Legacy software modernization: plan the migration before the build

01Know why you are modernizing

Modernization should solve a business problem: a system that can no longer be supported, changes that have become slow and risky, security exposure, or running costs that keep rising. Name the problem and how you will measure success first; it decides how much actually needs to change.

02Choose the approach

The common options differ in risk, effort and how long the old system stays in service.

• Rehost: move the system to new infrastructure with minimal code change.
• Refactor: improve the existing code and architecture while keeping its behavior.
• Replace gradually: build new modules around the old system and retire it piece by piece — the pattern Martin Fowler named the strangler fig.
• Rebuild or replace: write a new system or adopt a product, then migrate the data in one or more cutovers. See custom software vs off-the-shelf.

03Map what the old system really does

Legacy systems carry undocumented rules in their code, their reports and people’s habits. Before estimating, inventory the integrations, scheduled jobs, reports, data-quality problems and the workarounds staff rely on. This is where a software discovery phase earns its cost.

04Treat data migration as its own project

Most of the risk sits in moving data, not in writing new screens.

• Profile data quality early and agree who fixes bad records.
• Rehearse the migration on full copies of production data.
• Define reconciliation checks that prove the data arrived intact.
• Agree rollback criteria before cutover day, not during it.

05Learn from a public failure

In April 2018, TSB Bank’s migration of customer accounts to a new IT platform disrupted branch, telephone, online and mobile banking, and the bank did not return to business as usual until December 2018. In December 2022, the UK’s Financial Conduct Authority and Prudential Regulation Authority fined TSB, finding that it had failed to organise and control the migration programme adequately and to manage the operational risks of its outsourcing to an IT supplier; the FCA also pointed to an overly ambitious timetable and insufficient testing. Governance, testing and supplier oversight matter as much as the new code.

06Questions to ask a legacy modernization partner

Use these to separate experienced modernization teams from general development shops:

• Which approach do you recommend for our system, and what would change your mind?
• How will you discover the business rules nobody has written down?
• How will the old and new systems run side by side, and for how long?
• What are the rollback criteria and plan for each cutover?
• Who owns the code, data and infrastructure afterwards?

07What drives the effort

The size and quality of the data, the number of integrations, how much existing behavior must be preserved exactly, and how long both systems must run in parallel. The custom software development cost guide covers these drivers, and choosing a custom software development company covers what a proposal should state.