You don’t have to finish

When most companies decide to modernize, they picture one project: a rebuild that ends with the old system switched off. Incremental software modernization works differently. You replace the old system a piece at a time while it keeps running. Each piece goes live on its own, earns its keep on its own, and teaches you something before you commit to the next.

Done this way, the hard question becomes where to start.

How it works

Pick one area of the system. Rebuild it alongside the old one, connect the two, and move that area over. The old system shrinks and the new one grows. Each step is small enough to reverse if something goes wrong, and nobody waits two years to see a result.

Where we start

Every system is different, but we tend to work through the same questions, roughly in this order, skipping any that don’t apply.

Is the foundation stable? If the system goes down, loses data, or has no real backup or failover, that comes first. Every later phase runs on top of it, and moving to modern infrastructure is often the fastest visible win. If the foundation is already solid, skip ahead.

What connects to the outside world? Customer portals, supplier feeds, payment processors, anything that reaches into the old system or that it reaches out to. When those break, the damage spreads beyond your own walls. Moving them early puts a fence around the old system, so the rest of the work happens inside it.

What’s slow? Workflows that drag down the whole system or frustrate people every day. Fixing them inside a tangled old codebase is expensive. Rebuilding them is often cheaper, and everyone notices the difference right away.

What no longer fits how you work? Features built for how the business ran ten years ago, held together by workarounds. These are where a rebuild pays off in daily efficiency, not just in cleaner code.

What’s built more than once? The same logic copied into several places, so every change has to be made, and tested, several times. Consolidating it means a fix happens once.

What gets used the most? Heavily used areas attract the most change requests. Moving them early makes all that future work cheaper.

You don’t have to finish

At some point, what’s left in the old system may be rarely used and working fine. Moving it would cost money and return very little. Leaving it, or deferring it until the value is clearer, is a legitimate choice, and one a full rebuild never gives you.

Stopping partway has its own cost, though. It means living with two technologies indefinitely: two skill sets to staff for, two sets of updates and security patches, and the connections between them to maintain. A system that’s three-quarters modern and one-quarter old can be harder to support than either one on its own. Sometimes that’s still the right trade. Just make it on purpose, with the long-term cost in view, instead of letting the project quietly stall.

What it looked like in practice

One of our clients, a manufacturer and distributor, ran its operations on an ERP system that had grown over many years, with several copies running in parallel for different business units. They knew it needed modernizing, but the system was sprawling, and nobody could say with confidence what a full rebuild would cost. They had also just left a vendor whose work kept running late, so a years-long commitment with nothing to show until the end wasn’t appealing.

We started with the foundation: stabilizing the system and moving it onto modern infrastructure. Performance improved 60%, infrastructure costs dropped by half, and outages stopped. From there, we went where people spent their day: order management, forecasting, and reporting. Screens that had been spread across multiple views were consolidated, repeated data entry went away, and shared pieces were rebuilt so a change made once applied to every business unit. Admin and setup screens, used rarely and harder to justify, were deliberately left for later.

Partway through, the company was acquired, and new ownership took over the program before the final phases. Everything completed up to that point was already in production and in daily use. A single rebuild interrupted at the same moment would have left a half-finished system that nobody was using. Read the full story.

What it costs

Incremental modernization usually costs more in total than a single rebuild, because you’re running two systems and keeping them in sync until the transition is done. What you get for that is control: value early and often, the freedom to change direction, and no single day when everything has to work. For a closer look at that tradeoff, see Leaving the AS400 Without Breaking the Business.

Knowing where to start depends on knowing what’s actually in the system: what connects to what, where the slowdowns are, and which parts nobody wants to touch. That’s what an Assessment is for.