Legacy system modernization with AI, without stopping the business.
Modernizing a legacy system with AI means using coding agents to read what the system does today and build its replacement alongside it, switching over piece by piece while the old system keeps running.
A critical legacy system that cannot go offline.
Modernizing a legacy system, here, means reading the code that still serves and building the replacement beside it. A legacy-system refactor happens in parts, with human supervision and every session traceable. Legacy modernization starts in the Knowledge base: coding agents read everything that exists before any new line is written.
Read before writing.
The people who wrote the code have left and the documentation has aged. What still holds of the business rules is in the system that runs today.
- 01 Read
- All the existing code and all the existing documentation enter the Knowledge base before a single new line is written.
- 02 Build beside it
- The new system is built typed and instrumented, with every session traceable.
- 03 Check
- The rules taken out of the old system are checked against its behavior, not against the documentation.
- 04 Switch
- The replacement is planned with your team and happens in parts. Each part goes in only after it has been checked.
The platform does not leave after the switch. Sustainment is part of the platform.
What each stage does on a system that already runs.
- Knowledge base
- Code, documentation and anonymized data go in before any new line is written. The rules come from production behavior, not from old documentation.
- Build and refactor
- Coding agents write the new system beside the current one. What is live keeps serving.
- Observability
- Each session stores the request, the steps, the model, the cost and the authorship.
- Sustainment
- Tickets come in, fixes go out, with the team supervising. The platform does not hand the system over and leave.
Where the switch tends to break.
- A rule that lives only in code
- Documentation ages. The reading starts from the code that runs and from what the system actually does.
- A switch that takes down what is serving
- The current system stays up. Each part is checked before it goes in. The blast radius of a failure shrinks; the failure does not disappear.
- A session nobody can explain
- The request, the steps, the model, the cost and the authorship stay on the session. Without that record, the speed is not auditable.
- Autonomy past what the team reads
- The platform stops at level 4. Humans read what ships, and the team sets the limit. Level 5 is a dark factory, and the platform stops before it.
A subscription platform with eight years in production.
Deployment 01
Dr. Consulta · subscription platform
Eight years in production · Challenge B, refactor legacy
Speed and cost show up first. Correctness decides whether they are worth anything.
Each refactored part is checked against the old system's behavior before it goes in.
Not with the whole system.
The platform comes in through one part that can be checked end to end, usually the part that eats the most maintenance today. That part is refactored and put into production before the next one begins.
The system stays yours.
What gets asked before a deployment.
Can the system be modernized without taking it offline?
The current system keeps serving. The new one is built beside it, and each part goes in after it is checked. A failure is still possible; what changes is how much of the system it can reach.
What does the platform do first?
The first pass is reading: existing code and documentation become the Knowledge base. Writing starts only after that reading.
Is this a dark factory?
No. A dark factory is level 5, code nobody reads before it goes into production. The platform stops at level 4: the team reads what ships and sets the limit.
What results has the platform shown?
The Dr. Consulta case: a system with years in production, where one feature that used to take about two weeks took up to three days, and infrastructure cost is 75% lower than in the period before the modernization. The feature is a representative example, not a measurement of the whole backlog.
Does the code leave the network?
The repository is not sent to an Ithaca SaaS: the platform runs inside the firewall, on the client's cloud or data center. Model calls follow the policy the client sets (provider, region and contract). The code stays the company's, and every session is logged, with authorship.
Where does a deployment start?
With one part that can be checked from start to finish, almost always the heaviest maintenance. The whole system is not the first step.
Why the platform is not a dark factory
Observability for coding agents
Harness engineering for coding agents
