Legacy system migration

We move systems that still run the business off platforms that are no longer supported and onto current ones, and into the cloud where that is wanted. The work is done in stages, with the original kept in service until each part of the new system has been proven, so the business does not stop while it happens.

Legacy systems are often left in place because nobody is certain what they do any more: the rules are in the code and the people who wrote it have left. The first stage of the work is therefore analysis. Agents read the codebase in full and document its behaviour before anything is changed, which makes the part that used to take months considerably shorter.

What it covers

Codebase analysis: The whole codebase read and documented before anything is moved, including the rules nobody wrote down and everyone still depends on.
Re-platforming: Moving off a framework that is out of support and onto one your team, or anyone's team, can still hire for.
Cloud migration: Moving off a server in the office or a rented rack and into your own cloud account, with the deployment defined as code rather than remembered.
Incremental cut-over: The old system keeps running while the new one takes over one component at a time. There is no weekend on which everything changes and nobody can trade.
Data migration: Years of records moved across with their meaning intact, and verified against the old system before it is switched off.
Planned end of platform: A vendor withdrawing support or a runtime reaching end of life. The work is planned against the date rather than against the emergency.
Dependent integrations: Everything that quietly exchanges data with the old system, identified first and kept working, rather than discovered when it fails.
Maintainability after handover: Automated tests around the behaviour you rely on, so that the first change made after handover can be made with confidence.