June 24, 2026, Luboš Zápotočný
Replatform or fix? How to tell
A migration is a year of work that is often sold as a quick fix. How to tell whether the platform is the problem or the implementation is.
When a shop has problems everywhere (slow pages, high-risk upgrades, every change more expensive than it should be), replatforming starts to look like the solution. A fresh platform, a clean codebase, all the accumulated technical debt left behind. Agencies rarely advise against it; a migration is among the largest projects they can sell.
The arithmetic is worth stating plainly: a real migration is typically six to twelve months of work for a mid-size store, and longer for large or heavily customized ones, a feature freeze while it happens, an SEO risk at cutover, and reworking the platform side of every integration coupled to the platform’s APIs. Sometimes it’s worth all of that. But the decision deserves a diagnosis first.
Most problems originate in the implementation
The first question to settle: are the problems caused by the platform, or by what was built on it? In our experience the majority of “we’ve outgrown the platform” cases are actually:
- An accumulated extension stack. Dozens of modules, some abandoned, some conflicting, each added for one campaign years ago. The slowness comes from the pile of modules, not from the platform.
- Unmaintained hosting. The shop sits on infrastructure sized and configured once, long ago. Caches misconfigured or missing, no CDN, a database whose indexes have never been reviewed.
- A frontend problem that gets blamed on the platform. On Magento specifically, Luma’s architecture makes the whole shop appear slow even when the backend performs well.
- One catastrophic customization. A single early fork of core behavior that made every subsequent upgrade dangerous. Expensive, but removable for a fraction of a migration’s cost.
None of these disappear on a new platform. A migration run by the same process that created them reproduces the same problems on the new platform, and costs a year getting there.
When the platform genuinely is the constraint
Real platform ceilings exist, and pretending otherwise is the opposite error. The honest signals:
- End of life. Magento 1 today, others tomorrow. Once official security patches stop, the migration is almost certainly coming; unofficial third-party patching can buy time, but only delays it.
- An architectural ceiling you’ve actually hit. Not “the demo of the other platform looks faster,” but a named requirement the platform cannot meet: checkout customization the tier doesn’t allow, B2B workflows extended beyond their limits, a catalog model that fundamentally doesn’t fit.
- The upgrade path is gone. So many skipped versions and custom patches that getting current costs as much as leaving.
- The economics inverted. License plus specialist maintenance costs more per year than the platform returns in capability.
One signal deliberately missing here is “the developers prefer the other one.” That’s a tie-breaker at best.
The low-cost experiment before the expensive decision
You don’t have to decide from opinion. A structured audit settles the underlying question (where the problems originate) with measurements: how much of the slowness is backend versus frontend, which extensions cost what, what the hosting configuration fails to deliver. Then price the two paths side by side: fix-in-place as a ranked list of changes with estimated impact, versus migration with data, integrations, and SEO preservation costed in.
Sometimes the audit says migrate. We run migrations, and we’ll say so plainly when the platform really is the ceiling. But we’d rather base that recommendation on measurements than on one bad quarter’s frustration. If you’re facing this decision right now, get in touch before you sign a migration contract.