Leaving SaaS without a big bang

When a company decides to leave a system that holds it back, the first instinct is a big switchover plan: a new system, a go-live date, a migration weekend, and on Monday everyone works in the new one. That plan has one advantage — it looks good on a slide. Its disadvantages show up on Monday at 9:15.

Why the big bang fails

The old system does more than anyone remembers. A report someone runs once a month. A rule that has quietly blocked shipments to customers in arrears for years. The courier integration configured by someone who left long ago. A migration plan describes what the company knows about its system. Monday shows the rest.

On top of that, a big bang bets everything on one hand. If something goes wrong you cannot roll back one process — you roll back everything, and the team’s trust in the change rolls back with it.

Moving out brick by brick

The safer pattern has been known for a long time: the new system grows next to the old one and takes over one piece at a time, until the old one has nothing left to do. It sounds slower. In practice it usually finishes sooner, because nothing has to be undone.

Step one: the data leaves first. Before you change any process, set up continuous sync from the old system into a store that is yours. From that day the company’s memory stops being a hostage — and every later step already reads from your own place.

Step two: one process, preferably a boring one. Pick a process that is frequent, well described and not too risky. Build it in the new stack, run it in parallel with the old one and compare results for a few weeks. Switch only when they agree.

Step three: cut off, do not switch off. Once a process has moved, the old system keeps running; that piece simply stops being used there. Remove the permissions, close the screen, keep the data. Switching off comes at the very end.

Step four: repeat. Each further process goes faster, because the data, the way of testing and the team’s trust are already in place.

What to work out before you start

• The contract term. Moving brick by brick takes time — check when you can reduce seats or scope, so you are not paying for a full system while using half of it.
• A full export, relations included. Test it at the very start. If the export loses the links between records, that is the first problem to solve, not the last.
• A list of hidden functions. Walk through every report, automation and integration in the old system. Each item is either a piece to move or a deliberate decision that it is no longer needed.
• A process owner. Every process that moves needs someone who knows it and will sign off that the new version does the same thing — or better.

In the end the old system goes dark on its own

The best move-out is one where nobody notices the switch-off day, because nobody has logged into the old system for months. No migration weekend, no Monday panic, no rollback.

The barbarians who win do not storm the castle. They carry its bricks out and build their own house next to it — and one day the castle stands empty and nobody remembers when they left.