Headless Without the Rewrite: Migrate Safely

The word "headless" triggers a specific fear in enterprise teams: "we'll have to rewrite everything." That fear rests on a false premise. Moving to a headless architecture is not a migration, not a refactor, and not a rewrite. It's a layer on top. And it doesn't require breaking what already works.

The myth of the "big rewrite"

Enterprise has a recurring pattern: someone proposes to "rewrite everything from scratch," the team gets excited, the project starts, and 6 to 12 months later it turns out that:

• Timelines have grown 2 to 3 times beyond the original estimate
• The budget is overrun, but "there's just a bit left"
• Some functionality is lost or behaves differently
• Business processes are disrupted, managers have to relearn
• ROI is unpredictable, because the new system hasn't stabilized yet

In the tech industry this is called the "Osborne effect": when announcing a future product kills sales of the current one. In IT projects the analog is this: while the team builds a "new world," the current product degrades, because all the resources went into the rewrite.

According to the Standish Group, 66% of large IT projects exceed their budget or timeline. A full platform migration is one of the riskiest project types there is.

The Strangler Fig pattern: grow around it, don't kill it

Instead of replacing the existing system, we use the Strangler Fig pattern, named after the fig that grows around a host tree and gradually forms its own trunk. The host tree doesn't die at once. It keeps functioning until the new structure becomes self-sufficient.

In technical terms it looks like this:

• The backend stays: Bitrix continues to manage the catalog, orders, CRM, and inventory. Every business process runs as before.
• An API layer is added: adapters turn Bitrix data into a REST/GraphQL API for the frontend.
• A new frontend appears: Next.js renders pages, pulling data through the API. Fast, modern, SEO-friendly.

The key principle: nothing is deleted or rewritten until the new layer has proven itself in production.

A step-by-step migration plan

Phase 1 — Assessment (1 week)

• Audit the current architecture: which APIs already exist, what needs to be added
• Measure baseline metrics: TTFB, LCP, INP, CLS, API response time
• Map dependencies: which pages depend on which data
• Pick the pilot pages (usually the home page, catalog, and product page)

The output: a document covering the current state, room for improvement, and the pilot plan.

Phase 2 — Pilot (2 weeks)

• Deploy the Next.js frontend to a staging environment
• Connect to Bitrix through the API and adapters
• Build 1 to 2 key pages (for example, the catalog plus a product page)
• Wire up Elasticsearch for search and filtering
• Measure metrics on the new frontend and compare against the baseline

The output: a working prototype with real data and a comparison report.

Phase 3 — Phased rollout

• Pages move to the new frontend one at a time
• Each stage is a separate release with its own metrics
• A/B testing where needed: part of the traffic on the old frontend, part on the new one
• Rollback is possible at every stage, just a routing switch

Phase 4 — Full switch

• Once all pages are migrated and metrics are stable, the old frontend is turned off
• Bitrix keeps running as the backend and admin panel
• The cutover is decided by data, not by a deadline

What stays the same

This is the question that matters most to the business. With a headless move, none of this changes:

• The Bitrix admin: managers keep working in the interface they know
• Content management: editing products, categories, and promotions works exactly as before
• Order processing: the order funnel, statuses, and notifications stay untouched
• CRM and integrations: 1C, inventory, and logistics all connect through the backend
• Managers' workflows: not a single non-technical employee will notice a difference

Headless changes what the user sees. Not what the manager sees.

What changes

The user and the technical team, on the other hand, get a fundamentally different experience:

• TTFB: 600 to 900 ms on Bitrix becomes 90 to 150 ms on Next.js. A sixfold speedup on the first byte.
• Independent deploys: frontend and backend ship separately. A design update no longer requires a backend release.
• Developer experience: React and Next.js instead of Bitrix PHP templates. A different level of tooling, development speed, and hiring.
• UX possibilities: animations, instant transitions, SPA behavior, offline mode. Everything that's out of reach with server-side templates.
• Scalability: the frontend lives on a CDN/edge, the backend stays isolated. The load on Bitrix drops several times over.

Managing risk

Every stage of the move is designed to keep risk low:

• Zero downtime: the new frontend runs in parallel with the old one. The switch happens at the routing level. Users see no interruption.
• Rollback at every stage: if metrics drop or a problem shows up, you revert to the previous version in minutes. Not hours, not days. Minutes.
• Staging environment: everything is tested before production. Load tests, functional tests, performance metrics. Only after confirmation does it go live.
• No production changes until sign-off: until the pilot is approved by all stakeholders, we don't touch production. Your current system keeps running unchanged.
• Incremental verification: each page moved to the new frontend goes through its own test cycle. Problems get caught locally, not after a full switch.

This isn't a "risky rollout." It's a controlled experiment with clear criteria for success and failure. If the data says "stop" at any stage, we stop and analyze. The decision is always yours.

Economics: subscription instead of capex

The traditional model, "pay for development, get a product," creates unpredictable costs. The budget grows, the timeline slips, and after launch you need a separate support team.

We work on a subscription model: a fixed monthly cost covers the frontend, updates, support, and an SLA. That means:

• A predictable monthly budget instead of capital spend. The CFO knows the exact figure 12 months out.
• Updates and improvements are part of the subscription. No separate invoices for "tweaks."
• No vendor lock-in. The code and infrastructure belong to you, and you can leave at any time.
• Cost scales with the business, not up front. You don't pay for peak load from day one.

For comparison: a typical full-migration project costs 5 to 15 million rubles up front, drags on for 6 to 12 months, and needs a separate support budget. The subscription model removes those risks.

The next step

Start with a 15-minute architecture review. We'll look at your current stack and tell you whether a headless approach fits your case. Or run a 2-week pilot: a real frontend, real data, real metrics. No commitment.

Product: Headless on Next.js and Elasticsearch