TL;DR: Replacing the system your business already runs on is harder than building something new, and for one reason: the old thing works. It is ugly, slow and held together by one person's knowledge, but invoices go out and orders get filled, and on cutover day the new system has to do all of that from the first hour. The risk is almost never the technology. It is the undocumented business rules nobody can name, the data that turns out to be messier than anyone claimed, and a cutover plan that assumed everyone would switch cleanly on a Monday. Here is how legacy replacement actually goes, how to sequence it so you are never betting the business on a single weekend, and what to ask before you commission one.
Why replacing working software is the hardest kind of build
A new product starts from zero. Nothing depends on it, nobody is mid-transaction inside it, and if the first version is wrong you fix it next week. That is why greenfield work is comparatively predictable, and why we can scope a first build the way we lay out in what it takes to build an MVP.
A replacement starts from a system that is already load-bearing. Your team has years of muscle memory in it. Your customers see its outputs. Your finance close depends on it. And crucially, it encodes decisions people made years ago that nobody wrote down and everybody now relies on. The build is not the hard part. Landing it is.
This is also why replacement projects fail in a distinctive way. They rarely fail loudly in the first month. They fail in month seven, when the new system is roughly finished, the data migration keeps producing numbers that do not match the old reports, and nobody is willing to be the person who says go.
The four reasons systems actually get replaced
Worth being honest about which one you are in, because they lead to different projects.
The system blocks the business. You cannot add the product line, region, currency, customer type or integration the business now needs, and every attempt takes months. This is the strongest reason to replace, because the cost of not doing it compounds.
The knowledge is concentrated in one or two people. One developer understands the codebase, or one operations person knows which fields actually matter and which reports lie. That is a risk with a human dependency attached, and it does not resolve on its own.
The running cost is quietly enormous. Not just licences and hosting, but the hours your team spends re-keying data between tools, reconciling exports, and doing by hand what the software should do. That cost usually hides inside salaries, so it never appears on a line item until someone counts it.
Vendor or platform risk. The product is discontinued, the vendor's roadmap has diverged from yours, or the stack sits on something that is genuinely reaching end of support.
And the reason that is not good enough on its own: the system looks dated. A tired interface is a real problem when it slows staff down or costs you customers, but it is a much cheaper problem than a rebuild. If the only complaint is the look, a front-end refresh over the existing system is often the honest answer, and a vendor who does not raise that possibility is not advising you.
What is actually in the box
Every replacement quote should be interrogated on four things that are easy to underestimate and expensive to discover late.
The undocumented business rules
This is the big one. Somewhere in the old system is a rule like "orders from this customer group skip the credit check", "this fee is calculated differently after the fifteenth", or "these two product codes are treated as one for reporting". Nobody remembers deciding it. It is not in any specification. It surfaces when a long-serving employee looks at the new system and says that number is wrong.
The only reliable way to find these is to go looking on purpose: read the code paths, run the old and new systems against the same real inputs, and put the results in front of the people who would notice a difference. Anyone who proposes to rebuild from a wishlist of features, without excavating the current behavior, is quoting a different project from the one you have.
The data
The data is almost always worse than the person commissioning the project believes, and they are not being dishonest. They have simply never had to look at all of it at once. Expect duplicates, records with fields used for something other than their name, values entered as free text that need to become structured, historical rows that predate a rule change, and a long tail of entries that violate every constraint the new schema wants to enforce.
Decide early how much history has to move. All of it, the last few years, or a summary plus an archive you can query when someone asks. That single decision moves the migration effort more than any other, and it is a business decision rather than a technical one.
The integrations
The old system is rarely alone. It talks to accounting, payments, a shipping provider, a data feed, an internal reporting tool, a spreadsheet somebody built that has become critical. Each connection is scope. The ones that hurt are the connections nobody lists in the first meeting because they are not thought of as systems, like the export that gets emailed every Friday and pasted into a board pack.
The people
Software replacement is a change project wearing engineering clothes. The staff who are fastest in the old system will be slowest in the new one for a while, and they are usually your best people. If the plan has no training, no transition period and no named internal owner, the software can be correct and the rollout can still fail.
Big bang or incremental
There are two ways to land this, and the choice matters more than the tech stack.
Big bang. Build the whole replacement, migrate everything, switch over on a chosen date. It is simpler to reason about, avoids running two systems at once, and is sometimes the only option for a small tightly-coupled system. The problem is that all the risk lands on one day, and the fallback is a rollback nobody wants to execute in front of customers.
Incremental, one capability at a time. Put the new system alongside the old one and move functions across in slices, starting with something valuable but not existential. Reporting, a customer-facing portal, or one module such as purchasing. The old system stays authoritative for everything not yet moved, and the two are kept in step until each slice is proven. It takes longer in total, costs more in integration work, and requires discipline about which system owns which data at any moment. In exchange, no single failure takes the business down, and value arrives during the project instead of only at the end.
For anything that genuinely runs the business, incremental is usually right. The exception is when the old system cannot be integrated with at all, in which case the honest plan is a big bang with a long parallel-running period and an explicit rollback.
Parallel running is the underrated part. For a period, real work goes through both systems and the outputs are compared. It is duplicated effort and your team will not enjoy it, and it is also the single most effective way to find the undocumented rules before they find you. Budget for it as real work, because it is.
Data migration is a workstream, not a step
If a proposal has one line for data migration, the proposal is not finished. Migration is its own project with its own phases: profiling what is actually there, deciding the rules for cleaning and mapping it, building repeatable scripts rather than one-off manual fixes, running rehearsals against production-scale data, and reconciling the results against reports the business already trusts.
Rehearse it more than once. The first rehearsal exists to find how bad the data is. The second exists to time it, because "the migration takes fourteen hours" changes a cutover plan that assumed a quiet Sunday morning. And reconcile against numbers your finance or operations team already believes, because a migration is not done when it completes without errors. It is done when a person who knows the business looks at the totals and agrees.
Where AI genuinely helps, and where it does not
The build side compresses hard. AI coding agents under senior review are good at exactly the work a replacement is full of: reading an unfamiliar codebase and explaining what a path does, drafting migration and transformation scripts, generating the test coverage a rewrite needs, and producing the large volume of ordinary screens and endpoints that a business system requires. That is a real speedup, and it is the same ship-in-days approach we apply everywhere.
Some of the manual work also disappears rather than being rebuilt. Processes that only existed because a person had to move information between systems can often become automation or an agent instead of a screen, which is a large part of what we build in custom AI agent development, and the same principle behind the intake work in our Fortell build, where voice and SMS in 100-plus languages replace paperwork so teams can spend their time on people.
What AI does not compress is the deciding. Which rules to keep and which were never intentional. How much history to carry. Which slice goes first. When the business is confident enough to cut over. Those need people who understand the operation, and they are usually the critical path. Being able to build faster is only an advantage if you use the time you saved on the excavation and the landing.
How we approach a replacement
The pattern we run, and what to expect from anyone competent:
- Map the current system as it behaves, not as it is described. Code paths, real data, the reports people actually use, and the workarounds. The workarounds are requirements in disguise.
- Separate the rules worth keeping from the accidents. Some of what the old system does is deliberate and load-bearing. Some is a decision from 2014 nobody would repeat. Get that list agreed in writing.
- Choose the sequence and name the first slice. Valuable, visible, survivable if it slips.
- Treat data as its own workstream with profiling, rules, rehearsals and reconciliation against numbers the business already trusts.
- Run in parallel and compare until the new system's outputs stop being a discussion.
- Cut over with a written rollback, then keep a team on it, because the weeks after cutover are when the last hidden rules appear.
That is the same discipline behind our platform work, including Fyuel, a real-time accounting platform for the fuel trade that brings customers, suppliers, tankers, ledgers, banks and reports into one system, replacing the stitched-together picture that trade was assembling by hand. If you are still deciding whether a custom system is the right answer at all, the prior question is covered in build versus buy for vertical software. And if the constraint is capacity rather than direction, the same engineers are available through talent augmentation.
Buyer checklist
Ask these before you sign. The answers separate people who have landed a replacement from people who have only built software.
- How will you find the business rules nobody documented? Expect a specific method, not a promise to ask around.
- What is the migration plan, and how many rehearsals? One is not enough, and "we will export and import" is not a plan.
- Big bang or incremental, and why for us? Either can be right. Not having a reason is not.
- What runs in parallel, for how long, and who compares the outputs?
- How much history are we moving, and what happens to the rest? Make sure this is a decision, not an assumption.
- What is the rollback, and who decides to use it? Written down before cutover week, not improvised during it.
- Who owns this internally, and what does their team have to do? A replacement with no named business owner is a project that will stall at ninety percent.
A replacement is not a better version of a system your business already has. It is a transfer of something that is currently running, while it keeps running. Get the excavation and the landing right and the build is the straightforward part. Get them wrong and it does not matter how good the new software is, because nobody will be willing to switch to it.
Null Studio replaces the systems businesses have outgrown: excavating the rules in the old one, building the new one with AI leverage, migrating the data properly, and staying on it through cutover and the weeks after. Book a demo and we will tell you honestly whether you need a rebuild, a slice of one, or something considerably cheaper.