How to replace an old business system without a six-figure rebuild

If you've asked for a quote to replace an old business application, you've probably seen the usual shape. There's a discovery phase, then a long build, then moving all your records over, and a go-live date somewhere past the middle of next year. You write a large check at the start and find out whether it worked at the end.

The price is one thing, but the bigger problem is the order things happen in. Everything you learn shows up after the decisions have been made, and the first day your team uses the new system is also the day it has to work.

Why the all-at-once rebuild goes wrong

A system that's been running for ten years has picked up a decade of exceptions along the way. There's the customer you bill differently, the process that skips a step every November, and the report one department relies on that nobody else has ever opened.

None of that is written down. Most of it isn't even a rule in anyone's head, just a habit, the way people have always done it. A rebuild based on a written specification will miss those things, and nobody will notice until go-live week, when everyone is already on edge.

Replace it one piece at a time

The other way to do it is to stop treating the old system as one big thing. Most business applications are really several smaller ones sharing the same data, because that was convenient in 2009. One part takes orders, another handles scheduling, another does the reporting, and another does the billing.

You can replace those parts one at a time. Start with the one that causes the most trouble and is least tangled up with everything else, and build a replacement for just that piece. The old system keeps doing everything else in the meantime.

Run the old and new side by side for a while

This is the step people tend to skip, because doing the same job twice feels wasteful. It's also the biggest single thing you can do to lower the risk.

For a period, both systems handle the same work and you compare the results. Do the numbers match? Did the new one cope with that odd November case? This is where the unwritten exceptions come to light, while the old system is still there as a safety net. Finding them now is a lot better than finding them at 6am on switchover day.

Move your records over in stages

Moving the data is where these projects tend to go over budget, and the reason is rarely technical. The records in a ten-year-old system are messier than anyone expects. You'll find duplicates, records in states that shouldn't be possible, and fields someone started using for something else entirely years ago.

Moving records in stages means you find that out early, on one slice of the data, while there's still time to decide what to do about it. Moving everything at once means finding it out during the switchover, when every option is a bad one.

Switch the old system off properly

Eventually the old system will be doing nothing except holding history. That's when to shut it down properly. Archive whatever you're legally required to keep, write down what you're switching off, and then switch it off. Old systems left running because nobody's sure it's safe to stop them are how businesses end up in this same position ten years later.

What this looks like in practice

Your team gets something they can use in the first month or two. You pay as you go rather than all up front. The surprises turn up around week three, when they're still cheap to deal with, instead of month eight, when they aren't. And if your priorities change halfway through, you can stop with a working piece in use and something to show for the money you've spent.

The nine-month estimate isn't wrong about how long it takes to replace the whole system. Doing it in pieces just means you start getting something back from the project much sooner, instead of waiting until the very end.