For a CTO managing a mixed estate, application modernisation starts with deciding what each application needs and which decisions take priority. Some applications can be retained with appropriate support and oversight. Others need stabilising, moving to a supported platform, improving or replacing.
Before choosing a cloud platform, target architecture or technology, establish what business capability the application supports, where it creates constraints and what risks and costs it carries. Use that evidence to compare the viable options, justify the investment and determine how the change can be delivered safely.
Application modernisation starts with the business requirement
Application modernisation changes an existing application so it can support current and future business requirements. Before committing to that work, assess whether the application needs changing, retaining or retiring.
Cloud migration may form part of this work, but moving an application does not necessarily resolve limitations in its code, architecture or business processes.
AWS’s 7 Rs describe migration strategies – retain, retire, rehost, relocate, repurchase, replatform and refactor or re-architect. These provide a useful reference, but selecting an approach still requires evidence about the application’s business value, technical condition, costs and risks.
For a CTO, the central question is; what does each application enable the business to do, and what should happen to it as requirements change?
Applying one strategy across the estate can leave important constraints unresolved or create unnecessary work. Each decision should address a defined business need and account for the application’s dependencies.
This article focuses on choosing and validating an approach for each application.
For guidance on planning change across the wider estate, see our guide to legacy system modernisation or its Legacy Systems service.
Application modernisation assessment. Six questions to ask first
Age alone does not tell you whether an application needs modernising.
An older application that remains supported, sufficiently secure, stable and affordable may be a lower priority than a newer system that is unreliable, expensive to change or blocking a critical programme.
The UK Government’s Legacy IT Risk Assessment Framework illustrates how to assess risk using evidence about support status, available skills, security vulnerabilities, previous failures and the ability to meet business requirements. It considers both the likelihood of problems and their potential impact.
For each application, answer six questions. Record the evidence behind each answer and identify where further investigation is needed.
| Question | What you are trying to establish |
|---|---|
| 1. Does the business still need this capability? | Which services, users and processes depend on this capability; whether the capability is duplicated elsewhere; and what would happen if the application were retired. |
| 2. What risks and costs does the current application carry? | Security, resilience, support and skills risks; the consequences of failure; running and maintenance costs; and the cost of delayed business changes. |
| 3. Where is the constraint? | Whether the problem sits in infrastructure, runtime, database, code, architecture, integrations, data or the business process itself. More than one may be involved. |
| 4. Can it support future business requirements? | Whether the capability can accommodate the expected changes in demand, services, integration and ways of working and what would need to change if it cannot. |
| 5. What needs to remain bespoke? | Whether custom software provides a necessary capability or meaningful advantage and whether an established product could meet the requirements with acceptable integration, control and supplier dependency. |
| 6. What change is feasible and how can it be delivered safely? | Dependencies, service continuity requirements, data migration, delivery capacity and budget, including the cost and complexity of running old and new systems together. |
These answers should produce a shortlist of plausible approaches. A constraint in the code or architecture, for example, may justify refactoring, rebuilding or replacing the application.
The next step is to compare those options using evidence about what can be preserved, what each would cost and which risks each would remove or introduce.
Delivery constraints can change the preferred approach. An application may need stabilising first, or the work may need to proceed in stages while dependent services continue operating. Budget and available skills also affect whether an option is viable.
Treat the preferred approach as a hypothesis to validate before committing to wider delivery. For related financial analysis, our guide to calculating technical debt and the cost of legacy software examines cost, risk and opportunity in more detail.
The application modernisation decision framework
Use the assessment to compare the approaches that could meet the business requirement. Different applications may need different treatments and one application may need a sequence of interventions.
The table sets out seven treatments and the evidence needed to justify each.
| Treatment | When to consider it | What you need to establish |
|---|---|---|
| Retain | The application continues to meet business requirements at an acceptable cost and level of risk. | It can remain supported and maintained, with clear ownership, accepted risks and triggers for reassessment. |
| Retire | The application is no longer needed or its capability is provided elsewhere. | Dependent services and users can operate without it and data retention, access and archiving requirements can be met. |
| Rehost | Hosting or infrastructure is the main constraint, while the application remains fit for purpose. | Moving it largely unchanged will address that constraint without introducing unacceptable performance, security or operating costs. |
| Replatform | The runtime, database or supporting platform creates a constraint. | Platform changes can deliver the required improvement without extensive redesign of the application or its business logic. |
| Refactor | Valuable business logic can be preserved, but the code or architecture makes change difficult. | Improving the existing implementation is viable and its benefits justify the cost and risk compared with replacing or rebuilding it. |
| Replace | An established product could meet the required business capability. | Its functional fit, integration, data migration, ongoing costs, supplier dependency and exit options are acceptable. |
| Rebuild | Bespoke capability remains necessary and improving the existing implementation is unlikely to provide a viable foundation. | A new application is justified against refactoring and product alternatives, with a credible delivery, migration and ownership plan. |
Compare viable options over the same period. Include delivery and migration costs, any period of parallel operation, ongoing support costs and the cost of retiring the old implementation. Assess which constraints each option resolves and which risks or dependencies it introduces.
Before committing to the preferred treatment, identify the assumptions most likely to change the decision and the smallest credible test of each. That might be a dependency investigation, an architecture spike, a product-fit assessment or a working replacement of one capability.
Legacy application modernisation. When retain or retire is the right answer
An application’s legacy status does not, by itself, justify changing it. The decision should reflect its continuing business value, operating cost and risk.
Retain
Retain an application when it continues to meet business requirements at an acceptable cost and level of risk. This can allow investment to focus on systems where intervention is more urgent or valuable.
Retention needs clear ownership and ongoing oversight. Record:
- who is responsible for the application
- the support status of its software and infrastructure
- the services, integrations and data that depend on it
- the risks being accepted and who has accepted them
- when the decision will be reviewed and what would trigger earlier action
Unsupported technology requires particular care. Once security updates are no longer available, vulnerabilities may remain unresolved. Measures such as restricting access and isolating the application can reduce exposure, but continued use needs an explicit risk assessment, regular review and a plan to address the unsupported components.
Retire
Retire an application when its capability is no longer required or can be provided adequately elsewhere.
Before decommissioning it, confirm which users, integrations and downstream processes still depend on it. Low usage does not necessarily mean low importance. An application may support an infrequent but essential process.
Establish what data must be retained, how it will remain accessible and which legal or operational requirements apply. Include the work needed to remove integrations, decommission infrastructure, end unnecessary licensing commitments and verify that dependent services continue functioning.
Retirement delivers value when the application and its associated costs and dependencies can actually be removed.
Application modernisation without a rewrite. Rehost or replatform
An application may still meet business requirements while its hosting environment or supporting platform creates unnecessary cost, support difficulties or operational risk.
Rehosting and replatforming address these constraints, although both require evidence that the application will operate correctly in the new environment.
Rehost
Rehosting moves an application to different infrastructure with little or no change to the application itself.
Consider it when:
- existing infrastructure is approaching end-of-life
- hosting arrangements are expensive or inflexible
- infrastructure consolidation would reduce operating complexity
- the current environment cannot meet availability or recovery requirements
Check compatibility, performance, connectivity, security and recovery arrangements before committing. Moving the application may resolve the hosting problem while leaving limitations in its code, architecture and delivery processes unchanged.
Compare the full operating cost of the new environment, including licensing, data transfer, monitoring and support. A move does not automatically produce savings or greater resilience.
Replatform
Replatforming changes the supporting technology while preserving much of the application’s existing structure and business logic.
Examples include moving a database to a managed service, updating middleware or adopting a supported runtime. The extent of the required changes matters. Switching database technology may involve substantial changes to queries, data structures and application behaviour.
Assess whether the platform change will address the identified constraint and how much application modification, regression testing and operational retraining it requires.
If the main problem is tightly coupled code, unclear business logic or an architecture that prevents safe change, rehosting or replatforming alone is unlikely to resolve it.
Application modernisation by refactoring. Preserving valuable business logic
Refactoring is worth considering when the application supports a necessary capability and contains business logic worth preserving, but its implementation makes change difficult.
Signs that warrant investigation include:
- tightly coupled components that cannot be changed independently
- fragile integrations or poorly understood dependencies
- releases that require extensive manual testing
- limited automated test coverage
- routine changes that require work across several parts of the application
- maintenance knowledge concentrated in a small number of people
These symptoms do not automatically justify refactoring. Some may require better testing, documentation or engineering practices alongside changes to the code.
In this framework, refactoring includes restructuring code and, where necessary, reworking the architecture while preserving required business behaviour. Establish that behaviour through tests and evidence from users, documentation and the running system.
Do not assume refactoring will be cheaper than replacement or rebuilding. Investigate the dependencies, identify which parts can be improved independently and test whether an initial change delivers the expected benefit.
The investment case should explain what is worth preserving, which constraints will be removed and how the application will become easier to maintain and change.
Replace or rebuild. When improving the existing application is insufficient
Replacement or rebuilding becomes worth considering when changes to the existing application are unlikely to meet the business requirement at an acceptable cost and level of risk.
Compare both options with refactoring before committing. Our guide to legacy software modernisation versus replacement explores this decision in more detail.
Replace
In this framework, replacement means adopting an established product to provide the required capability.
Assess whether the product can support the business’ essential requirements without extensive customisation. Include:
- functional fit and any changes to business processes
- integration and data migration
- security, accessibility and regulatory requirements
- implementation, licensing and ongoing support costs
- control over data and dependence on the supplier
- contractual exit terms and the practical cost of moving later
A product can reduce the burden of maintaining custom software, but configuration, integrations and supplier management still require ownership.
Rebuild
Rebuilding means creating a new bespoke application. It may be justified when the required capability cannot be met adequately by an established product and the existing implementation is not a viable foundation.
Start with the business outcomes, user needs and rules the new application must support. Review existing features and workflows before carrying them forward. Some will remain essential, while others may reflect requirements that no longer apply.
The delivery plan should establish how data will be migrated and reconciled, how continuity will be maintained and how the old application will eventually be retired.
Aldermore Bank illustrates the importance of control as well as technical capability. Its existing digital banking platform had limited flexibility and scalability and the bank lacked the IP ownership needed to control and customise it fully.
Catapult CX delivered a new cloud-native platform using a Minimum Viable Replacement approach to support continuity during transition. The platform went live with no major incidents and the published case study reports improved customer experience and reduced manual work.
The relevant decision was whether a new platform could provide the capability and control the bank needed, with a credible path through delivery and migration.
Strangler Fig pattern. Delivering application modernisation incrementally
Replacing a critical application through a single cutover can concentrate delivery and operational risk. Where functionality can be separated, the Strangler Fig pattern offers a way to introduce a new implementation progressively.
Martin Fowler’s description of Strangler Fig centres on gradually creating a new system around the existing one. Responsibility for individual capabilities moves to the new implementation until the old system can be retired.
Assess whether:
- capabilities have boundaries that can be separated and tested
- requests can be directed to the appropriate implementation
- old and new systems can operate together
- data ownership and synchronisation can be managed during transition
- each stage can be validated against business and service requirements
- there is a credible plan to remove the remaining legacy components
Incremental delivery introduces its own costs and complexity. Temporary integrations, parallel operation and data consistency need active management. Define what each stage will replace, how its success will be measured and when the superseded components can be removed.
Strangler Fig helps deliver an agreed replacement or rebuild. The business and technical evidence must still justify that underlying decision.
Our guide to the Strangler Fig pattern for legacy modernisation covers capability boundaries, data migration, testing and eventual legacy retirement in more detail.
Application modernisation priorities. Sequence the portfolio, not just the application
Once you have identified a preferred approach for each application, decide what happens first. The most outdated technology will not necessarily warrant the earliest investment.
Prioritise using four factors.
- Business impact
Identify the services, customers, employees, revenue and statutory responsibilities that depend on the application. Consider the consequences of disruption across those dependencies. - Risk exposure
Assess the likelihood and impact of failure, security vulnerabilities, loss of support or an inability to make essential changes. Include deadlines such as support expiry or contractual changes that may make intervention time-critical. - Constraint on future value
Identify which business initiatives the application is delaying or preventing. Establish the value of resolving the constraint and the cost of leaving it in place. - Delivery feasibility
Determine whether a useful improvement can be delivered safely with the available skills, budget and capacity. Map work that must happen first, including changes to shared infrastructure, integrations or data.
Use these factors to build a sequence of work. A high-priority application may need immediate stabilisation while a longer-term solution is assessed. Another may need preparatory work before its preferred treatment becomes feasible.
For financial services firms within scope, the FCA’s PS21/3 and the PRA’s SS1/21 set operational resilience requirements around important business services, impact tolerances, mapping and testing. Assess how application weaknesses and proposed changes affect the firm’s ability to remain within those tolerances.
Business criticality determines the care and urgency required; it does not, by itself, justify rebuilding.
Catapult CX’s work with a global network provider illustrates this. After a platform consolidation caused severe instability, we stabilised and simplified the existing environment through infrastructure improvements, reduced component complexity and stronger testing.
The published results included message failures falling from 12% to 0.3% and the release outage window reducing from 21 days to around 30 minutes. Targeted intervention restored performance without replacing the platform.
A controlled application modernisation programme
For the highest-priority applications, turn the assessment into a proposal that can be tested before wider delivery investment.
Establish six things:
- Current-state evidence
Document architecture, dependencies, support status, costs and delivery constraints. Include context debt – undocumented knowledge about manual workarounds, why they exist and which processes depend on them. Validate this with operational teams. - A measurable business outcome
Define what must improve or become possible, the current baseline and how success will be measured. - The preferred treatment and alternatives
Explain why the proposed approach is preferable to the other viable options. Compare delivery costs, transition risks and ongoing ownership requirements. - Critical assumptions
Identify what must be true for the approach to succeed, including technical feasibility and operational dependencies. Confirm which workarounds and related processes must be preserved, redesigned or made unnecessary. - The smallest credible test of those assumptions
Choose an architecture spike, proof of concept, prototype, dependency test or Minimum Viable Replacement. Test affected processes, exceptions and manual interventions alongside the software to establish whether the approach works in practice. - Criteria for proceeding, changing direction or stopping
Agree what evidence is sufficient, who makes the decision and which unresolved risks would prevent wider delivery.
Record the findings and update the proposal before committing to the next stage. Include named owners, the resources required and any conditions that must be met.
Catapult CX’s Modernisation Readiness Review assesses the existing estate and business requirements to identify what can be reused, replaced or retired before significant delivery investment.
Our Legacy Systems service supports the subsequent engineering work, using targeted proofs of concept and Minimum Viable Replacements to test critical elements and plan controlled change.
Establish what your applications need next
Tell us which application is causing concern, what it is making difficult and what you know about the problem so far. You don’t need a complete technical assessment to start the conversation.
We’ll help you understand the options and identify what needs investigating or testing before you commit to change.
Talk to Catapult CX about your application
Application modernisation FAQs
What is application modernisation?
Application modernisation changes an existing application so it can meet current and future business requirements. It may involve updating its platform, restructuring code, redesigning its architecture or replacing functionality. An assessment should first establish whether change is justified. Retaining or retiring the application may be the appropriate decision.
Is application modernisation the same as cloud migration?
No. Cloud migration moves workloads to a cloud environment. Application modernisation addresses limitations that prevent an application from meeting business requirements. The two can happen together, but moving an application to the cloud does not automatically resolve problems in its code, architecture, integrations or business processes.
How do you choose an application modernisation strategy?
Assess the application’s business value, technical condition, risks, costs and future requirements. Identify the constraints, then compare the viable options – retain, retire, rehost, replatform, refactor, replace or rebuild. Include delivery feasibility, migration and ongoing ownership costs. Test the assumptions most likely to change the decision before committing to wider delivery.
Do all legacy applications need to be modernised?
No. An application that remains supported, sufficiently secure, stable and able to meet business requirements may be retained at an acceptable cost and level of risk. Retention still requires ownership, maintenance and regular review. Unsupported components, unresolved vulnerabilities or changing requirements may make intervention necessary.
What is the difference between application modernisation and legacy modernisation?
The terms overlap. Application modernisation focuses on individual applications, while legacy modernisation can also encompass infrastructure, data, integrations and operating practices across a wider estate. This guide focuses on choosing an approach for each application. Our guide to legacy system modernisation covers planning change across the estate.
What are the AWS 7 Rs of migration?
The AWS 7 Rs are retain, retire, rehost, relocate, repurchase, replatform and refactor or re-architect.
They provide a useful reference for cloud migration decisions. Several overlap with the treatments in this guide. Repurchase broadly corresponds to adopting a replacement product, while refactor or re-architect can include substantial application redesign. This guide distinguishes rebuilding as a separate investment decision; the terminology is not an exact one-to-one mapping.
Can a critical application be modernised without a single large cutover?
In some cases, functionality can move to a new implementation in stages using the Strangler Fig pattern. This requires separable capabilities, controlled routing, clear data ownership and evidence that old and new systems can operate together safely. Incremental delivery still needs a plan to retire the superseded components.
