Compare · 2026
Replatform vs rebuild — when you've outgrown your stack.
The hardest commerce decision most retail leaders make twice in a career. Real cost math, real failure modes, and the third option most agencies forget to mention.
30-second verdict
Three paths. Most agencies discuss two.
The third option — stay and modernize — is the right answer more often than the commerce industry admits.
Replatform
~50%Move from one platform to another (Magento → Shopify, BigCommerce → Shopify Plus, etc).
Best when
Your current platform's ceiling is the bottleneck and the next platform clearly meets your needs.
Stay & modernize
~30%Hollow out the painful surfaces (search, checkout, OMS) as headless services. Keep the core.
Best when
Pain is concentrated in 2–3 surfaces, not the platform itself. Cheapest, fastest, lowest risk.
Rebuild
~20%Custom commerce engineered from scratch. Own the model, own the maintenance.
Best when
Your model breaks every platform AND you have a sustained engineering team to own it for 5+ years.
The 7 dimensions
Side by side, with the failure modes named.
Each path has a way it goes wrong. We've named it under each option — because the right call is the failure you can survive, not the upside you most want.
Upfront cost
Rebuild is 3–5× more upfront. Math only works if the 5-year platform tax exceeds the delta.
Replatform
$200K–$1.5M depending on platform + scope.
⚠ How it fails
Vendor onboarding + per-app subscriptions creep past budget once procurement signs the master contract.
Stay & modernize
$50K–$300K modernization sprint.
⚠ How it fails
Cheap upfront, but you keep paying yearly in workarounds that quietly compound.
Rebuild
$800K–$5M+ depending on scope.
⚠ How it fails
Most rebuild estimates are 60% of the real bill. Edge cases, hardening, and post-launch ops are routinely under-scoped.
Time to value
Stay-and-modernize wins until the platform itself becomes the blocker.
Replatform
16–28 weeks to launch parity.
⚠ How it fails
Last-mile data parity (orders, accounts, gift-cards) blows the launch window — the 80/20 cuts the wrong way.
Stay & modernize
6–12 weeks per modernization slice.
⚠ How it fails
Slice-by-slice progress feels good but never reaches a coherent end-state.
Rebuild
8–18 months to launch parity. 24+ months for a full custom OMS.
⚠ How it fails
Time-to-value death spiral: 18 months in, the business has moved and the original spec is wrong.
Risk profile
Pick the failure mode you can actually survive.
Replatform
Medium. Platform handles infra, you handle migration.
⚠ How it fails
Big-bang cutovers fail loudest — SEO collapse, checkout outages, integration re-wires that take 3× longer.
Stay & modernize
Low. You're already running it.
⚠ How it fails
Death by debt — the platform quietly stops being able to do what the business needs.
Rebuild
High. You own everything. Phased rollout is mandatory.
⚠ How it fails
Key-person dependency. The senior engineer who designed the system leaves; the team can't safely change it.
5-year TCO @ $50M GMV
Ranges overlap heavily. Differentiator is whether the platform ceiling becomes a tax or a non-issue.
Replatform
$2.5M–$5M (license + dev + ops).
⚠ How it fails
Vendor pricing tier-jumps as GMV grows. The 5-year line you signed for is rarely the 5-year line you pay.
Stay & modernize
$2M–$6M (existing platform + workarounds + ops).
⚠ How it fails
Workaround cost is invisible — you only see it when senior engineers spend half their week on platform glue.
Rebuild
$3M–$8M (build + sustain + infra).
⚠ How it fails
Sustaining engineering is the line nobody costs honestly. A custom system needs 2–4 FTEs forever.
Team capability needed
If you don't have a senior team and won't build one, rebuild is the wrong door.
Replatform
Platform-specialist team for migration; ongoing platform admin.
⚠ How it fails
Specialists are scarce + expensive at the platform you're moving to. Hiring lag stalls the project.
Stay & modernize
Existing team + targeted external help.
⚠ How it fails
External help becomes a permanent dependency — you never build the in-house muscle to escape.
Rebuild
Senior + principal engineering, system design, sustained ops capability.
⚠ How it fails
Without principals, the architecture rots within 18 months. Without ops capacity, day-2 reliability tanks.
End-state ownership
Ownership cuts both ways.
Replatform
You rent the platform forever. Pricing controlled by vendor.
⚠ How it fails
Vendor changes pricing or sunsets a feature; you have no bargaining power and no escape hatch.
Stay & modernize
Same as today, slightly better.
⚠ How it fails
Renting old debt instead of new debt. Same dependency, worse vintage.
Rebuild
You own it forever. Maintenance is yours forever.
⚠ How it fails
You own the upside AND the downside. Most brands underestimate the downside.
Customization ceiling
If your roadmap fits inside the platform's API, replatform. If it doesn't, rebuild. If you don't know, you don't need to rebuild yet.
Replatform
Hard ceiling at platform's customization API.
⚠ How it fails
Hit the ceiling 18 months in and you're stuck — back to choosing rebuild from a worse starting point.
Stay & modernize
Same as today.
⚠ How it fails
Today's ceiling is also next year's ceiling. The roadmap stops at the platform's edge.
Rebuild
Effectively unbounded.
⚠ How it fails
Unbounded freedom = unbounded scope. Without a hard product spec, the build never converges.
When each wins
The signal-from-noise checklist.
Replatform wins when
- 1You've outgrown the current platform's catalog / customization / B2B ceiling — but the next platform clearly meets your needs.
- 2Maintenance cost on the current platform exceeds 30% of engineering capacity.
- 3The current platform is end-of-life or losing vendor investment (Magento Open Source, SFCC legacy versions).
- 4Your team is mid-sized (5–15 engineers) and can absorb a 4–6 month migration.
- 5You don't need customization beyond what the next platform allows.
Stay-and-modernize wins when
- 1Your current platform mostly works — the pain is concentrated in 2–3 specific surfaces.
- 2You're early ($5M–$30M GMV) and replatform / rebuild cost is disproportionate to scale.
- 3You can extract the painful surfaces (search, checkout, OMS) into headless services without replacing the core.
- 4You don't have the engineering bandwidth for a 6+ month parallel project.
- 5Migration risk to revenue (especially seasonal — gifting, beauty, apparel) is unacceptable in the next 12 months.
Rebuild wins when
- 1Your model breaks every off-the-shelf platform — custom OMS, proprietary pricing engine, unique fulfillment.
- 2You operate at scale where platform per-GMV pricing exceeds the build cost over 5 years.
- 3Compliance / data residency / sovereign cloud forces self-hosting anyway.
- 4Customization is your competitive moat, not a side project.
- 5You have a 10+ engineer team capable of sustaining custom infrastructure long-term.
- 6Legacy code that pre-dates modern platforms still drives revenue and can't be cleanly extracted.
When rebuild was the right call
Enterprise US gifting retailer — JSP/Java to React/Spring Boot.
60 → 90PageSpeed lift, no revenue freeze
A real example of when rebuild was the right call. Decade-old JSP + Java monolith, customizations no platform could absorb, holiday-traffic peaks no SaaS could safely handle. Multi-year phased rebuild, old + new in parallel until parity proven.
Read the case studyThe honest take
The order we'd consider if we were sitting in your job.
- First →
Try stay-and-modernize.
Identify the 2–3 surfaces causing 80% of the pain. Headless them out. Keep the platform. 6–12 weeks per surface, no migration risk.
- If that fails →
Replatform.
If the platform itself is the bottleneck and the next platform clearly meets your needs, replatform. 16–28 weeks, parity-first cutover, old + new in parallel.
- Only then →
Rebuild.
If both above are wrong because your model genuinely breaks every platform, rebuild. Phased, multi-year, with a sustained engineering team. Custom commerce is where Destm actually wins.
FAQ
Questions buyers ask us in the first call.
QHow do I know if my platform is actually the bottleneck — or just my team's frustration with it?
How do I know if my platform is actually the bottleneck — or just my team's frustration with it?
Three tests. (1) Is engineering velocity dropping >20% year-over-year on the same headcount? (2) Are at least 3 strategic features in the last 6 months blocked by 'the platform can't do that'? (3) Is the platform's recurring license + extension cost growing faster than GMV? Two of three = real bottleneck. One of three = your team needs help, not a new platform.
QCan we do a hybrid — keep the platform but rebuild the parts that hurt?
Can we do a hybrid — keep the platform but rebuild the parts that hurt?
Yes — and this is actually the most common 2026 pattern. Keep Shopify Plus / Adobe Commerce as the catalog + checkout. Rebuild the OMS, search, pricing engine, and merchandising as headless services. We call this 'hollow out the monolith' and ship it on every other engagement.
QWhat's the biggest hidden cost of a rebuild?
What's the biggest hidden cost of a rebuild?
Sustained ownership. The build is the easy part — keeping it running for 5+ years, hiring the team, paying down its own technical debt, integrating with new platforms as the ecosystem evolves. Brands that rebuild and then can't sustain end up worse off than if they'd replatformed.
QHow phased should a rebuild be?
How phased should a rebuild be?
Brutally phased. Phase 0: discovery + architecture (2–4 weeks). Phase 1: one real production surface running against real data (8–12 weeks). Phases 2+: each ships behind a flag, with rollback, until the new is provably better than the old. Big-bang rebuilds fail. Phased rebuilds succeed.
QWhat about composable / MACH — does that count as replatform or rebuild?
What about composable / MACH — does that count as replatform or rebuild?
Composable sits in between. You're 'replatforming' to a set of best-of-breed services (commercetools + Algolia + custom checkout + custom OMS) but the integration work is closer to a rebuild than a single-platform migration. We treat it as its own path — see /solutions/headless-commerce.
QDestm has shipped both — what's your bias?
Destm has shipped both — what's your bias?
We ship more replatform than rebuild because the math fits more brands. Rebuild is where Destm's actual moat is — 13 years on custom retail codebases, JVM Java + Spring fluent, enterprise US retailer codebases. We name it as the right answer when it is, and tell you to replatform when that's the right answer instead. We're paid to be right, not to upsell.
How an engagement starts
Three steps to a partnership
Intake call
30 minutes. We listen, you talk. No deck.
Diagnostic
We audit the surface, name the bottleneck, propose a path.
Kickoff
Senior engineer in your standup by week two.