A business-critical application rarely exists on its own. It sits inside a web of reports, approvals, integrations, operational habits, and undocumented exceptions. Replacing the code is only one part of replacing the system.
Modernisation should make a service easier to change and safer to operate. The best starting point is a clear business problem: a slow customer journey, fragile integration, expensive manual process, or component that can no longer be supported.
Start with the operational map
Before choosing a new framework, document who uses the system and what they depend on. Talk to operations, customer service, finance, security, and the people who run month-end processes. Their work often reveals dependencies that an architecture diagram misses.
Build a small inventory of interfaces, scheduled jobs, reports, databases, permissions, and support procedures. Record the owner of each dependency and how a failure would be detected. Separate confirmed behaviour from assumptions that still need testing.
Choose a boundary small enough to understand
A useful first slice has a clear user need, a manageable data boundary, and a measurable outcome. It might be an application-status enquiry or a document submission flow. Begin with a contained workflow rather than attempting to replace every screen and integration together.
The Strangler Fig pattern describes gradually moving functionality from an existing system to a replacement. A routing layer can direct traffic to either implementation while the transition takes place. It introduces its own operational complexity, so the boundary and the temporary architecture need deliberate ownership.
Treat data migration as a product decision
Agree which system owns each record during the transition. Define how changes are synchronised, how conflicts are handled, and how the team will reconcile totals and exceptions. A successful database import does not prove that the business can trust the result.
Avoid an informal arrangement where both applications write to the same tables without a clear contract. If a shared database is temporarily necessary, document the constraints, monitor the risks, and define the conditions for removing that dependency.
Make the release observable and reversible
Before moving real users, establish a baseline for completion rates, errors, latency, support requests, and business reconciliation. Check the new implementation against realistic scenarios, including interrupted sessions, failed dependencies, and permissions.
- Define the release owner and the people who can make a rollback decision.
- Rehearse the deployment and rollback with the database changes included.
- Agree the signals that would pause or reverse the rollout.
- Prepare a support note that explains the user-visible change and the escalation route.
A rollback plan must account for data created after release. Restoring old code may be insufficient if the new version has changed records or introduced an incompatible schema. Prefer changes that let old and new versions coexist safely during the transition.
Know when a rewrite is justified
Incremental replacement is not always the right choice. A small application with few dependencies may be simpler to replace outright. A platform approaching an unavoidable support deadline may require a different migration plan. The decision should reflect business risk, the available time, the quality of the existing interfaces, and the team’s ability to operate two systems.
Useful modernisation produces evidence at each step: a simpler workflow, fewer manual interventions, a clearer integration boundary, or a safer deployment. Progress becomes easier to defend when the team can show what improved and what risk remains.
Further reading: Microsoft Azure Architecture Center — Strangler Fig pattern.