Modernize a system when it blocks change, costs too much, or carries security or skills risk. Choose per system from seven strategies: retire, retain, rehost, relocate, repurchase, replatform, or refactor and re-architect. Work in steps, replacing piece by piece, with each step tested and reversible.
This is the main guide in our modernization series. The guide on modernizing without a big-bang rewrite covers the step-by-step method.
Signs a system needs modernizing
Five signals that a system is costing more than it returns:
- It blocks change: new features take months, or cannot be built at all.
- It costs too much: licences, hardware or specialist support rise every year.
- Security risk: the platform or its libraries no longer get security updates.
- Skills risk: one or two people understand it, and they may leave.
- It cannot connect: no APIs, so data is retyped between systems.
The cost of leaving it
Old code carries technical debt: shortcuts and outdated parts that make every change slower and riskier. CISQ's 2022 report estimated accumulated software technical debt in the US at about $1.52 trillion, within a total cost of poor software quality of at least $2.41 trillion. For a single business, the cost shows up as slow projects, outages and workarounds.
The seven strategies
AWS's public migration guidance lists seven strategies, often called the seven Rs. They apply on any platform:
- Retire: switch it off; its work is no longer needed or is done elsewhere.
- Retain: leave it as it is for now, and revisit later.
- Rehost: move it to new infrastructure largely unchanged, often called lift and shift.
- Relocate: move it to another hosting platform without changing the application.
- Repurchase: replace it with a bought product, often software as a service.
- Replatform: move it with small changes that take advantage of the new platform, such as a managed database.
- Refactor or re-architect: rebuild parts or all of it for the new platform; the most work, and the most gain.
How to choose a strategy
Score each system on two axes: business value (how much the business depends on it and how much it must change) and technical condition (how hard and risky it is to run and change). Low value, poor condition: retire or repurchase. High value, good condition: retain or rehost. High value, poor condition: replatform or refactor, in steps.
AWS's guidance notes that refactoring is not recommended for large migrations, because of the effort; keep the deepest work for the systems that matter most.
Modernizing in steps
Big-bang rewrites, where a new system replaces the old one on a single day, carry the most risk. Martin Fowler's strangler fig application (page dated August 2024) describes a gradual approach to legacy modernization instead: build new functionality alongside the legacy system and move behavior over piece by piece until the old system can be retired. Our guide to modernizing legacy applications walks through it.
The risks, and how to manage them
Modernization projects often fall short; BCG's 2020 research on 825 senior executives found that 70% of digital transformations fall short of their objectives. The usual risks:
- Lost behavior: old systems do things nobody documented. Record what it does before changing it.
- Data problems: migrations corrupt or lose data. Test on copies and reconcile counts.
- Running two systems: costs rise during the move. Keep the overlap short and planned.
- Scope creep: modernization turns into a redesign of everything. Agree the scope per step.
- People: users resist changed screens. Involve them early and train before switch-over.
Conclusion
Legacy system modernization updates old software so it is cheaper to run, safer and easier to change. Choose per system from seven strategies (retire, retain, rehost, relocate, repurchase, replatform, refactor), based on business value and technical condition, and modernize in steps rather than one rewrite, with each step tested and reversible.
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. Our modernization team assesses old software and moves or rebuilds it in steps, and our transformation planning work sets the order across systems. We are not a partner of any cloud provider.
The guides in this series
This is the main guide in our modernization series. Each guide below goes deeper on one part and links back here.
- How to modernize legacy applications: the step-by-step method, without a big-bang rewrite.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.