AI decisions Operating model
Legacy rewrite vs AI-assisted modernisation: should you start again or decode what you have?
Rewrite from scratch only when the system is small, its rules are well documented or the business wants a different process anyway. When the value is in years of rules nobody has written down, use AI to recover them from the code as a specification that people review, then regenerate the system against the target architecture one domain at a time. AI speeds up the reading and the writing; it does not remove the need for experts who validate the rules and for tests that prove the new system behaves like the old one.
The options
Full rewrite
A new system designed and built from scratch, from fresh requirements, that replaces the legacy one at a cut-over.
AI-assisted modernisation
AI reads the legacy code to recover its rules as a specification, which people review and from which new code is generated incrementally.
Side by side
| Criterion | Full rewrite | AI-assisted modernisation |
|---|---|---|
| Starting point | New requirements gathered from people and documents, which rarely capture every rule the old system applies. | The behaviour of the running system, extracted from its code, data and tests and turned into a reviewable specification. |
| Hidden business rules | High risk of losing exceptions and edge cases that only exist in the code. | Rules are surfaced explicitly, so experts can keep, change or retire each one on purpose. |
| Delivery shape | Usually a long build followed by a large cut-over. | Domain by domain, with old and new running side by side until each part is proven. |
| Time to first value | Late: little reaches production until the new system covers enough of the old one. | Earlier: the recovered specification is useful on its own, and each migrated domain can go live separately. |
| Freedom to redesign | Full freedom to change processes, data model and architecture. | Redesign is possible but deliberate: you change the specification first, then regenerate. |
| Verification | Acceptance tests written from new requirements; equivalence with the old system is hard to prove. | Tests derived from the specification and from real cases compare old and new behaviour. |
| Dependence on scarce experts | Heavy during requirements, and knowledge can leave with the people who hold it. | Experts review and validate rather than explain everything from memory, and what they confirm stays written down. |
| Main risk | Scope and budget grow while the old system keeps changing underneath. | Trusting AI output without review: a wrong rule extracted with confidence is still wrong. |
Choose Full rewrite when…
- The system is small or recent enough that its rules are known and documented.
- The business wants a different process, so reproducing today's behaviour has little value.
- The legacy code is so degraded or incomplete that recovering its behaviour costs more than redefining it.
- A mature product on the market already covers the process and you are replacing, not rebuilding.
Choose AI-assisted modernisation when…
- The system is critical and encodes years of rules, exceptions and regulatory logic that nobody has fully documented.
- The people who understand it are few, close to leaving, or both.
- The business cannot afford a long freeze or a single large cut-over.
- You need evidence of which rules were kept, changed or retired, for audit or for regulators.
- You want to migrate domain by domain and decide the order by value and risk.
When to combine them
The two are not exclusive. A common pattern is to recover the specification of the whole system first, because that map is cheap compared with the rewrite and it shows which domains hold the critical rules. Domains whose rules must be preserved are then regenerated from the reviewed specification, and domains the business wants to change are redesigned from new requirements, with the old rules on the table so nothing is dropped by accident.
Common mistakes
- Treating the rewrite as a technical project when the real asset is the business knowledge in the code.
- Asking AI to translate code line by line into a new language; you keep the old design and its debt in new syntax.
- Accepting a recovered specification without review by the people who know the business.
- Planning a single cut-over instead of running old and new in parallel and comparing results.
- Measuring progress by lines of code generated rather than by rules verified and domains in production.
How Thinkia approaches it
Our starting point is the thesis of our Brownfield AI whitepaper: legacy code is not rewritten; it is decoded into specs and regenerated. The spec is the asset. The value of a legacy system is the business intent trapped inside it, and AI-assisted engineering extracts that intent into a governable specification that people review before any code is regenerated against a target architecture.
We work domain by domain, not system by system. For each domain we ask how legible its rules are and what happens if a rule is lost, and that decides the order and whether to regenerate what exists or redesign it. Recovery, regeneration and verification follow the same AI-SDLC discipline we apply to new software: shared specs, gates and risk tiers. Pulse supports that work with signable Golden Specs, AI-BOM traceability and auditable delivery.
We are also clear about the limits. AI does not replace the experts who confirm the rules, or the tests that compare old and new behaviour on real cases. When a system is small, well documented or the business wants a different process, a clean rewrite can be the simpler answer, and we say so.
Thinkia products involved
- PulseGoverned AI-SDLC: signable specs, AI-BOM traceability, auditable delivery.
- SynapseGoverned agentic platform: agents, models, costs and data in one place.
Related AI solutions
Frequently asked questions
What does AI-assisted modernisation actually do with the legacy code?
It reads the code, data structures and existing tests to describe what the system does: entities, rules, calculations, exceptions and integrations. That description becomes a specification that people review and correct. New code is then generated from the approved specification, not translated from the old code.
Is this the same as automatic code translation?
No. Translating code from one language to another keeps the old design, structure and debt. Recovering the specification separates what the system must do from how it was built, so the new system can follow a different architecture.
Can we trust a specification extracted by AI?
Only after review. Models can misread code or fill gaps with plausible rules. Treat the extracted specification as a draft: experts validate it, uncertain rules are flagged, and tests on real cases check that the regenerated system behaves as expected.
Does AI-assisted modernisation remove the need for parallel running?
No. Running old and new side by side, or comparing their outputs on the same inputs, is still the most reliable way to show equivalence. The incremental approach makes it easier because each domain is smaller.
When is a full rewrite still the right call?
When the system is small, its rules are well known, the business wants to change the process, or the code is too degraded to be worth reading. In those cases reproducing current behaviour adds little and a rewrite from clear requirements can be simpler.
Keep exploring
Related decisions
- AI pilot vs production: what actually changes when you scale?
- Build vs buy AI agents: which agents should you own, and which should you rent?
- Fix the data first or start with AI now: which comes first?
- LLM evals vs human review: how should you assure the quality of enterprise AI?
Key terms
- Spec-Driven Development
- Living Specification
- Executable Specification
- Functional Specification
- Acceptance Criteria
- AI Bill of Materials
Thinkia articles
- AI Agents in Developer Workflows: The Shift from Tool to Teammate
- AI for Code Generation: The Hidden 90% Performance Gap
- AI-Native Application Development: A C-Suite Guide
- AI Coding Agents: Gartner's Endorsement Signals a New Era for Enterprise Software
Whitepapers
- Legacy isn't rewritten. Brownfield AI.How AI enables legacy migration without rewriting — the spec as the asset, reverse engineering anatomy and a five-phase method for brownfield modernisation.
- From the core to the agentic layer.Modernise the core or put agents on top? What decides is not the system but how legible its rules are. A four-quadrant framework for the 2027 budget.
- AI–SDLC. From code to intent.Thinkia's playbook for governed AI software delivery—shared specs, gates, risk tiers, and one model gateway so teams ship with audit-ready evidence.