Migration Economics: The Numbers a CFO Approves

If you're a CTO preparing a move to headless architecture, here's what your CFO actually sees when they open the deck. And why, in 9 cases out of 10, they close it after 3 slides.

At WebGoodPeople we see this every week. The CTO arrives with a detailed technical case: microservices, API-first, independent deploys, developer experience. All correct. All ineffective.

A CFO doesn't buy architecture. A CFO buys the removal of a specific financial risk. This article is the frame that translates the first into the second.

Three layers of math that work

Every headless-migration case for a CFO should be built on three layers, in exactly this order:

Layer 1: the cost of NOT migrating. How much the business loses right now because of the current architecture.

Layer 2: direct migration costs. Person-hours, tools, downtime risk.

Layer 3: risk-adjusted comparison. Expected return weighted by the probability of failure.

If you start with Layer 2, the CFO sees only an expense figure. That's almost always a red flag. Start with Layer 1.

Layer 1: the cost of not migrating (shadow revenue)

Take a realistic e-commerce model:

• 500,000 sessions per month
• 1.2% conversion
• Average order value 4,500 ₽

Monthly revenue: 500,000 × 1.2% × 4,500 = 27,000,000 ₽/month.

Loss from TTFB

The Amazon rule («every 100 ms of latency = 1% of sales») has been re-measured dozens of times. The exact figures vary by market, but the direction is stable: 500 ms of delay = 3–6% lost conversion.

If your TTFB on the catalog is 900 ms (typical for a mid-aged Bitrix monolith), then compared to 400 ms (achievable on headless with ISR/edge), you're losing about 4% of conversion.

Loss: 27,000,000 × 4% = 1,080,000 ₽/month.

This is money your team never sees in reports. It never existed as a line in the P&L. You don't «save» it through migration, you unlock it.

Loss from bus factor

A separate category: the cost of having one or two developers who know the Bitrix components, where their departure means the project stops.

Conservatively: one critical release delayed by 2 weeks because a developer is unavailable equals a missed marketing campaign or promo launch. Estimate: 2–5% of monthly revenue per such case. It happens 3–6 times a year.

Total: 540,000–1,350,000 ₽/year on a typical market average.

Loss from speed of change

Every landing page, promo, or campaign launch in a monolithic admin takes 2–4 weeks versus 1–2 days on headless. Over a year that's 10–30 activities you never ship. If each adds 2% revenue growth in its month, you're leaving 2–6 months of growth on the table per year.

In total: Layer 1 usually comes to 18–30 million ₽/year for a typical mid-size e-commerce.

Layer 2: direct migration costs

Here it's important to distinguish two kinds of migration:

Big-bang rewrite (the one the CFO fears): rewrite everything in 12 months. 4–8 developers × 12 months × 400,000 ₽/mo = 19–38 million ₽. Plus a 40–60% risk of blowing the deadline.

Staged decomposition (the one we propose): incremental extraction, starting with the most «money-making» module (usually catalog + search). A 2-week pilot at a fixed price. Continuation driven by metrics.

A 2-week pilot = 800,000–1,500,000 ₽. If the metrics don't move, it's closed and you've lost the pilot budget. If they do move, you continue evolutionarily, locking in the gain from each stage.

The figure for the CFO: «Risk = the cost of the pilot. Before the pilot, it's zero.»

Layer 3: risk-adjusted comparison

Now the comparison in the clean form a CFO accepts:

• Status quo: expected benefit (12 mo) 0 ₽, direct cost 0 ₽, failure risk —, risk-adjusted 0 ₽ (but shadow loss = −18 million).
• Big-bang rewrite: expected benefit +25 million (after migration), direct cost −25 million, 50% chance of failure, risk-adjusted +0 ± 15 million.
• Staged headless: expected benefit +12 million in the first year, direct cost −4 million (staged), 15% per stage, risk-adjusted +8 million.

The last row is what the CFO looks at. Not «a migration for 25 million», but «+8 million a year at a manageable risk».

A template you can show a CFO

Step 1. Name three concrete risks (not «architectural debt», but: «we lose 1.08 million/mo on TTFB», «one person knows the Bitrix component», «we launch promos in 2 weeks instead of 2 days»).

Step 2. Cost them in rubles. Not «a lot», but a specific amount. A 5-row table.

Step 3. Propose a 2-week pilot at a fixed price, with a clearly defined scope and before/after metrics. Frame it as a «minimal hypothesis test», the wording a CFO understands from financial vocabulary.

Step 4. At the end of the deck, ONE figure: «Risk = X ₽ (pilot budget). Expected benefit = Y ₽/year. Decision: approve or reject the pilot.»

Not «approve or reject the migration.» Only the pilot.

Common mistakes in these decks

Starting with architecture. The CFO closes the deck on the «microservices vs monolith» slide. Architecture is for CTOs and architects to discuss. The CFO discusses rubles and risks.

A big number up front. «The migration will take 12 months and cost 25 million.» The CFO sees that and thinks «let it wait until next year.» Always break it into stages, the first of which is a pilot for a small amount.

No success metrics. «It'll be faster and more convenient» is not a metric. A metric is «TTFB from 900 ms to 400 ms in 4 weeks, measured with Lighthouse at the end of the second week.»

No failure scenario. If the CFO can't see what they lose on a failed pilot, they can't assess the risk. «Risk = 1.2 million (pilot budget). If the metrics don't move, we close it and the pilot budget is lost» is a clear amount in a clear context.

What this means in practice

If you have a CFO discussion coming up and a deck already exists, redo the cover. From «Why we need headless» to «Three financial risks and their cost in ₽».

If the CFO isn't in the discussion yet, prepare the Layer 1 table before the conversation. Show shadow revenue first, before any technical slides.

If you're ready for the next step, request a 48-hour CWV audit. It gives you concrete Layer 1 numbers for YOUR stack, not from a generic model.

---

WebGoodPeople runs a 48-hour CWV audit for free. We return a shadow-revenue calculation on your own data and a concrete plan for a 2-week pilot: our headless Next.js + Elasticsearch product.