The system that works, mostly
It was built years ago, or quickly, or by someone who has since left. It holds the business together and everyone is a little afraid of it. New features take too long. Nobody is quite sure what happens if the server restarts. There is a spreadsheet beside it that covers what it cannot do.
The instinct is to replace it all at once. That plan fails often enough that we do not recommend it. A year of building with nothing shipped, a migration weekend that nobody sleeps through, and a new system that turns out to have forgotten half of what the old one quietly did.
Stabilise, then rebuild in slices
Read it first. We map what the system actually does: the flows, the data, the integrations, the manual steps around it. Usually there are things it does that nobody wrote down.
Stabilise it. Backups, monitoring, the two or three fixes that remove the daily fear. This alone changes how the team feels about the system, and it buys time to rebuild properly.
Rebuild one slice at a time. Reporting first, perhaps, because it is read-only and low-risk. Then the workflow that hurts most. Each slice is built as a proper web application or internal tool, goes live on its own, and takes its data with it. The old system shrinks.
Switch off quietly. When the last slice has moved, the old system is turned off on an ordinary Tuesday, and nobody notices.
Data, honestly
Migration is designed at the start, not the end. History comes across, checked against the source. Old and new run side by side until the numbers agree. Where the old data model is a mess, and it usually is, we clean it where it matters and preserve it where it does not.
Where AI fits, and where it does not
AI helps us read a large old codebase faster and spot what a human would miss on a Friday afternoon. It does not decide what the new system should do; the people who run the business do. Our approach is the same here as everywhere.
After the rebuild
You own a system that the next person can understand, with documentation written for them. We stay to keep improving it, or hand it over cleanly. Both are normal. See what you should own at the end of a software project.