How to Prove Modernisation ROI Before the CFO Says No

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A Series A UK SaaS founder whose five-year-old Rails monolith is slowing every new feature to a crawl and whose CFO has just asked for a signed-off business case before approving the £180K rebuild budget

Your modernisation business case is losing to the CFO because you are selling a benefit (developer velocity, future features) when you should be removing a cost. The winning argument is not what the rebuild will unlock; it is what you are already paying to keep the Rails monolith alive — workaround headcount, inflated AWS spend, blocked enterprise deals, and ICO fine exposure under UK GDPR Article 32 — assembled on one page the CFO recognises. Do that, phase the spend so the first increment funds the next, and £180K stops looking like a bet and starts looking like a refinancing.

This post is the argument you take into the meeting. It assumes you are a Series A UK SaaS founder, the monolith is roughly five years old, and the CFO has asked for a signed-off business case before releasing the budget.

Why the standard ROI pitch dies in the CFO's office

Every vendor modernisation calculator measures the same thing: engineering velocity. Story points per sprint, deploy frequency, lead time for change. These are real, but a CFO does not have a line on the P&L called "deploy frequency." They have lines called payroll, hosting, support contracts, and provisions for regulatory risk. If your business case does not move those lines, it is a wish list.

The second problem is framing. You are presenting £180K of new spend against soft future benefit. The CFO's job is to say no to that shape of request. The reframe: the business is already spending a six-figure annual run-rate maintaining the current system, that run-rate is growing, and the modernisation programme is how you stop it. Now you are not asking for new money. You are proposing to redirect money that is already leaving the building.

McKinsey's research on technical debt estimates it represents 20–40% of the entire technology estate's value before depreciation. Legacy-heavy organisations typically run an 80/20 budget split — 80% keeping the lights on, 20% building — against a post-modernisation target of 30/70. Those are the numbers that make a CFO lean forward, because they are talking about operating leverage, not engineering taste.

The cost of doing nothing: four lines the CFO already recognises

Build the baseline before you build the proposal. Every pound you can attribute to "we are already spending this" shortens the apparent payback period without inventing a single new benefit.

1. Workaround headcount absorbed by the monolith

Count the engineers, SREs, and support staff whose week is dominated by things the current architecture forces on you: manual deploys, flaky test suites, data patches run from the Rails console, incident response on background jobs that silently fail. Stripe's Developer Coefficient survey of 1,000+ engineers found developers spend an average of 17.3 hours per week — 42% of the working week — on maintenance and bad code rather than new development. On a Series A engineering team of ten at a loaded cost of ~£90K each, that is roughly £378K per year of payroll not producing new product.

You do not need to claim all of it. Claim the portion that is architecturally caused — the hours that would not exist on a modern codebase. A conservative 25% attribution on a ten-person team is still £90K/year of recurring cost the CFO is signing off today without a line item for it.

2. Inflated infrastructure spend

Legacy monoliths over-provision because you cannot scale components independently. A single slow endpoint forces you to scale the whole app. Background job queues run on oversized workers because splitting them is risky. Database read replicas get added instead of query refactors. Pull the last twelve months of AWS (or GCP) invoices and segment them: compute attributable to known-inefficient services, RDS instances sized for peak load that only one endpoint causes, data transfer costs from chatty internal calls that a modern design would eliminate.

You will not reclaim all of it. But a defensible 20–30% reduction in annual cloud spend after modernisation is the kind of number a CFO can validate against the invoices on their desk.

3. Revenue the system is blocking

This is the line founders systematically under-count. Walk through the last four quarters of lost or stalled enterprise deals and tag each with the reason. How many were blocked because:

• You could not meet a SOC 2 or ISO 27001 control the monolith's auth model does not support?
• SSO / SAML integration is a two-month engineering project rather than a config change?
• Audit log export, data residency, or role-based access controls were "on the roadmap"?
• A pilot customer asked for a feature that would have taken six weeks on a modern stack and twelve on yours — and went elsewhere?

Attach ARR to each. Even if you discount heavily for "we might not have won them anyway," the number is almost always larger than the modernisation budget. This is the slide that moves the CFO from cost containment to growth unlock, and it is grounded in deals the sales team already lost.

4. UK GDPR Article 32 exposure

This is the line the CFO's auditor will raise before the CFO does. UK GDPR Article 32 requires "appropriate technical and organisational measures" for security of processing. An unpatched or unpatchable monolith — one where you cannot easily rotate secrets, enforce MFA on service accounts, or isolate the blast radius of a compromised dependency — is a documented regulatory risk.

