Moving On-Premise to Cloud: The Case Your CFO Will Sign

For: A UK-based Series A SaaS founder who is still running their product on a co-located or on-premise server inherited from the early days, whose board is asking about ISO 27001 and UK GDPR posture, and who cannot get a clear answer on what migration will actually cost versus what staying put is already costing them

The case your CFO will sign is not "cloud is cheaper." It is this: your on-premise setup carries a quantifiable UK GDPR breach exposure calculated against global turnover, is blocking enterprise deals that require ISO 27001, and absorbs headcount and support-contract spend that already exceeds a phased migration budget. Cloud ERP and infrastructure benchmarks show 66–71% lower total cost of ownership over 10 years, but the number that actually moves a CFO is the cost of doing nothing — and that number is bigger than most Series A founders realise.

This post gives you the argument, the sequencing, and the honest tradeoffs. It does not give you a quote, because no one credible can quote you without scoping your data, integrations, and compliance targets first.

Start with the cost of doing nothing

Every migration business case that dies in a CFO meeting dies for the same reason: the founder walks in with the cost of moving and no credible number for the cost of staying. The CFO's default is inertia. Your job is to make inertia the expensive option.

There are four line items your CFO already recognises. Price them honestly, on your own numbers, before you talk about cloud at all.

1. The support contract and hardware lifecycle

Pull the last three years of invoices. You are looking for: the annual hardware support contract (Dell ProSupport, HPE, whoever), the co-location or rack fees if applicable, the OS and hypervisor licences, backup software licences, and any specialist appliance renewals (firewalls, load balancers). Add the sinking fund your finance team should be accruing for the next hardware refresh — typically every 4–5 years — even if no one is actually accruing it.

2. The headcount you are not admitting to

Very few Series A SaaS companies have a full-time sysadmin. What they have is a senior engineer who spends 15–30% of their week on patching, backups, monitoring, capacity, and the occasional 2am incident. Price that engineer's fully-loaded cost at the percentage they actually spend. IDC's 2023 analysis, cited in cloud vs on-premise TCO comparisons, puts the operational labour reduction from a cloud move at 25–40% — because patching, hardware lifecycle, and capacity planning are absorbed by the provider.

3. The revenue the system is blocking

This is the one CFOs underweight and the one that usually closes the argument. Walk through your last five lost or stalled enterprise deals. How many asked for ISO 27001? How many sent a security questionnaire with questions about physical access controls, patch cadence, or SOC 2 that your current setup cannot honestly answer? ISO 27001 certification eliminates or reduces security questionnaires in 70–90% of enterprise deals — it is a sales accelerator, not just a compliance line item. And the 2022 revision added cloud-specific controls (Annex A.5.23) that map cleanly onto cloud-native infrastructure and awkwardly onto legacy on-premise setups.

4. The ICO exposure window nobody has priced

Here is the number most founders have never put in a board pack. UK GDPR fines can reach £17.5 million or 4% of global annual turnover, whichever is higher, under the ICO's updated Fining Guidance from March 2024. The fine is calculated against your turnover, not the cost of the breach.

Now overlay two facts. First, time-to-exploit for newly disclosed vulnerabilities has collapsed from 63 days in 2018 to 5 days in 2024. Second, organisations average 88 days to remediate a critical vulnerability after a patch ships, and 50% of CISA Known Exploited Vulnerabilities remain unpatched 55 days after a fix is available.

The gap between when a vulnerability becomes weaponisable (5 days) and when a typical on-premise setup actually patches it (60–90 days) is your exposure window. On a managed cloud platform with automated patch management, that window collapses toward zero for the layers the provider owns. That is the argument. Not "we might get breached." It is: "we are carrying a 55-to-85-day window where a known, patched vulnerability is exploitable on our infrastructure, and the fine ceiling is 4% of turnover." Your CFO understands asymmetric risk. Frame it that way.

None of this is legal advice — get your DPO or an external counsel to review the specifics of your data processing and breach notification obligations before you put fine estimates into a board pack.

What migration actually costs — the model, not a number

Published benchmarks put cloud migration costs at $40,000 for startups to $600,000+ for enterprises. A Series A SaaS company sits at the low end of that range, but the range exists for a reason. The four things that move your number, in roughly descending order of impact:

• The shape of your data. Is it a single production Postgres with 200GB and no PII edge cases? Or is it a decade-old MSSQL instance with stored procedures nobody wrote, feeding three internal tools? Data migration is where big-bang projects overrun.
• Integrations and dependencies. Every SFTP feed, every hardcoded IP, every batch job cron'd on the sysadmin's laptop. Discovery of these usually doubles the integration line item on the first pass.
• Rearchitect vs rehost. Lift-and-shift is cheapest and fastest but preserves most of the operational cost you are trying to escape. Rearchitecting to managed services (RDS, S3, container orchestration) costs more upfront and returns more over 24 months. Most credible migrations are a mix, by workload.
• Compliance target. Migrating with ISO 27001 in scope from day one is more expensive than migrating first and certifying later — but certifying later means a second round of rework. ISO 27001 certification requires 6–12 months plus 3 months of operational evidence, so the sequencing matters.

Illustrative only: a Series A SaaS with a single Postgres database, two external integrations, no PII beyond standard user records, choosing a rehost-then-refactor path on AWS or Azure, sits toward the lower end of published startup migration ranges. Change any of those assumptions — add a second database, add HIPAA-adjacent data, add a hard ISO 27001 deadline tied to a specific enterprise deal — and the number moves materially. Any vendor who quotes you without a scoping conversation is guessing.

To turn a range into a real number, three specifics matter most: (1) an inventory of every data store and integration, with owners; (2) your compliance target and deadline; (3) whether you are rehosting, refactoring, or replatforming each workload. If you want that conversation, CodeNicely's digital transformation team scopes migrations against exactly these inputs.

Sequencing: strangler-fig vs big-bang

The single biggest determinant of whether your migration lands on budget is sequencing. There are two honest options.

The strangler-fig increment

Named for the fig that grows around a host tree and eventually replaces it. You stand up cloud infrastructure alongside the on-premise system, migrate one bounded workload (usually the newest service, or the one with the clearest interface), route traffic to it, verify, then repeat. The old system shrinks; the new one grows.

Good at: preserving revenue continuity, letting you learn the cloud operating model on a low-stakes workload first, phasing the spend so the first increment retires enough on-premise cost to fund the second.

Bad at: anything with deeply shared state. If your monolith has one database that every module reads and writes, the strangler pattern fights you at every step. It is also slower in wall-clock time — you will run parallel infrastructure for months, and that costs money.

The big-bang rebuild

Cut over the whole system in one weekend. Usually chosen when the on-premise system is genuinely unmaintainable, when a hardware refresh is forcing a decision, or when a compliance deadline makes incremental work uneconomical.

Good at: speed to a clean end state, no parallel-running cost, one training curve for the team.

Bad at: risk. Everything that can go wrong goes wrong in the same weekend. Rollback plans are theoretical until they are not. If your revenue depends on the system being up, this option is harder to sell to your board than to your CFO.

Most Series A migrations that succeed are strangler-fig with one big-bang exception — usually the primary database, cut over during a planned maintenance window near the end of the programme.

Phasing the spend so the first increment funds the next

This is the specific framing that gets a modernization budget signed. Do not ask for the full programme budget on day one. Structure it as three phases, each with its own approval gate.

1. Phase 1 — Discovery and first workload (typically 8–12 weeks). Full inventory of data, integrations, and dependencies. Compliance gap analysis against ISO 27001 and UK GDPR. Migrate one bounded, low-risk workload (often a stateless internal tool or a read-heavy reporting service). Deliverable: a real cost and timeline model for the remaining phases, based on measured effort, not estimates. This is the phase your CFO approves easily because the spend is bounded and the output is a better forecast.
2. Phase 2 — Core workload migration. The main application tier, cache, queueing, observability. On-premise support contracts start winding down. Sysadmin percentage-of-week drops. First measurable savings hit the P&L. Enterprise sales conversations that were blocked on infrastructure questions start reopening.
3. Phase 3 — Database, decommission, certification. Primary data store cutover. On-premise environment decommissioned. ISO 27001 evidence collection begins on the new environment. Full cost savings realised.

Each phase's savings — retired support contracts, reclaimed engineering time, deals unblocked — should be tracked against Phase 1's baseline and reported to the CFO monthly. This turns a capital expenditure conversation into an operational return conversation, which is a much easier conversation to have quarterly.

What the business has to supply

Migrations fail on the client side as often as the vendor side. Before you brief anyone, get these ready:

