---
title: "Replatform or fix? How to tell"
description: "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."
author: "Luboš Zápotočný"
published: "2026-06-24"
language: "en"
canonical: "https://zapolu.com/blog/replatform-or-fix/"
---

# Replatform or fix? How to tell

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](/blog/hyva-vs-luma/) 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](/services/performance-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](/services/platform-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](/contact/) before you sign a migration contract.