The numbers now have teeth. In October 2025 the ICO fined Capita £14 million for Article 5(1)(f) and Article 32 failures after a 2023 breach exposed 6.6 million people's data — and the starting-point fine before mitigating discounts was £58 million. In March 2025 the ICO fined Advanced Computer Software Group £3.07 million for Article 32 failures after a ransomware attack disrupted NHS 111 — the attack succeeded because a customer account lacked MFA. Across the 2023–24 period UK businesses were fined over £15.5 million for GDPR breaches.

You are not forecasting a fine. You are forecasting the expected value of regulatory and breach-response exposure, which is probability × impact. The CFO's auditor already does this calculation for cyber insurance renewal. Ask them for it, and put the number in the baseline. You should also have a solicitor review how your specific processing activities map to Article 32 — this post is not legal advice, and the exposure number has to survive your own counsel's scrutiny before it survives the CFO's.

Sequencing: strangler-fig vs big-bang, and why the CFO cares

Once the baseline is agreed, the conversation moves to how. There are two defensible paths and one indefensible one.

Big-bang rewrite

Full parallel rebuild, cut over on a date. Cheaper on paper because you avoid dual-run costs. Catastrophic in practice because you carry the entire delivery risk to a single launch, your product roadmap freezes for 12–18 months, and the CFO watches burn with no revenue signal until go-live. Industry data puts positive ROI on a full rewrite at 36–48 months, versus 12–14 months for a phased approach. Do not propose this unless the system is genuinely at end-of-life and there is no incremental path.

Strangler-fig incremental modernisation

Named after Martin Fowler's pattern: new functionality is built in a new architecture alongside the monolith, and traffic is progressively routed away from legacy endpoints until the monolith is strangled. For a Rails monolith this typically means extracting the highest-pain bounded contexts first — auth, billing, the one domain that is blocking enterprise deals — behind an API gateway, while the rest of the app keeps shipping.

The CFO case is strong because each increment has its own ROI. You are not asking for £180K against a two-year promise; you are asking for the first £45–60K against a four-month increment with a measurable outcome (SSO shipped, SOC 2 control satisfied, two blocked deals unblocked), and the savings from that increment partly fund the next. McKinsey has observed that organisations overspend by roughly 14% annually during migration transitions due to dual-run costs, so your plan has to be honest that months 3–15 cost more to operate, not less. Account for it in the baseline.

The indefensible path: "we'll refactor as we go"

Also known as "we are already modernising." The CFO has heard this for three years and velocity is still falling. If you present this as the alternative, you lose credibility. Say plainly that in-flight refactoring has not kept pace with debt accumulation — the 2024 Rails Community Survey confirms the ecosystem is still active (9% of 2,709 respondents came from the UK, on par with Germany), so this is not a language-death problem; it is an architecture problem your team cannot solve inside sprint capacity.

Phasing the spend so the first increment funds the next

This is the structure that converts a sceptical CFO. Break the programme into three or four increments of 10–16 weeks each, and for every increment specify four things:

1. What legacy cost it removes — workaround hours, infrastructure line, support contract, audit finding.
2. What revenue it unblocks — a named deal, a compliance certification, a pricing tier you cannot currently serve.
3. The capital at risk — the increment's budget, standalone. Not a slice of a £180K ask.
4. The decision gate — what has to be true at the end of the increment for the CFO to release the next tranche.

A plausible shape for a Rails monolith at Series A:

The CFO is not approving £180K. They are approving Increment 1 with a decision gate at week 14. Every subsequent tranche is a smaller decision made with better data.

What the business has to supply

Modernisation programmes fail more often on the client side than the vendor side. Before the business case is signed, be honest about what the business is committing to deliver:

• A product owner with real authority — not a part-time PM. The strangler pattern forces constant "keep in legacy vs move to new" calls, and these have to be made in hours, not weeks.
• Engineering capacity for cutover work — expect the internal team to spend 20–30% of their time on integration, data reconciliation, and feature-flag management during active increments.
• A clear data map — what tables, what PII, what retention, what residency. If this does not exist, Increment 0 is building it, and that cost belongs in the business case.
• Executive air cover — the CFO needs to understand that during months 3–15, both systems are running and gross infrastructure cost goes up before it goes down. If that conversation has not happened before kickoff, the programme will be cancelled at the first invoice shock.

What the business case actually costs — and what moves the number

The honest answer: the modernisation budget is a function of five variables, not a lookup in a price list. What moves the number up or down, in roughly descending order of impact:

• How many bounded contexts you extract — auth alone is a very different scope from auth, billing, and the core domain.
• Data migration complexity — a clean schema with good test coverage is a different programme from a five-year-old schema with implicit business logic in the Rails models.
• Integration surface area — every third-party (Stripe, Xero, HubSpot, your data warehouse) is an interface that has to keep working through the cutover.
• Compliance target — "meets Article 32" is a different bar from "passes SOC 2 Type II" is a different bar from "ready for an FCA-regulated customer."
• Team shape — fully outsourced delivery, blended team, or vendor-led with your engineers embedded all price differently and carry different post-programme ownership risk.

