The instinct with an old system is to replace it. The instinct is understandable and the data is against it. A full rewrite is by definition a large project, and the Standish Group's CHAOS research puts large project success below 10 percent, against roughly 90 percent for small ones.
A rewrite also has a specific structural problem beyond its size. The old system keeps changing while you build the new one, because the business does not stop. You are aiming at a target that moves for the entire duration of the project, and the longer the project, the further it moves.
Incremental modernization has worse aesthetics and much better odds.
What makes a system "legacy"
Age is a poor indicator. Plenty of old software runs quietly for a decade and costs nothing to own. The properties that actually matter are these.
Nobody can change it confidently. Changes are avoided, or made by one person, or followed by unexpected breakage elsewhere. This is usually the absence of tests around behavior rather than the age of the language.
It cannot be connected to anything. No API, or an API that exposes a fraction of what the system does, so integrations happen through database access, file drops or people retyping.
Its assumptions no longer match the business. The data model encodes a version of the company that no longer exists, and everyday work involves conventions that work around it.
Its dependencies are unsupported. A runtime or framework past end of life is a security clock rather than an inconvenience, and it eventually forces a move regardless of the business case.
Which of these applies determines the right approach entirely. A system nobody can change safely needs tests before anything else. A system that cannot be connected needs an interface in front of it. A system whose model is wrong needs a genuine rebuild of the affected area. Treating all four as the same problem is what produces rewrite proposals.
Take the piece with the highest ratio of pain to risk
Modernization works when you can name the specific piece being replaced and the specific benefit of replacing it, and when the rest of the system keeps running throughout.
Choose the first piece by two properties together: how much pain it causes now, and how contained it is. The most painful part is often deep in the core, and starting there means the risk arrives before any benefit. A slightly less painful part with clean boundaries produces a working result, a team that has now done a migration once, and evidence for the next one.
Reporting is frequently a good first target. It is read-only, so mistakes do not corrupt anything, the pain is usually acute, and it forces you to understand the data model without changing it.
The interface in front of the old system
The technique that makes incremental modernization possible is putting a deliberate interface in front of the legacy system, and having everything new speak to that interface rather than to the system directly.
The interface starts as a thin pass-through. Its value is not what it does but where it sits: once new work depends on the interface rather than on the old system's internals, individual pieces behind it can be replaced without every consumer having to change. Without that layer, each replacement requires coordinating every caller, which is how modernization stalls.
This is unglamorous work with no visible output for the people paying for it, and skipping it is the most common reason a phased plan turns into a rewrite anyway.
Data migration is the part that goes wrong
Moving records into a new system is the line item most likely to break a fixed price, because nobody knows how bad the data is until they look properly.
Real systems accumulate records that violate their own rules. Required fields empty because they were added later, duplicates created by a process that has since changed, dates in several formats, and identifiers reused across eras. All of it works fine in the old system, which tolerates it, and none of it fits a new schema that assumes correctness.
Do the assessment before quoting the migration, not after. Counting the rows that violate each rule you plan to enforce takes a day or two and changes the plan more than any other single activity.
Where AI actually helps, and where it does not
AI is useful in modernization for reading, not for rewriting. Summarizing what a large unfamiliar codebase does, generating first-pass documentation for undocumented behavior, and identifying where a rule is implemented across a sprawling system are real accelerations on tasks that were previously slow and manual.
It is much weaker at producing a correct replacement for business logic whose edge cases exist because of a decision made years ago for a reason nobody wrote down. Those edge cases are the entire difficulty of a migration, and they are precisely what is missing from the code as context.
Treat AI as a way to understand the old system faster. Treat claims about automatic translation of legacy code with the same scepticism you would apply to any claim that the hard part has been removed.
What modernization costs
Incremental work prices like other custom development, which means it prices by the size of the piece rather than the size of the system. With us, a contained piece of modernization work, meaning an interface in front of an old system, a replaced reporting layer, or an integration that removes manual data movement, runs $5,000 to $15,000. Larger pieces involving a genuine rebuild of an area with its own data model start at $18,000. Ongoing work runs $2,000 to $6,000 per month.
The number that matters more is what the current situation costs annually in manual work, in changes not made because they are too risky, and in the security exposure of unsupported dependencies. That figure is usually never calculated, which is why modernization budgets get compared against zero.
Frequently asked questions
Should we rewrite or modernize incrementally?
Incrementally, in almost every case. A rewrite is a large project, and the CHAOS data puts large project success below 10 percent against roughly 90 percent for small ones. Rewrites also have to hit a target that keeps moving, since the old system continues changing while the new one is built.
How do we choose what to modernize first?
Pick the piece with the best combination of current pain and clean boundaries. Read-only areas such as reporting are often the right start because mistakes cannot corrupt data and the work forces you to understand the data model.
How long does legacy modernization take?
Each piece should be a small project. Our builds run two to four weeks after a five to ten day discovery. A programme is a sequence of those, with a working result after each, rather than one long effort with a single delivery date.
What does it cost?
Contained pieces run $5,000 to $15,000 with us and larger rebuilds start at $18,000. The cost driver is the data, specifically how much of it violates the rules the new system will enforce.
Can AI modernize legacy code automatically?
It can help you understand an unfamiliar system considerably faster, which is genuinely valuable. It is not reliable at reproducing business logic whose edge cases exist for undocumented reasons, and those edge cases are the actual difficulty.
Where to start
If you have an old system and no clear first move, the useful step is an assessment that names the first piece and what replacing it is worth. Our audit does that, starting at $3,000 and credited toward the work.