Most B2B businesses do not decide overnight that their store needs rebuilding. The decision drags on for years, with workarounds, compromises and a hope that the system will keep coping. By the time it is made, the cost and disruption are often higher than they needed to be.
Knowing something feels wrong is the easy part. The hard part is knowing when fixing the current platform has stopped being enough.
Signs that fixing has stopped working
Fixes stop sticking
Every platform needs maintenance, but there is a point where each fix creates another problem and new features feel risky because they might break something unrelated. The architecture still works. It just no longer supports the way the business wants to operate.
Performance work stops paying back
Slow pages and patchy search are often fixable. When they come back after repeated optimisation, as the catalogue and the integrations grow, it is fair to ask whether the platform itself is the limit.
Security debt keeps growing
Unsupported extensions, an old framework version and patches that keep getting delayed add up quietly. A breach or a long outage damages trust quickly, and at that point the platform has become a board-level question.
The platform is shaping the business
The clearest sign is when commercial decisions are being made around what the system can handle. Ranges get cut, pricing models get simplified and account features get dropped because the store cannot cope with them.
None of these on its own means rebuild. Several together usually do. Waiting feels cautious, but it has its own cost, in orders lost and in staff working around the system.
If you do migrate
Migrations are rarely talked about honestly. Case studies focus on the launch date and the new design and skip the trade-offs. These lessons come up again and again, many of them from long-running Magento 1 stores that had grown for years before they moved.
The worries are reasonable
Downtime that hits sales, data lost or corrupted on the way, and integrations that quietly kept the business running failing in subtle ways. Then a like-for-like move that grows once hidden dependencies surface. Leaders who hesitate are usually aware of real risk rather than resisting change, and a good plan treats those worries as the list of things to plan for.
Plan before the deadline does it for you
The biggest difference between a smooth migration and a painful one is preparation. Timelines driven by an end-of-life date or internal pressure lead to compromises that last for years. Map the data, integrations, pricing rules, customer accounts and day-to-day workflows first. Decide what genuinely needs to move, what should be improved on the way and what can be retired. Otherwise the business rebuilds its old problems on a new platform, which happens more often than anyone admits.
B2B features are not edge cases
Account pricing, contract terms, restricted catalogues and approval workflows build up over years. During a migration they are easy to treat as awkward exceptions to the platform's defaults. Simplify them to hit a launch date and the site goes live on time, but sales staff step back in to handle what it can no longer do and the channel loses credibility. Keep the buying process and improve how it works.
Clean the data before you move it
Old platforms carry years of duplicated, outdated and inconsistent data. Moving it all just moves the problem. Cleaning and restructuring it first takes time, and it pays back after launch, when there are fewer surprises and the catalogue is easier to keep right.
Phase it where you can
Rebuilding does not have to mean switching everything over in one weekend. Delivering in phases, with a clear objective for each one, beats a rushed big-bang move whichever platform you are moving to. Customers should notice that things carried on working.
Making the call
Deciding whether to rebuild or keep improving is a business decision, and making it is not an admission that something failed. The aim is to make it before the cost of doing nothing is bigger than the disruption of changing.
The rebuild or improve check gives a first read in a few minutes. For an answer based on the code itself, an Adobe Commerce audit will tell you whether to stay, fix or move.
