Bitrix rewrite audit: reducing risk before a headless migration

When someone comes to me with "we want to rewrite our 1C-Bitrix store on Next.js", I do not start with a price.

First I try to understand what they mean by rewrite. Sometimes it is a real architecture change. Sometimes it is frustration with a slow catalog. Sometimes it is a contractor problem. Sometimes the marketing team just cannot launch a new landing page without five tickets and two weeks of waiting.

If you price the project at that point, you get a clean but useless number. It says nothing about downtime risk, SEO, integrations that must not move, or why checkout should probably stay in the old system during the first phase.

For a serious Bitrix project, the proper first step is not a proposal. The proper first step is a compact risk audit.

What I check first

The first layer is the money and operations path: catalog, cart, prices, stock, discounts, payment, delivery, 1C sync, CRM, customer account. Not as a module list, but as a map of what cannot stop.

The second layer is release speed. What the team cannot ship today: new categories, SEO pages, promotions, filters, search, content blocks, A/B tests. Headless is rarely useful because it is headless. It is useful when the old system blocks changes that matter.

The third layer is data ownership. Which product fields live in Bitrix, which arrive from 1C, which are calculated, and which are edited by the content team. "The catalog" sounds like one object. In production it is usually dozens of sources of truth.

The fourth layer is SEO surface: URLs, canonicals, filters, pagination, breadcrumbs, structured data, sitemap, redirects and indexable landing pages. If this is not mapped before the project, a rewrite can easily become "we made the site faster and lost organic traffic".

The fifth layer is observability: logs, metrics, slow queries, API errors, indexing speed, cache hit rate. Without it, nobody can honestly say what is slow: Bitrix, SQL, templates, an external API, search or CDN.

Why fixed price before this map is a bad signal

Fixed pricing can work for productized formats: clear scope, repeatable stack, known constraints.

For a custom rewrite or headless migration, fixed price before discovery usually means someone buried the risk. The client still pays for it later through scope creep, conflict, bad compromises, or a half-finished project.

I prefer a different shape:

Collect preliminary requirements and business context.
Split functionality into base, optional and client-specific parts.
Define the API contract and the areas we will not touch in the first iteration.
Pick a small pilot scope where speed, quality and workflow can be measured.
Price the larger project from a fact map, not from a guess.

It is less exciting than "we will rebuild everything in N weeks". It protects the client's budget and the team's reputation.

What a good pilot looks like

A weak pilot says: "let us rewrite half the site and see what happens."

A good pilot chooses one area with business value and technical risk:

a catalog category with heavy filters;
search with Elasticsearch and a measurable quality target;
a standalone SEO landing page on top of the existing catalog;
a read-only customer account without touching payments;
a new Next.js storefront that reads data through a limited Bitrix API.

The pilot should not ask anyone to trust a deck. It needs criteria: the URL works, data is correct, speed improves, SEO metadata survives, rollback is clear, and the client can see Git Flow and staging.

If the pilot works, the roadmap conversation becomes practical. If it fails, that is still useful. You found the risk cheaply.

Where WGP fits

I run WebGoodPeople around this exact class of work: Bitrix-backed e-commerce, Next.js, Elasticsearch, careful modernization without stopping sales.

But I do not think every project needs a big rewrite. Sometimes you only need to move search out. Sometimes you need an API audit. Sometimes monitoring and slow queries should be fixed first. Sometimes the honest advice is: do not touch checkout in phase one.

If you are looking at an old Bitrix store and you are not sure whether this is a rewrite, an optimization project or a headless migration, I would start with a short risk map instead of a budget number.

The practical next step is simple: send the site URL and the current pain: speed, releases, search, SEO, integrations or contractor risk. On the WGP side, that becomes a compact scope: what we check, what we leave alone, where a pilot makes sense, and which decision criteria are fair.