A Magento store that has fallen several versions behind carries two problems at once. It misses performance improvements, and more urgently it stops receiving security patches. Both get worse with time and neither fixes itself.
The choice is rarely between doing nothing and rebuilding. It is between an upgrade path that keeps what you have and a migration that starts cleaner, and the right answer depends on things you can assess before spending anything.
What makes an upgrade expensive
Upgrading is not one project, it is a series of compatibility problems. The cost is driven almost entirely by what was added over the years:
- Extensions. Every one has to have a compatible version, be replaced, or be rebuilt. This is usually the largest single factor.
- Custom code. Modules written against older interfaces need work. Undocumented custom code needs more.
- Theme overrides. Templates copied and edited years ago drift further from the core with every version.
- Version distance. Several versions behind often means going through intermediate steps rather than jumping.
When migrating is the better spend
Migration means moving the data to a fresh installation rather than dragging the old one forward. It sounds more expensive and sometimes is not.
- When most extensions are no longer used. If you are upgrading twenty extensions and using eight, you are paying for twelve you should have removed.
- When nobody knows what the custom code does. Upgrading code nobody understands is expensive and risky; rebuilding what you actually need is neither.
- When the design is due anyway. If a redesign is coming in the next year, doing it as part of a rebuild avoids paying twice.
- When the store is several versions behind. At some distance the upgrade path costs more in intermediate steps than a clean build.
What you keep either way
Both routes keep your catalogue, customers, orders and URLs. Migration does not mean losing history; it means moving it to a cleaner installation. That matters for SEO, because your existing URLs and rankings carry over in both cases when it is done properly.
What differs is what you keep of the accumulated technical debt. An upgrade brings it along. A migration is a chance to leave some of it behind, and that is often the real argument.
The thing not to do
Postpone. An unsupported version is a security exposure that grows every month, and the upgrade only gets more expensive as the distance increases. If budget is the constraint, an upgrade in phases beats waiting for a year when the whole project fits in one budget cycle.