Replace Legacy Software Without Downtime, One Workflow at a Time

• Software that was built properly years ago and simply got old needs a different answer than a prototype you outgrew. Usually some of it should stay.

• Decide part by part: keep, fix, integrate, migrate or rebuild. One verdict for the whole system is how big-bang rewrites start.

• Replace one workflow at a time while the old system keeps running everything else.

• Rehearse the data migration until it’s boring, run old and new side by side for at least one full business cycle, and don’t cut over without a written way back.

• Name the person who owns the old system until each replacement is formally accepted. Outages happen in the gap between “we’re replacing it” and “it’s replaced”.

Your system was built years ago, everyone’s scared to touch it, and you can’t switch it off. Orders, invoices, schedules or client records run through it every day. The developer who knew it best has moved on. Each change takes longer than the last, and nobody will promise the next one won’t break something else.

This isn’t the no-code story, where a platform hits its ceiling, and it isn’t a prototype that was never meant to carry real customers. It was written properly, by people who knew what they were doing. Then years of changes got layered on, the documentation stopped being updated, and the parts it depends on went out of support. The question now is how to replace legacy software without downtime, when the business can’t stop to let you.

Most of the advice on this is written for enterprise IT departments with a program office and a migration team. You probably have an operations lead, a contractor who knows part of the code, and a business that has to keep invoicing on Monday. The principles carry over. The size of the plan shouldn’t.

There’s often a deadline hiding in it, too. Microsoft’s lifecycle page for SQL Server 2016 shows its extended support ending in July 2026, with Extended Security Updates listed as the bridge after that, and Microsoft’s page for Windows Server 2016 shows the same point arriving in January 2027. If your system dates from that era, find out what it runs on. An end-of-support date is a real reason to move. “It feels slow” usually isn’t, on its own.

The obvious plan is to build a new system beside the old one, then switch everything over on a weekend. Martin Fowler’s write-up of the strangler fig approach describes how that usually ends: “we’ve seen this simple-sounding plan go down in flames most of the time.”

The reason isn’t that rebuilders are careless. It’s that the old system is the specification. Years of fixes, special cases and “just this once” changes live in the code and nowhere else. Fowler puts it plainly: “Replacements seem easy to specify, but often it’s hard to figure out the details of existing behavior.”

A single switchover day then packs every one of those unknowns into a few hours, while the business is trying to work. And because a full rewrite takes months, the old system keeps changing underneath it. The target moves while you’re aiming at it.

That doesn’t mean a rebuild is never right. A platform with no upgrade path, a data model that can’t represent how you work now, or a security exposure nobody can patch are all honest reasons. Even then, a rebuild is a decision about the code. It shouldn’t also be a decision to switch everything over on one day.

An old system isn’t one thing. It’s a set of workflows, a database and some connections to other tools, and each part can get its own verdict.

A realistic plan mixes them: keep the core records, rebuild the one workflow that’s costing you most, and move a standard function to a product you can rent. One verdict for the whole system usually means nobody has looked closely enough yet.

That’s the shape our work with Unity Property Management took: a custom platform and mobile app replacing a costly per-seat portal, while the existing back-office system stayed in place for operations. Keeping a system is a decision, not a failure to finish.

Once you know which parts are being rebuilt or migrated, put them in order and move them one at a time. The old system keeps running everything that hasn’t moved yet. Each new piece goes live, gets used, gets accepted, and only then does the next one start.

Pick the first workflow carefully. It should matter enough that people notice the improvement, and be self-contained enough that a bad day doesn’t stop the business. Scheduling for one team is a reasonable first move. Month-end billing is a poor one.

For a while, the old and new systems have to share data. Sometimes the new piece reads from the old database; sometimes a sync copies changes across. Fowler calls this transitional architecture, code that goes away once the replacement is finished, and argues that “the reduced risk and earlier value from the gradual approach outweigh its costs.” Budget for it rather than being surprised by it.

Then decide, for every kind of record, which system is the source of truth during the transition. Two systems that can both edit the same customer will eventually disagree, and you want the rule written down before that happens.

Data migration is where the old system’s history comes due. Years of records entered by different people, under different rules, rarely map cleanly onto a new structure. You find that out in a rehearsal or on cutover day, and a rehearsal is cheaper.

• Use a full copy of real data, not a sample, in a safe environment. The odd records are the point.

• Reconcile the totals. Record counts, open balances, active customers, jobs in progress. They should match, or the difference should be explained.

• Have the people who use the data check it. Ask each to look up twenty records they know well in the new system. They’ll spot what a script won’t.

• Time it. How long the move takes decides how long your cutover window has to be.

• Fix, then run it again. Repeat until two rehearsals in a row come out clean, with nothing explained away.

Decide what moves at all. Active records and open work have to come across. Years of closed history may be better kept in a read-only copy of the old system that people can still search. That’s a business decision about what you need to look up and what you’re required to keep, so make it with whoever owns those records, not only with the developer.

Before each cutover, run the old and new systems side by side on the same work for a defined period. Compare the outputs every day: the invoices, the schedules, the totals. Set the length in advance and make it cover at least one full cycle of whatever matters most, such as a month-end close or a billing run.

Parallel running costs something. Staff do some work twice, or someone reconciles two systems every day. What it buys is evidence that the new piece produces the results you expect on your real work, which is the only evidence that counts.

Then write the cutover plan, and give it a way back:

• A go or no-go checklist, agreed in advance, with a named person who makes the call.

• A quiet window chosen around your business, not the developer’s calendar.

• A rollback trigger and a deadline. If these checks aren’t passing by this time, you switch back. Decided before, not argued during.

• A plan for the work done in between. If you roll back after a morning on the new system, whatever was entered there has to reach the old one. It’s the part of a rollback that’s easiest to forget.

• The old system kept read-only for a set period afterwards, so anyone can check what it said.

The riskiest stretch in a staged replacement is the one where everyone assumes someone else is looking after the old system. The contractor who knows it has been told it’s going away. The hosting bill looks like money wasted. Nobody applies the security patch, because the system will be gone in three months.

Name one person who owns the old system until every part of it is formally retired. They keep it patched, keep its backups tested, keep the people who understand it on contract, and approve the date each part is switched off. Don’t cancel a licence, a hosting plan or a support arrangement until the read-only period for the last workflow is over.

Acceptance needs the same discipline. A workflow is accepted when the person who runs that work in your business has used the new version on real cases and signed off, not when the developer says it’s finished. The software project handover checklist applies the same standard to the code itself: separate what you received from what you’ve actually tested.

Before anyone prices a rebuild, list every workflow the old system runs. For each one, write down who uses it, how often, what breaks, and your best guess at the verdict: keep, fix, integrate, migrate or rebuild. Put a question mark wherever you don’t know.

The question marks are the real scope of the first piece of work. If there are a lot of them, or the people who could answer them have gone, get an independent second opinion on the system before you commit: an account of what’s sound, what’s risky and what’s worth keeping, written so you can act on it whoever does the work.