The year’s nearly done, and if you lead an organization, you’re probably working three lists right now: what got done in 2026, what still has to land before December 31, and what goes on next year’s plan.
Somewhere on that last list, probably near the bottom where it’s been for a few years, is the system everyone quietly works around. It still runs. It’s run for years. But every new idea dies at the integration; the vendor stopped sending patches a while ago, and the one person who understands it keeps mentioning retirement.
It stays at the bottom for a reason. Replacing it has always looked expensive, slow, and risky, and the old thing works well enough. That math is changing.
What’s different now
For years, the hardest and most expensive part of replacing an old system was working out what it actually does: decades of code, thin documentation, and rules nobody remembers writing. Teams spent months reading before anyone could build.
AI tools have changed that part of the job. A skilled developer can now work through old code, trace what it does, draft the documentation, and build test coverage much faster than even a few years ago. Data conversions, and the checks around them, move faster too. The work that used to make a replacement too big to justify now takes a smaller share of the budget.
What AI hasn’t changed is judgment. Someone still has to decide which old rules still matter, what the new system should do, and how to switch over without disrupting the business. AI is the industrial mixer. The skill is everything around the machine.
So if you’ve put this off because the price and the risk never added up, run the numbers again before you lock next year’s plan.
Three signs it belongs on your 2027 list
One person keeps it alive. Everything works as long as one developer, consultant, or admin stays put. When they’re on vacation, the whole office feels it. When they retire, their knowledge goes with them.
The vendor has moved on. End-of-life notices arrive, the patches stop, and support tickets go unanswered. The platform’s clock runs out before yours does.
Every change takes a quarter. A small request turns into estimates, meetings, and months of waiting. Eventually, people stop asking, and that’s the most expensive part: the ideas nobody brings up anymore.
If even one of these sounds familiar, take a look before the system decides for you.
Modernize or rebuild?
There are two ways out. Modernizing keeps the bones of what you have and moves it off the old platform piece by piece, so the old system shrinks until there’s nothing left to turn off. Rebuilding starts fresh, designed around how your team works today, and moves your data over once the new system is ready.
Three questions usually point the way:
- Does the system still match how you work? If the logic is sound and the platform is the problem, modernize. If your team has spent years working around the logic itself, rebuild.
- Can it be split into pieces? A system that does several distinct jobs (billing, inventory, reporting) can often move one job at a time. A tangle where everything touches everything is usually easier to replace all at once.
- What do the people who use it every day want? They know which parts earn their keep and which ones they’d happily never see again.
Many projects modernize the parts that work and rebuild the parts that don’t.
Either way, nothing gets unplugged
The switch should be boring, meaning your team barely notices it. The old system keeps running the business while the new one is built and proven beside it, so there’s never a day nobody can work. Here’s how we keep it that way:
- The old system stays up, and your team keeps working.
- We build the replacement alongside it, in two-week sprints you can see.
- Your data moves over, checked against the old system line by line.
- You switch when it’s proven. The old one runs until the day you no longer need it.
A large wholesale distributor is doing this right now, retiring the mainframe that runs its core operations one function at a time. For one piece of that work, the company’s own plan called for four developers and six months. Working alongside the company’s team and its technical architect, we delivered that same piece with one developer in 28 weeks, at the fixed price. Read the full story.
Start with what the old system knows
Old systems are full of decisions nobody wrote down. A field that only gets filled in for one kind of customer. A report that runs every Friday because someone asked for it years ago. A rule that exists because of a problem nobody remembers. Miss those, and a shiny new system can end up worse than the old one.
This is where faster tools help most, and where judgment matters most. Before anyone builds, we map what the old system does, screen by screen and rule by rule, with the people who use it. We call it Requirements by Design. You approve what the new system will do before we write any code, and we set the fixed bid on that plan.
Put it on the list
Before your 2027 plan is final, bring us the old system. Tell us what it does, what drives your team up the wall, and what you’d build if you could. We’ll help you work out whether now is the time, which way out fits, and what it would take.
See how the switch works on our What We Solve page.