Modernizing an old business system without a big-bang rewrite

Every business that has been around for a while runs on something old. It might be a desktop program from the 2000s, a database only one person can query, or a web app whose original developer left years ago. It still works, mostly. But it is getting harder to change, harder to host, and riskier every year.

The tempting approach to legacy software modernization is a rewrite: build a new system from scratch, then switch over on a chosen weekend. That is also the riskiest way to do it. This post explains why, and describes the safer path of replacing old business software one piece at a time.

Why big-bang rewrites go wrong

A full rewrite looks clean on paper. In practice, three things happen.

The old system keeps moving. While the new one is being built, the business still needs changes. Either they go into the old system, and the new one falls behind, or they wait, and the business suffers.

Hidden rules surface late. Old systems are full of behavior nobody wrote down: a discount that applies only on the last day of the month, a report that quietly excludes one customer. The new system misses them until someone notices a wrong number after the switch.

Cut-over day becomes a cliff. Everything changes at once. If something breaks, it hits the whole business, and going back is hard.

The result is often a project that runs long, costs twice what was planned, and launches with less than the old system did.

The alternative: replace it in slices

The safer approach is often called a strangler fig migration, after a plant that grows around a tree until it can stand alone. New code takes over one piece of the old system at a time: one report, one screen, one workflow. Both systems run side by side. Traffic or users move across gradually, and the old system shrinks until nothing depends on it and it can be switched off.

Each slice is small enough to test properly, and you can reverse each step until it has proven itself.

How a legacy software modernization project runs

Most projects follow the same six steps, whatever the system.

1. Read the system before touching it

The first step is a written assessment: what the system actually does, based on its code, its data and the people who use it. This is where the undocumented rules come out. It is common for nobody to fully understand the old code anymore, and that is fine. The assessment is how you find out.

2. Decide what moves first

Good first candidates are pieces that are either very risky or very expensive to keep:

• A report that takes someone a day each month to produce.
• A customer-facing form that breaks often.
• The part that only runs on one ageing server.
• Data that must be shared with a newer tool.

Starting with something visible and valuable builds trust in the approach.

3. Build the new piece beside the old one

The new piece reads from or writes to the same data, or the two are kept in step. Users can try it while the old version is still available. If something is wrong, they fall back.

4. Move the data carefully

The team checks every data move against the source before anyone relies on it. Counts match, totals match, and spot checks on real records match. The team deletes nothing from the old system until the new one has run cleanly for a while.

5. Switch off the old piece

Once nothing depends on the old piece, you retire it. Any records you must keep go into a readable archive.

6. Repeat

Each slice makes the next one easier, because the new system and its data model grow with every step.

Hosting is often the first win

Many old systems run on a single server in a closet or an old hosting account. Moving to managed hosting with automatic backups, monitoring and repeatable deploys can happen early, sometimes before any code changes. It removes the scariest risk, a dead machine with no backup, and makes every later step safer.

Signs it is time to start

• Only one person can deploy changes, or nobody can.
• The software runs on hardware or an operating system that no longer gets security updates.
• New features the business needs are impossible or absurdly slow to add.
• Staff keep spreadsheets on the side because the system can't produce what they need.

What it costs, roughly

You pay for a slice-by-slice project one slice at a time. The assessment is usually a small, fixed piece of work, and it ends with an ordered plan. After that, each slice gets its own scope and price, so you can stop after any step and still have something that works. Our modernization service page describes how we run these projects.

Talk about your system

Tell us what the system does, roughly how old it is, and what worries you most about it. We reply within one business day, and if the right first step is just better backups, we will say so. Get in touch.

Cover photo by Pixabay on Pexels.