Old internal software often survives because it does something valuable. Years of business rules have collected in its screens, reports and database, even when the original documentation and developers are gone.
Replacing it is therefore not a conventional greenfield build. The first job is to discover which behaviour is essential, which is merely familiar, and which workarounds exist because the system could not be changed.
Understand before rebuilding
We examine the data, observe users and trace important journeys through the current application. The existing code can help, but it is not treated as the specification. People and records reveal the operation more reliably.
Replace in controlled stages
The replacement is designed on a current, supportable stack with clear interfaces to the rest of the estate. Data migration is rehearsed and reconciled. Functions can move in phases, with parallel running where the consequence of a missed rule is high.
The cutover plan includes rollback, support and the retirement of the old platform. Launch is followed by monitoring and a planned period of close operational support.
Avoid creating the next legacy system
The delivered repository includes the application, infrastructure definitions and operating documentation. Automated tests cover the important rules, and deployment is repeatable. Ongoing hosting and maintenance are available through Run and improve systems.