Who this is for: Technology leaders, application owners and operations teams
An existing application often contains years of operating knowledge alongside constraints that slow the business down. Replacing it therefore requires understanding what the system does for people, including behaviour that may never have been formally documented.
A staged approach can give the team smaller decisions to evaluate. It also creates coexistence work that needs deliberate design. The following planning sequence is a useful starting point; the right approach depends on the application and its dependencies.
Choose a specific operating problem
Describe the capability that needs to improve and why. Examples might include a difficult integration, a slow release process or a workflow that forces people to re-enter information. Connect the change to the people affected and the result they need.
Review the current behaviour with users and maintainers. Identify the reports, exceptions and downstream processes that rely on it. This gives the team a more useful boundary than a broad instruction to rebuild everything in a newer framework.
Find a boundary that can be changed
Select a capability that can be tested and accepted with a manageable set of dependencies. Examine where requests enter, where data is changed and which other systems expect a response. The cleanest conceptual boundary may still need practical integration work.
Microsoft's Strangler Fig pattern describes gradually replacing parts of a system while routing requests between old and new implementations. It is one reference to consider, not a prescription for every application.
Design coexistence explicitly
Agree which system owns each relevant record and how updates move between systems. Decide what happens if an integration fails or a request reaches an unexpected version. Avoid leaving these questions until the first release is already in use.
Coexistence has an operating cost. Track temporary adapters, duplicated behaviour and extra support tasks. Give the team a clear plan for removing them when the transition conditions are met.
- Ownership of records and updates.
- Request routing and compatibility expectations.
- Failure handling, reconciliation and observability.
- Responsibilities for temporary transition components.
Accept the new capability and retire the old one
Test with representative cases and compare the result with the agreed operating requirements. Include the people who use reports or complete exception workflows. Technical deployment alone does not establish that the capability is ready.
Agree the conditions for retiring old behaviour, including data verification, support readiness and any rollback limitations. Retirement should be a planned stage with an owner; otherwise an apparently complete project can leave two systems to maintain.
A staged modernization planning checklist
Use this checklist to shape a first modernization slice and its review point.
Treat the first slice as a learning exercise for the operating model as well as the software. Review which dependencies were missed, how support handled coexistence and whether users adopted the new workflow. Apply that learning before repeating the pattern across the rest of the estate.
- A specific business problem and acceptance measures.
- An understood capability boundary and dependency map.
- A plan for record ownership and coexistence.
- Representative tests and operational observations.
- Clear release, recovery and support responsibilities.
- Defined conditions for retiring old components.
Frequently asked questions
Is staged modernization always possible?
No. Architecture, dependencies and operating constraints may limit how a system can be separated. Assess those constraints before committing to a staged transition.
Should we move to microservices first?
Choose an architecture based on the capability, team and operating requirements. A change in architectural style is useful only when it addresses an actual requirement and can be maintained.
How do we know a stage is complete?
Use agreed acceptance measures, integration and data checks, support readiness and the retirement conditions for the replaced behaviour.
Sources and further reading
Technical references supporting the topics discussed above. The decision frameworks and recommendations are Codersbay editorial guidance.
- Strangler Fig pattern (opens in a new tab)Microsoft Azure Architecture Center
