The one decision that shapes your entire replatforming project

You know your commerce stack needs modernizing. The question is not whether to move - it is how to sequence the move without the project collapsing under its own weight.

At the center of that question is a single decision: do you start with the backend (OMS, checkout, product data) or with the frontend (storefront, campaign pages, customer experience)? That sequencing choice determines your risk profile, how your budget behaves over time, and how soon you can show measurable results.

This guide is written for the people who own the decision: COOs, CTOs, CFOs, and anyone signing off on the roadmap. No architecture deep-dives, no stack comparisons. Just: which sequence carries less risk, delivers value earlier, and keeps your budget predictable?

Option A: Backend-first - what it promises and what it actually costs

Backend-first is the instinct most companies reach for. Stabilize the foundation, then build the house. In practice: you replace the platform, OMS, ERP integration, or checkout layer first, while the frontend keeps running on the legacy system.

The case for backend-first

• Clean data from day one: your new frontend inherits a stable, well-mapped data layer.
• No double integration work: one connector layer instead of two parallel ones.
• Clear handoff: once the backend is stable, the frontend follows on solid ground.

What backend-first costs in practice

The problem is time. A backend replacement in mid-market commerce typically takes 9 to 18 months, depending on catalog complexity, checkout logic, and ERP integrations. During that window:

• No visible progress: marketing and commercial teams see nothing change for months. The storefront looks like it did in 2021 because the frontend is frozen.
• Parallel systems as a cost driver: you are paying twice. The legacy system continues running (licenses, hosting, support) while the new system is under construction (development costs, integration work).
• SEO risk at cutover: after 12 months of backend work, the new frontend often gets built in 6-8 weeks under time pressure. URL structure, internal linking, and content migration all happen in a rush. Documented SEO drops of 20-40% in the first weeks after a poorly planned cutover are not unusual.
• Abort risk: the longer a project runs before delivering visible value, the higher the probability that budget or organizational energy runs out first.

Backend-first is not the wrong approach in every case. But it requires your budget to absorb 18 months of parallel operating costs and your organization to stay aligned without visible results.

Option B: Frontend-first - decoupling as Phase 1

Option B reverses the order: decouple the frontend first, address the backend later.

What a decoupled frontend actually means

A decoupled frontend running on a Frontend Management Platform (FMP) sits as an independent layer on top of your existing backend. Shopify, Shopware, OXID, Magento, commercetools - it does not matter. You keep the backend as-is. The new frontend talks to it via API.

The result: you renovate the house without touching the foundation.

What frontend-first delivers

Phase 1 (weeks 1-10): decouple the frontend

• New storefront goes live on a composable basis, backend unchanged.
• Marketing teams manage campaign pages, product worlds, and seasonal promotions without developer tickets.
• Performance gains are immediate and measurable: typical results after frontend decoupling include LCP under 1.5 seconds versus 3-4 seconds before. Conversion rates follow.
• SEO continuity: URL structure stays intact because backend routing is not touched.

Phase 2 (after a successful frontend launch): replace the backend

• You approach the backend decision from a different position: the frontend is independent. The backend cutover is no longer a relaunch - it is a connector swap.
• No time pressure on frontend design, because the frontend is already live and stable.
• Parallel operating costs drop: the legacy frontend is gone, the new frontend carries the load.

What frontend-first costs and where the real risks sit

To be direct: frontend-first is not without challenges.

• Double data maintenance during the transition: as long as the old backend runs, you manage product and pricing data there. That changes only with Phase 2.
• Parallel phase complexity: if Phase 2 (backend replacement) starts before Phase 1 is fully consolidated, coordination complexity rises. Clear milestones and a go/no-go gate between Phase 1 and Phase 2 are not optional.
• Dependency on legacy API quality: if your existing backend has unstable or poorly documented APIs, decoupling is harder. This needs to be assessed before you commit.

Decision framework: when to choose Option A and when to choose Option B

Not every business fits the same sequencing. Here are the criteria that carry the decision:

Option A (backend-first) fits better when:

• Your backend is fundamentally broken: data loss, no API capability, end-of-life system with no support path
• You have a clear 18-month budget runway, including parallel operating costs
• The frontend experience is not a competitive disadvantage today (B2B catalog reorder, low conversion pressure)
• Your team has strong backend expertise and limited frontend capacity

Option B (frontend-first) fits better when:

• Your backend is stable but the storefront is outdated or too rigid for marketing requirements
• You need visible results within 3 months, not 18 (internal stakeholders, budget approval cycles)
• Your replatforming budget is constrained and needs to be invested in phases
• SEO is a material channel for you (frontend-first protects URL structure and rankings better)
• You want to isolate backend risk: if Phase 2 turns out harder than expected, Phase 1 has already delivered substantial value

TCO perspective: what does each sequence cost over 3-5 years?

Most replatforming calculations focus on initial spend. The number that matters is total cost of ownership over 3-5 years.

Backend-first scenario (typical mid-market):

• Legacy system costs during backend rebuild: 9-18 months of full license and hosting budget
• Frontend build under time pressure after backend go-live: often 20-30% higher development costs due to compressed timelines
• SEO recovery after a poorly planned cutover: 3-6 months of reduced organic traffic

Frontend-first scenario with an FMP:

• Phase 1 delivers a productive new storefront within 8-12 weeks
• Legacy backend continues running, but expensive frontend hosting and frontend development costs drop from Phase 1 go-live onward
• Phase 2 (backend replacement) starts without time pressure, since the frontend is already live
• TCO advantage over 3 years: depending on stack and complexity, typically 25-40% lower than a backend-first big-bang approach

These are directional numbers, not guarantees. Every project is different. But the logic holds: closing Phase 1 (frontend) quickly eliminates months of parallel dual costs and reduces the abort risk of the overall project.

The recommended decision path for mid-market

If you are operating between 5 and 50 million euros in annual revenue and planning your replatforming, this is the path we see succeed most consistently:

Step 1: Backend readiness check (2-4 weeks)

Verify that your existing backend is API-capable. Most Shopware, Shopify, OXID, and Magento systems are. If yes, frontend-first is immediately viable.

Step 2: Phase 1 frontend decoupling (6-12 weeks)

New storefront on a composable basis via API on the existing backend. Go live with full marketing control. Zero backend risk.

Step 3: Consolidation and assessment (4-8 weeks)

The new frontend is live. Measure conversion trajectory, SEO performance, and marketing velocity. Only once Phase 1 is stable do you decide when and whether to start Phase 2.

Step 4: Phase 2 backend replacement (on your own timeline)

With a stable frontend already running, the backend replacement is a connector swap, not a relaunch. Time pressure is gone. The risk is isolated.

What you can do next

Replatforming decisions are not single-sprint projects. But the sequencing question is solvable if you ask it early.

If you want to assess your existing headless frontend setup or structure your composable commerce roadmap, the Laioutr UI Platform is built specifically for this sequencing: decouple the frontend without touching the backend.

For a related starting point on protecting your existing investments through a composable transition, see: Saving Existing Investments During a Composable Migration.

Related resources:

• Headless Frontend Hub
• Laioutr UI Platform
• Composable Headless Frontend
• What is a Frontend Management Platform?
• Saving Existing Investments During a Composable Migration