The payback window on a phased programme typically lands at 12–14 months, driven mostly by how aggressively the first two increments remove run-rate cost rather than by how fast new features ship. The things that would turn any of these ranges into a real quote are: a two-week discovery on the current codebase and data model, a prioritised list of the bounded contexts to extract, and a decision on the compliance target. Those three inputs together determine 80% of the number. A conversation with CodeNicely's modernisation team is scoped around producing exactly those three outputs before any delivery commitment is made.

How CodeNicely can help

The closest analogue in our portfolio to a Series A Rails monolith blocking enterprise deals is GimBooks, a Y Combinator-backed accounting SaaS where the product had outgrown its original architecture and the team needed to add compliance-grade features (GST, e-invoicing, multi-entity) without freezing the roadmap. We ran it as a strangler programme: extracted the domains that were blocking growth first, kept the legacy app shipping, and used each increment's output to fund the next phase of scope. The pattern — same programme shape as your situation — was lower risk per decision and shorter time to the first unblocked revenue line.

For the compliance-exposure side of the case, the Cashpo engagement is more relevant: a regulated lending workflow where Article 32-equivalent controls (KYC, auditability, access control, data residency) were non-negotiable and had to be designed in from the first increment rather than retrofitted. If the ICO exposure line in your baseline is doing heavy lifting, this is the pattern that makes it credible to your auditor.

We work with full IP transfer and no vendor lock-in, which matters for the CFO conversation — the business case has to survive the possibility that we are not the partner for Increment 3 or 4, and the architecture has to support that.

The one-page argument

If the CFO only reads the first page, it should say this: the business is already spending a six-figure annual run-rate on the current system in workaround headcount, over-provisioned infrastructure, and lost enterprise ARR, plus a quantified Article 32 exposure the auditor will raise at the next review. A phased modernisation programme redirects that spend into a modern architecture, with each 10–16 week increment carrying its own ROI and its own decision gate. The ask today is not £180K. The ask is Increment 1, with the next tranche contingent on the gate being met. The alternative — continuing to pay the current run-rate while losing deals — is the expensive option.

That is the argument. The baseline numbers are yours to assemble, because only you have access to the AWS invoices, the lost-deal list, and the engineering time logs. Spend the week before the CFO meeting on that assembly, not on the proposal deck.

Frequently Asked Questions

How long should a legacy modernisation programme take for a Series A SaaS?

A phased strangler-fig programme typically reaches positive ROI in 12–14 months, compared with 36–48 months for a full rewrite, according to industry data cited by EC Info Solutions and McKinsey. The actual duration depends on how many bounded contexts you extract, data migration complexity, and whether you are also targeting a compliance certification like SOC 2 in parallel. Scope those three inputs with a two-week discovery before committing to a timeline.

How do I quantify the cost of keeping legacy software running?

Four lines: engineering hours absorbed by workarounds (Stripe's data suggests 42% of a developer's week goes to maintenance on average), over-provisioned cloud infrastructure, revenue blocked by missing enterprise features (SSO, audit logs, compliance controls), and regulatory exposure under UK GDPR Article 32. Pull last twelve months of invoices, lost-deal reports, and engineering time logs. The number is almost always larger than the modernisation budget, which is the point.

Should I propose a big-bang rewrite or incremental modernisation?

Incremental, almost always. A big-bang rewrite freezes your roadmap for 12–18 months, carries all delivery risk to a single cutover date, and gives the CFO no revenue signal until go-live. The strangler-fig pattern lets each 10–16 week increment carry its own ROI and its own decision gate, so capital is released in tranches against observable outcomes rather than a single large commitment up front.

What UK GDPR exposure should I include in the business case?

Expected value — probability of a reportable incident multiplied by likely impact — not a forecast fine. Reference points: the ICO fined Capita £14 million in October 2025 for Article 5(1)(f) and Article 32 failures (starting-point fine £58 million), and fined Advanced Computer Software Group £3.07 million in March 2025 after an MFA-related breach disrupted NHS 111. Your cyber insurance renewal already contains an exposure calculation; ask for it and have your solicitor validate the specific Article 32 mapping before the number goes in front of the CFO.

What are the hidden costs of a modernisation programme itself?

Dual-run infrastructure during the transition — McKinsey has observed roughly 14% annual overspend during migration periods due to running old and new systems in parallel. Expect gross infrastructure cost to rise for months 3–15 before falling. Also budget for 20–30% of internal engineering time on cutover work, a full-time product owner with decision authority, and a data-mapping exercise if one does not already exist. Surfacing these costs in the baseline, rather than after kickoff, is what keeps the programme from being cancelled at the first invoice shock.