Before a Legacy Rewrite, Do a Risk Audit

When someone says “we need a rewrite,” they usually aren't describing the work yet.

They're describing fatigue.

The site is slow. Releases are painful. The vendor disappeared. Nobody wants to touch old Bitrix templates. Marketing waits two weeks for a simple landing page. The engineering team says: “It would be easier to rebuild this.”

Sometimes they're right. Sometimes they aren't.

The problem is that rewrite sounds like a plan, while at the start it's only a hypothesis. If you turn it into an estimate too early, every hidden risk rides into the project: SEO, catalog data, roles, checkout, ERP sync, CRM, content model, data migration and rollback ownership.

I wouldn't start that conversation with a budget.

I'd start with a risk map.

What actually hurts

The first question is blunt: what becomes better if a new frontend appears tomorrow?

If the answer is “the site gets faster,” check what is slow today: SQL, templates, API, images, filters, CDN, external services, personalized prices or search.

If the answer is “the team will ship faster,” inspect the deploy flow, backend/frontend coupling, content permissions, task queue and the exact places where changes break production.

If the answer is “we need to get away from the old vendor,” this is not just architecture. It's transfer of ownership: documentation, access, Git history, environments, knowledge base and the decision model.

The same word, rewrite, can hide three different projects.

What should not move first

In old e-commerce systems, some ugly parts still make money.

For example:

checkout with years of discount rules;
account areas with custom roles;
ERP sync that works partly because nobody touches it;
SEO pages that still bring organic traffic through old URLs;
CRM integrations with manual exceptions;
stock export logic that lives in team habits, not only in code.

That doesn't mean those parts can never be modernized. It means they shouldn't fall into the first scope by accident just because rewrite sounds big.

Sometimes the right first move is the catalog. Sometimes it's search. Sometimes it's a new layer for SEO pages. Sometimes checkout should stay in Bitrix while Next.js gets a read-only storefront.

Headless is useful not because everything becomes new. It's useful because part of the system can move without setting the rest of the business on fire.

Why fixed price is risky here

Fixed price can work for productized formats: repeatable scope, known constraints, known team.

For a custom rewrite, fixed price before discovery usually means the risk has been hidden in the wording.

It comes back later:

“we didn't know prices were calculated through a custom module”;
“we didn't include separate rules for B2B customers”;
“we thought filters could be copied one to one”;
“we didn't see that half of organic traffic depends on indexable parameters”;
“nobody mentioned that managers edit stock manually before promotions.”

An honest estimate starts after compact discovery: preliminary requirements, base scope, optional/client-specific functionality, integrations, data, roles, workflow and acceptance criteria.

Before that, you can estimate the first work slice. Not the whole rebuilt world.

The slice I would choose

A good pilot should be small, but not fake.

I like areas where business value and technical risk are both visible:

One catalog category with heavy filters.
Search based on real queries and zero-results logs.
An SEO landing page built on top of existing data.
A read-only account area without payment or order mutation.
The API contract for product, price, stock and images.

A pilot needs criteria. The URL works. Data matches. Metadata survives. Performance improves. Rollback is clear. The team sees Git Flow, staging and production checks.

If the pilot fails those criteria, that's not a disaster. That's cheap risk discovery.

What an owner or CTO gets

After a proper pre-rewrite audit, the team should know:

which pain is real and which one is just loud;
what can move first without risking revenue;
what should stay in the old system for now;
which data and integrations control the cost;
which pilot can show results without a giant promise;
where senior engineering judgment is needed and where it's just normal backlog work.

This is less exciting than a “modern stack” deck.

But it's the kind of conversation you can defend in front of the business. Not because the architecture looks elegant. Because the next step is bounded, measurable and doesn't require trust by default.