The problem
Your business runs on a system nobody wants to touch. The people who built it are gone, nothing around it is tested, and the business cannot stop for a rewrite. So it stays, and your team works around it.
What goes wrong
- The rewrite starts from a blank page. The last ten percent takes longer than the first ninety, so the old system never shuts off and your company pays to run two.
- The switch-over is a weekend. Nobody tested the parts that move money or log people in, and Monday morning is spent finding out which ones broke.
- The company never held its own keys. The domain, the hosting, the payment account, and the source code sit with whoever built the old system, so leaving that vendor means asking it for permission.
The approach
- Take control first: every account, every credential, every copy of the source and the data, in your company's name, with two named people on each. Nothing gets replaced until you own what is being replaced.
- Put a safety net around money and login before changing anything. Regression tests on the parts that cannot break, then every fix lands with a test that proves it.
- Replace one workflow at a time. The new one runs beside the old one on real data, and the old one is switched off only after the two give the same answers for a few weeks.
- Switch over on a day you choose, with the rollback written down first and our dedicated support and maintenance team watching the new system after the switch: the queue, the errors, and the questions from the field.
When it works
When your business depends on a system it is afraid to change, the people who built it are gone or leaving, and one workflow inside it costs enough to be worth replacing first.
Why the rewrite fails
Every company has one system it is afraid of. The one that runs job costing, or scheduling, or the draws, built years ago by someone who is gone. It works, mostly. Every change is a risk, so nobody changes it, and the workarounds pile up in spreadsheets around it.
The usual answer is a rewrite. A new team starts from a blank page and promises the new system in a year. Eighteen months later it does most of what the old one did, the old one is still running because the last ten percent is the hard part, and your team is maintaining both. The business never stopped, but it paid for two systems and got one.
The fix is not a better rewrite. It is a different order of operations.
Take control before you change anything
The first job is ownership, not code. Before a line of the new system is written, your company holds every account the old system depends on: the domain, the hosting, the database, the payment processor, the email sender, the source repository. Each one in the company's name, with two named people on it. One person is a single point of failure. A vendor holding it is worse.
Then the copies. Every repository, every database, every environment file, pulled into storage you control while the people who built the system are still cooperating. Then the source is checked against what is actually running in production. The two have usually drifted, and what is running is the version that matters.
Only then does the replacement start. A system you do not control is not yours to replace.
Safety net first
Legacy systems rarely come with tests. That is why nobody dares change them. So the first engineering work is not a feature. It is a set of regression tests around the parts that cannot break: anything that moves money, anything that logs a person in, anything that writes to the record the business runs on.
Once those tests exist, every change lands with a test proving it. This is what makes the system safe to touch, and it is what lets a small pod move quickly on a codebase nobody has fully understood for years.
Replace one piece at a time
The new system does not replace the old one. It replaces one workflow inside it. Say it is estimating. The pod builds the new estimating flow against your real data, on the tools your team already uses, and runs it beside the old one. For a few weeks both produce an answer and your team compares them. When the two have matched for a few weeks, the old estimating module is switched off.
Then the next piece. Each switch-over is small enough to reverse and small enough to understand. The old system shrinks until what is left is a database nobody logs into, and that gets retired too.
The switch-over
Each switch-over happens on a day you choose, not a weekend you dread. The rollback is written down before anything is switched. After the switch, our dedicated support and maintenance team watches the new system: the queue, the errors, and the questions coming in from the field.
The pod keeps replacing pieces for the rest of the term, and your team learns to run what it leaves behind. A week in a pod shows how that work runs.
When it does not work
It does not work when nobody on your side can hand over the accounts the old system runs on, or when the plan is still one big switch over one weekend.
Where to start
If you know which system is the problem, the FDE Pod is the engagement that replaces it, and legacy system modernization covers the build. If you are not sure which piece to start with, the paid assessment delivers an AI inventory, risk tiers, the top 3 workflows with today's numbers and a 90-day plan. For a straight answer first, ask Roo, Webaroo's AI: How would we replace our old system without stopping the business?
Book 15 minutes with Connor