This year we moved a group of long-running online shops and business websites off a platform that had served them for more than a decade. Some had years of orders and enquiries behind them, and all of them were trading while we worked.
Replacing a system that people depend on is one of the riskier things a team can do. Here's what this one taught us, because the lessons apply to almost any replacement, from a website to the system that runs your office.
Find out what the old system really does
Documentation describes what a system was meant to do. Years of small changes mean it rarely describes what it does now. On this platform, much of each site's behaviour, including the whole of one shop's checkout, turned out to live in the data rather than the code: scripts stored in the database, invisible to anyone reading the source.
So we stopped reading and started observing. If the old system does something, the new one has to do it too, or someone has to decide, on purpose, that it shouldn't.
History comes with you
Switching off the old platform meant its records would go with it, so the history had to move. One shop had more than nine hundred orders going back to 2014. They needed to arrive exactly as the customers were charged, not as today's prices and delivery rules would calculate them. When we checked, today's rules would have produced a different delivery charge on about one order in twenty. History isn't something to recalculate; it's a record of what happened.
Even times needed care. The old system stored order times without saying which time zone they were in. The giveaway was the average order time, which shifted by almost exactly an hour between summer and winter: the clocks moved, not the customers.
A migration isn't finished when the new system works. It's finished when nobody can tell anything moved.
Keep the numbers people rely on
Order numbers and enquiry references end up in filing systems, email threads and people's memories. One site's enquiries had been numbered in sequence for years, so the new system carried on from exactly where the old one stopped. Nobody had to explain a gap, or a duplicate.
Compare, don't assume
We rendered every page on both the old and the new site and compared them automatically. At first, fewer than half matched. We worked through the differences until every one that remained was explained, and most of those were the new site being more correct, such as no longer showing a product that had been withdrawn years before.
Make it repeatable
Because the old sites kept trading during the work, a one-off copy would have been out of date by the time we used it. Every import was built so it could be run again safely, bringing across only what had changed. On the day of each switch-over, the final run was routine.
Move one piece at a time
Each site moved on its own, when it was ready, rather than everything on one big day. Problems stayed small, and each move made the next one easier.
If you're living with a system that's reaching its limits, and the thought of replacing it is what's stopping you, let's talk. It's very doable with the right approach.