Bitrix rewrite discovery: scope before estimate

When someone asks me, "How much would it cost to rewrite our Bitrix site on a normal stack?", I rarely answer with a number in the first message.

Not because I want to make sales complicated. A serious rewrite estimate starts with a risk map: what already makes money, what breaks today, which integrations cannot stop, and where the team is actually losing delivery speed.

Rewrite sounds simpler than it is

From the outside the task looks clear: old Bitrix, modern frontend, better search, faster checkout, cleaner releases. So the answer must be a rewrite.

Inside, it is rarely that simple. The catalog has its own rules. 1C exports data differently from the documentation. SEO depends on historical URLs. Managers rely on specific admin flows. Some business logic is hidden in event handlers that nobody has touched for years.

If you name a fixed price at that point, you are not selling control. You are selling the illusion of control.

What I check before estimating

The first layer is money and risk. Which pages drive revenue, which flows cannot be paused, where one hour of downtime already hurts the business. Without this layer, you can "improve architecture" and quietly damage the system that pays the bills.

The second layer is data. Catalog, prices, stock, filters, properties, SEO metadata, redirects, account area, orders, roles, permissions, 1C exchange, CRM, payments and delivery integrations. This is where base scope and client-specific scope start to separate.

The third layer is process. How changes ship today, whether staging exists, who accepts a release, how rollback works, and how the team knows production is healthy after deployment. In a headless project, this matters as much as Next.js or Elasticsearch.

Scope should be short, but functional

I do not like 100-page requirement documents that nobody reads. A useful discovery output for a rewrite or headless project is a compact functional scope.

It should make five things visible:

the base scope without which launch does not make sense;
optional blocks that can move to a second phase;
integrations and data owners;
acceptance criteria for key business flows;
risks that need a pilot, not a promise.

That kind of document helps the owner, CTO and delivery team discuss the same project. Not "make it modern", but "this is version one, this is what we test, and this is what we leave untouched until the evidence is there".

A pilot is often more honest than a large contract

If the main risk is catalog, search or speed, I prefer to start with a limited work slice: one category, one search flow, one API adapter, one Core Web Vitals area.

This is not a demo for its own sake. It tests the workflow: access, code quality, review, staging, metrics before and after, and the team's ability to explain trade-offs without hiding them.

After that pilot, the larger project becomes easier to discuss. You can see not only "how much", but how the team actually works.

When fixed price makes sense, and when it does not

Fixed price makes sense for productized formats where the scope is repeatable: packaged Frontbox subscription or a white-label Frontbox setup with clear boundaries.

For custom rewrites, integrations, B2B portals and non-standard e-commerce flows, fixed price before discovery usually creates bad incentives. Either the vendor hides risk in a large buffer, or every normal scope discovery becomes a commercial argument later.

I prefer a different sequence: short diagnosis, base scope, optional blocks, then an estimate by milestone or work slice. The client gets a budget range and understands what drives it.

Where I fit

My value is not in saying "rewrite everything" as quickly as possible. I have seen too many old PHP systems keep earning money while the new stack is still learning to repeat basic flows.

I am useful when engineering refactoring needs to be separated from business risk: what stays in Bitrix, what moves to Next.js, where Elasticsearch is justified, where an API adapter is enough, and where the real problem is the release process.

If you are looking at legacy Bitrix and thinking about a rewrite, do not start with a large contract. Start with a risk map and one testable slice.

For a commercial project, WGP can run that as a technical audit / Catalog Probe. For a direct conversation, message me on Telegram or LinkedIn.