New: CentriCall AI voice agents that answer, qualify, and book around the clock
Centricone Technologies
eCommerce replatforming

Replatforming to headless commerce, one slice at a time

Moving a live store to a headless architecture is not a rebuild you reveal on a launch date. It is a migration that has to keep taking orders throughout. We plan it as a sequence of small, reversible cutovers — and we start by checking that headless is actually the fix for the problem you have.

Book a replatforming assessmentAll Software management services

Before you migrate

Decide the problem before you decide the architecture

Headless pays for itself in three situations: several storefronts on one commerce back end, a front end that a theme cannot express, and content and commerce that live in separate systems. If your pain is slow pages or a brittle integration, a new front end can leave both unchanged, or make them worse for a while. The first week of an engagement is spent finding out which problem you have, and we will tell you if the answer is that you should stay where you are.

Scope

What a replatforming engagement covers

Fit assessment and target architecture

What the current platform does well, where it blocks you, and whether the fix is headless, a different platform, or work on the existing one. Output is a decision with reasons, not a vendor shortlist.

Catalogue, pricing, and inventory integration

The commerce back end stays the system of record. We design the API layer, caching, and invalidation so the storefront shows correct stock and price without hitting the origin for every request.

Checkout and payments

The highest-risk surface, so it moves last. Hosted or embedded checkout, payment provider behaviour, tax, shipping, and the failure modes of each — designed before the first customer reaches them.

SEO-safe migration

URL structure preserved or redirected one-to-one, structured data and metadata carried across, sitemaps and canonicals checked, and organic traffic watched slice by slice. A replatform that loses its rankings has failed whatever the performance numbers say.

Performance and rendering strategy

Static generation, incremental regeneration, or server rendering chosen per page type against how often its data changes — and budgets set for Core Web Vitals before the work starts, so they can be checked.

Handover and operations

Runbooks, monitoring on the paths that earn revenue, and a team that understands the architecture well enough to change it. A storefront only we can maintain is a worse position than the one you started in.

How we cut over without a launch day

The reason to migrate in slices is that every slice is a real test with a small blast radius. By the time the highest-traffic pages move, the approach has already survived production.

Talk it through
  • Traffic moved behind a routing rule, one category or page type at a time, with the old storefront still serving everything else
  • A mid-volume category first, so the earliest real traffic teaches the team something without putting the best-selling pages at risk
  • Checkout and cart last, once catalogue and category pages have proven rendering, caching, and integration at real volume
  • A rollback that is a routing change, not a redeploy — rehearsed before it is needed

Tooling

What we work in

Storefront

  • Next.js
  • React
  • TypeScript
  • Vercel
  • Edge caching

Commerce back ends

  • Shopify and Shopify Plus
  • BigCommerce
  • Adobe Commerce (Magento)
  • Commerce APIs

Content and search

  • Headless CMS
  • GraphQL
  • Algolia
  • Elasticsearch
  • PostgreSQL

Questions

What teams ask before they migrate

Separating the storefront your customers see from the commerce engine that holds the catalogue, prices, orders, and customers, and connecting the two through APIs. Replatforming is the migration of a live store onto that architecture. The back end usually stays; the front end is rebuilt and moved across in stages.
It depends on catalogue size, integrations, and how custom the checkout is, so we scope it after an assessment rather than quoting from a brochure. As a rough shape, a mid-sized store with a handful of integrations is a matter of months, with the first slice of live traffic arriving well before the end. Anyone who quotes a launch date before seeing your integrations is guessing.
Not if the migration treats SEO as a requirement rather than a check at the end. URLs are preserved or redirected one-to-one, metadata and structured data are carried across, and organic traffic is monitored per slice so a problem shows up on one category and not the whole catalogue. Moving in slices is the main protection.
Often stay. A modern hosted platform with a good theme handles most stores well, and headless adds a codebase to own, a hosting bill, and a team that has to understand it. It earns its place with multiple storefronts, a front end a theme cannot express, or content and commerce in separate systems. The longer version is in our article on when headless is worth it.
No. Most headless migrations keep the existing commerce back end and replace only the storefront. Changing the platform as well stacks a second large risk on the first, so we separate the two decisions and do not bundle them unless there is a reason to.
Last, and carefully. Catalogue and category pages move first because a problem there does not stop orders. Checkout moves only once those slices have proven the approach at real volume, and it keeps a tested path back to the previous checkout until the new one has carried real peak traffic.

Related