Legacy modernization approaches differ less in theory than in what the team does and which tools it needs. Rehost mostly needs infrastructure and migration tooling, replatform adds database and runtime work, refactor depends on test harnesses and code analysis, rebuild depends on specification recovery and data migration, and retire needs usage evidence and archiving. Pick the approach by the gap between the system's condition and the business's needs, then pick tools to fit.
This guide complements legacy system modernization options, which defines each option and explains the strangler pattern. Here the focus is execution: what the work involves, what categories of tools help, how the approaches compare in practice, and how to avoid buying tooling you do not need. For the decision about which application gets which approach, use the assessment checklist first. If you want a partner to carry the work, see legacy system modernization services.
What do the five approaches look like in practice?
| Approach | What the team actually does | Typical tool categories | Best fit | Watch out for |
|---|---|---|---|---|
| Rehost (lift and shift) | Copies the system as is onto new servers or virtual machines; changes network, backup and monitoring | Server and virtual machine migration tools, backup and restore, infrastructure as code, monitoring | Hardware is failing or a data centre is closing; the software itself still serves the business | Carries every old limitation to the new host; licence terms may not allow the new environment |
| Replatform | Moves to a supported operating system, runtime or database version with minimal code change | Database migration and schema comparison tools, container images, CI pipelines, regression test suites | Platform is unsupported but the code and design are acceptable | Behavior differences between database or runtime versions that tests did not cover |
| Refactor / re-architect | Restructures code, separates modules, adds an API layer, replaces the interface | Static analysis and dependency mapping, characterization tests, API gateway, feature flags, version control | Business logic is valuable but structure blocks change | Needs people who can read the old code; slow if tests are missing |
| Rebuild (rewrite) | Recovers the specification, builds a new system, migrates data and cuts over | Requirements capture, data profiling and ETL tools, parallel-run comparison scripts, automated test suites | Codebase beyond economic repair or requirements have moved on | Under-specified behavior; scope creep; long period with no visible gain |
| Retire | Confirms nobody needs the system, archives data, switches it off | Usage logs, access reviews, archive and export tools | Low value, low usage, or duplicate function | Hidden users and legal retention duties |
Two further options sit beside these: retain (leave it, document it, monitor it) and replace with a packaged product. The decision table later in this guide covers all seven.
Which tool categories matter, and when?
Tools do not modernize a system; people do. But the right category saves weeks at specific steps. Go through them in the order of a project.
Discovery and mapping
- Code and dependency analysis. Static analysis tools list modules, call relationships, unused code and library versions. Commonly used examples include the code search and analysis features of source control platforms and language-specific analyzers.
- Database schema inspection. Tools that reverse-engineer tables, keys and stored procedures into diagrams. Stored procedures often hold business rules that no one documented.
- Runtime observation. Logs, network captures and application performance monitoring show what the system really does: which screens are used, which interfaces fire at night, which batch jobs run.
- Usage evidence. Login records and transaction counts answer "who still uses this?" more reliably than interviews.
Making change safe
- Version control and a build pipeline. If the source is not in version control, that comes before anything else. A continuous integration pipeline that builds and tests every change turns a risky release into a routine one.
- Characterization tests. Where unit tests do not exist, write tests that record what the system does today for a set of inputs, then run them after each change. They protect behavior you do not yet fully understand.
- Test data management. Copies of production data with personal details masked, so developers can rehearse safely.
- Feature flags. Switches that route a percentage of users or one department to the new component, with an instant way back.
Moving data
- Profiling. Scripts or tools that count nulls, duplicates and out-of-range values before design starts.
- Extract, transform and load (ETL). From plain scripts to commercial data-integration platforms. For one-off migrations, tested scripts under version control are usually enough; a platform pays off when the same pipelines run for months.
- Reconciliation. Queries that compare record counts and totals between source and target. Build them early and run them after every trial load. See our ERP data migration checklist for a copyable version.
Running old and new together
- API gateway or facade. A thin layer that sends each request to the old or new component, which is how the strangler pattern routes traffic.
- Change data capture and message queues. Keep the old and new databases in step during a transition.
- Parallel-run comparison scripts. Feed the same transactions to both systems and compare outputs.
Operating the result
- Observability. Logs, metrics and alerts, so the new system does not become a black box in turn.
- Infrastructure as code. Environments you can rebuild from files rather than from memory.