← Back to blog

Risk budget before headless: what I count before a rewrite

A rewrite rarely starts with architecture. It usually starts with a sentence: "we cannot keep developing the current site anymore."

Sometimes that is true. Sometimes it is not.

Before headless, Next.js or a full rebuild, I do not count only the development budget. I count the risk budget: what the business can lose if the migration goes wrong.

Money is not the only risk

The obvious cost is easy to see: team, hours, vendor, licenses, infrastructure.

But e-commerce has four more bills that often stay outside the first estimate:

  • catalog or checkout downtime;
  • SEO loss from URLs, canonicals, filters and content parity;
  • broken integrations with ERP, payments, delivery or CRM;
  • internal team time for acceptance, testing and the transition period.

If those are not counted early, the project only looks cheaper on paper.

First question: what exactly blocks growth

"Bitrix is slow" does not explain anything.

The bottleneck can be an SQL query. Cache. Template code. Search. ERP sync. No staging. Manual deploy. Sometimes the real bottleneck is process: every change goes through one person who remembers the system by heart.

So the first step is not choosing a stack. The first step is a risk map:

  1. which pages and flows actually make money;
  2. where the technical limit is visible in metrics, logs or release speed;
  3. what must not break even for one day;
  4. which integrations hide business logic;
  5. which acceptance criteria will prove that the transition worked.

Without this, headless is just a nice hypothesis.

Second question: can we move in stages

A big rewrite is dangerous because it delays feedback.

The team builds a new system for months, then discovers that part of the logic lived in the old template, part in event handlers, part in a manager's spreadsheet, and part was "always done manually."

A staged headless transition reduces that risk:

  • start with one commercial flow;
  • keep the old core while it still makes money;
  • set up staging and rollback;
  • compare before/after metrics;
  • expand scope only after evidence.

This is not always the trendiest path. It just avoids putting the whole revenue stream behind one deploy.

Third question: what will count as success

"Launch the new site" is a weak acceptance criterion.

Better signals:

  • LCP and TTFB on key pages;
  • release speed for marketing changes;
  • correct indexing and redirects;
  • checkout and integration stability;
  • share of flows where the team no longer touches legacy frontend;
  • clear ownership for API, frontend, content, cache and monitoring.

Then the architecture discussion becomes a business discussion.

What I usually suggest instead of a big promise

Not "fixed price for a rewrite."

First, compact discovery: requirements, a functionality map, base scope, optional/client-specific parts, integrations, data, roles, workflows and acceptance criteria.

Then a small work slice: one catalog section, one search flow, one frontend module, one measurable problem.

That shows work quality faster than a 40-slide deck.

And it is more honest.

Headless is useful when it reduces risk and speeds up change. If it only replaces one black box with another, it is not modernization. It is scenery change.