Legacy modernisation

Because a full rewrite must match years of behaviour before it can replace anything, while the business keeps changing around it. Such projects often run long and launch with gaps. Replacing one capability at a time delivers value early, keeps the old system as a safety net, and lets you stop or change direction at any step.

The approach is designed so that it does not. The old system keeps running while each new part is built and proven in parallel. Work moves to the new part gradually, and can move back if something is wrong. Where a data migration needs a switch-over, we rehearse it first and schedule it with you.

Yes, and that is common. We recover the knowledge from the code, the data, the logs and the people who use the system, and we capture what it actually does in characterisation tests. Those tests become the specification the new parts must meet, so undocumented behaviour is kept unless you decide to change it.

The size and complexity of the old system, the quality of its data, the number of systems that depend on it, and how much must change rather than be kept. Old languages and databases that few engineers know add effort. Because the work is incremental, you can fund it in stages and see each stage’s result before approving the next.

We map and profile the data first, so problems are found before migration rather than after it. Migrations are scripted and repeatable, run against copies first, and reconciled with counts and totals that show nothing was lost or altered. Personal and sensitive data is protected throughout, and access to it is limited to named people.

When the old core is stable and correct but hard to reach. Modern APIs in front of it let new channels, partners and products use its functions without touching its internals, at far lower risk than replacing it. We recommend replacement when the system blocks change, cannot be secured or can no longer be staffed.

We work with the stacks many business systems were built on, including older versions of Java and .NET, relational databases such as Oracle Database and SQL Server, SOAP services and file-based interfaces. For rarer platforms we assess the code first and tell you plainly whether we have the skills, or whether a specialist should join the team.

Access is granted per person, limited to what each role needs, and removed when that person leaves the project. We work in your repositories and environments if you prefer, use multi-factor authentication, and keep secrets in a vault, never in code. Code is reviewed before it is merged, dependencies are scanned, and production data is not copied into test environments without masking. We agree these controls with your security team at the start.