.svg "kloia.png"){kind=logo}
Software Modernization (Brownfield)
Modernise The Platform
You Are Afraid To Touch
AI agents map what your legacy system actually does.
Your experts validate it.
You get a plan measured, not guessed.
Your Existing System
Is The Specification
Legacy modernization usually fails one of two ways: months of discovery that exhausts your best people, or a plan committed before anyone understood the estate.
Brownfield AI-DLC does neither. It treats modernization as an evidence problem, not a rewrite project, working from the measured behavior of the code running today rather than a requirements doc written from interviews. Agents extract that behavior with a citation behind every rule they find. Your architects confirm it. Then we build against it and check the new system against it, endpoint by endpoint.
Nothing is rewritten wholesale. The old system keeps running while the new one grows next to it, capability by capability, and each one only takes over once it's proven to behave identically.
Who It's For
CTOs and platform owners with a business-critical system that's expensive to change and risky to touch. Typically a large .NET, Java, or mainframe estate, a database with a decade of logic in stored procedures, some regulated flows, and a team spending most of its time on maintenance.
Why Modernisation Programmes Stall
Understanding the system costs more than changing it.
The original team moved on and the documentation does not match reality. Research on professional developers puts time spent on program comprehension at roughly 58%, and legacy estates are worse than average.
Our Solution :
Agents read every repository, map dependencies, extract business rules with file and line references, and produce a record your architects sign off on.
You cannot get a credible price or a credible date.
Fixed-price legacy modernisation barely exists because nobody can estimate it honestly. So you accept either an open-ended programme or a fixed price with a large guess baked in.
Our Solution :
We build one real capability first and measure it. The plan for the rest is based on that measurement, which is what makes a fixed price defensible.
Cutover is the part everyone is scared of.
One big migration weekend, a rollback plan nobody has rehearsed, and an unpleasant Monday.
Our Solution :
Small tranches, each rehearsed, legacy still live behind them, rollback practised before it is needed. Per capability or per tenant, never as one event.
Modernisation projects quietly under-deliver.
The architecture diagram looks modern, the database is untouched, the business logic moved nowhere. Two years later you are modernising the same thing again.
Our Solution :
Modernisation has to reach infrastructure, stack and business logic. A clean architecture over an unchanged legacy database fails our own acceptance test, so it does not get signed off.
ProveIt, Then Switch It
Assessment,
Two To Six Weeks
Agents ingest the estate. Findings surface in the first week so your people can correct them early. Partway through there is a formal go or no-go checkpoint reporting on coverage achieved, complexity found, and how well the analysis is working on your estate. Its sanctioned outcomes are continue, change scope, or stop.
Decomposition And
The Blueprint
Candidate domain services with explicit acceptance criteria per boundary, a migration sequence, a cost view, and a single plan aligned to your own target architecture.
A Proof Slice,
Two To Six Weeks Where Contracted
One bounded capability, chosen jointly, built for real. This is where the velocity assumption gets replaced by a measurement.
Delivery, Slice By Slice
Characterisation tests pin the old behaviour before extraction. The new service talks to the legacy world through a one-way adapter that has a removal date from the day it is created. Both systems run against the same traffic and the answers are compared.
The Rules We Do Not Bend
- Legacy code is read-only. We modernise alongside it, we do not edit the thing we are replacing.
- No two-way data sync in production. Ever. Data flows one direction.
- Every slice ends up owning its own database, with the temporary adapter removed on a named date.
- Parity is the floor. Improvements on top of it are welcome but need explicit sign-off, so they cannot muddy the comparison.
- Regulated flows get 100% human review, not a sample.
Outcomes, With Their Qualifiers Attached
A Plan You Can Commit Budget To
Measured on a real slice of your own system.
Fixed price and fixed time, or agile. Your call.
Discovery In Weeks
Rather Than a Quarter
On our reference engagement the assessment and blueprint
closed in four weeks. The equivalent classical budget in AWS's
own modernisation playbook is about fourteen.
Proof Instead of Assertion
at Every Gate
Parity computed per endpoint, machine-checked, no override.
On the proof slice, 228 of 228 acceptance tests passed in
under ten minutes.
Cost Visible Per Capability
The agentic build of one capability on the reference engagement
ran at roughly $39 of model spend, measured and metered.
At slice scale.
Your Experts Stay on Their Day Jobs
No discovery workshop marathon. Short validation sessions on
machine-generated findings instead of long interviews to
originate them.
A Knowledge Core You Keep
When the programme ends you still have a cited, current record
of your platform. That asset is often worth more than the migration.
A Regulated
Financial Services Platform
Three large .NET monoliths, roughly 1.7 million lines of code between them, around 300 repositories, and 29 production databases with a decade of business logic living in stored procedures. Some of the most important flows were regulated. Automated coverage of the documented business scenarios was in the low single digits, so nobody could change anything quickly and be confident.
What we did
Ingested the estate and built the knowledge core. Decomposed the platform into candidate domain services. Closed the assessment and blueprint in four weeks. Then built one bounded capability end to end through the pipeline as a proof of value.
What came out
The capability was delivered by agents working in parallel across 143 recorded runs, with every pull request reviewed and merged by a human. 228 of 228 acceptance tests passed in under ten minutes. Agentic build cost landed around $39 per capability. The measured velocity from that slice is what the programme plan was then based on.
Honest caveat, and we put it on the slide too
This is one engagement and the proof is at slice scale. Calibrating it for a whole estate is the next step, not a finished claim. Where else this fits Insurance policy administration platforms. Core banking peripheries. Retail and e-commerce platforms that grew into a monolith. Healthcare systems where behaviour is contractual. Any estate where a stored-procedure layer holds business rules nobody has written down.
Find Out What Your Estate Actually Looks Like
The assessment reads your platform, decomposes it, and ends with a measured plan and a real proof slice. A few weeks, a bounded cost, and a go or no-go decision made on evidence.
FAQ
Is it safe to point AI at a regulated legacy system?
That is what the gates are for. Agents never merge. Parity is measured by a machine and the verdict cannot be overridden by opinion. Regulated flows get complete human review rather than a sample. Four kinds of decision have no agent route at all.
How is this different from a rewrite?
A rewrite replaces the system and hopes the behaviour survives. This keeps the old system running as the reference, extracts one capability at a time, and proves equivalence before switching. If a slice fails the comparison, nothing goes live and nothing is lost.
What about our stored procedures?
In scope, not deferred. Table splits, ownership transfer and stored-procedure refactoring are part of each slice's definition of done. Skipping this is why modernisation programmes get redone.
Every consultancy says it has a method. Why is yours different?
Ours works without the AI. The disciplines came from seven years of modernisation delivery before we automated any of it. And we publish the caveats on our own evidence, which you can check against how any other vendor presents theirs.
Do we need to stop feature delivery while this runs?
No. The old platform stays live and supported. New capabilities grow beside it and take over one at a time.
What if the assessment tells us not to proceed?
Then it did its job and you spent a small amount to avoid a large mistake. The mid-assessment checkpoint exists precisely so that outcome is available and cheap.