• A named executive owner. Not a committee. One person who can make cutover decisions.
• A data map, even a rough one. What data lives where, who owns it, what its retention and residency requirements are. UK GDPR data residency matters if you have EU or UK customers with contractual data-location clauses.
• An integration inventory. Every external system your on-premise environment talks to, in either direction. Include the ones you inherited and no longer understand.
• Your compliance target and its deadline. ISO 27001 tied to a specific enterprise deal is a different project from ISO 27001 as a general posture improvement.
• Access. To the servers, the code, the monitoring, and — critically — the person who set it all up seven years ago, if they still take your calls.

How CodeNicely can help

CodeNicely runs legacy modernization and cloud migration programmes for SaaS companies at exactly the Series A stage this post is written for. The engagement that maps most closely is GimBooks, a YC-backed fintech accounting SaaS. GimBooks had the same profile: an early product that had grown past its original infrastructure, a compliance posture that was starting to matter for larger customers, and a founder who needed to phase spend against measurable outcomes rather than commit to a big-bang budget upfront.

The work there followed the sequencing described above — discovery first, then bounded workload migrations, then core services — with full IP ownership retained by GimBooks and no vendor lock-in on the cloud tooling chosen. That last part matters more than founders realise: a migration partner who ties you to their proprietary orchestration layer has just moved your lock-in from a physical server to their software.

If your situation is closer to modernizing an internal operations stack rather than a customer-facing SaaS, the SMB modernization and digital transformation pages cover that work specifically.

The one-slide summary for the CFO meeting

If you take one thing into the meeting, take this framing:

We are carrying a quantifiable ICO exposure window of 55–85 days on unpatched vulnerabilities, against a fine ceiling of 4% of global turnover. We are absorbing roughly [X]% of a senior engineer's time and [£Y] of annual support and hardware spend on infrastructure our customers increasingly ask us to certify. Enterprise deals worth [£Z] in the pipeline require ISO 27001, which is materially easier on cloud infrastructure. A phased migration, starting with an 8–12 week discovery and first-workload phase, gives us a real cost model before we commit to the full programme — and the first phase's output is either a green light with measured numbers or a decision to stop with limited spend.

That is the case CFOs sign. Not because cloud is cheaper. Because staying still has a price tag your board can now see.

Frequently Asked Questions

How long does an on-premise to cloud migration take for a Series A SaaS?

The honest answer is a range, driven by three things: the number of distinct workloads and data stores, whether you are rehosting or refactoring each, and whether ISO 27001 is in scope from day one. A single-application SaaS with one primary database and a handful of integrations is a materially different project from a company with three services, an analytics pipeline, and hardcoded external dependencies. To turn a range into a real timeline, you need a discovery phase — typically 8–12 weeks — that produces a measured plan for the remainder.

Can we get ISO 27001 certified while still on-premise?

Yes, but it is harder and the 2022 revision made it harder still. ISO 27001:2022 added cloud-specific controls (Annex A.5.23) and the overall control set maps more naturally onto managed cloud services than onto self-managed on-premise infrastructure. Certifying on-premise means demonstrating manual evidence for controls the cloud provider would otherwise attest to on your behalf — physical access, patch management, backup verification, capacity management. Doable, but more expensive to achieve and more expensive to maintain annually.

What is the biggest hidden cost of staying on-premise?

Not the hardware or the support contract. It is the compounding revenue loss from enterprise deals that stall on security review, plus the asymmetric risk of the ICO exposure window. Time-to-exploit has collapsed to 5 days while typical remediation takes 88 days. That gap, multiplied by a fine ceiling of 4% of global turnover, is a risk most on-premise founders have never quantified.

Should we lift-and-shift or rearchitect?

Almost always a mix, decided per workload. Lift-and-shift is cheapest and fastest but preserves most of the operational cost you are migrating to escape — you still own patching, scaling, and capacity. Rearchitecting to managed services (managed databases, object storage, container orchestration) costs more upfront but returns more over 24 months and is materially easier to certify. A common pattern: lift-and-shift stateless services first to prove the operating model, then refactor stateful services in phase two.

What determines whether the migration budget gets approved?

Whether you have credibly priced the cost of doing nothing. CFOs approve modernization budgets when the alternative — support contracts, absorbed headcount, blocked revenue, compliance exposure — is quantified in numbers they can defend to the board. The phased approach (discovery first, then core, then decommission) helps because each phase's approval is bounded and each phase's output either justifies the next or gives you a clean stopping point.