Choose between modernization and a rewrite by identifying the business constraint, the part of the system causing it, and the evidence needed to change that part safely. The age of the code alone does not establish which approach will work.
Modernization may involve changing one component, adding an interface, improving a release process, or replacing larger portions over time. A rewrite creates a new implementation, but still needs a plan for existing behavior, data, integrations, and users.
Name the outcome before the approach
Replace “we need a modern stack” with an observable requirement. For example: staff must be able to change approval rules without a release, or a new customer portal needs access to order status. These are hypothetical outcomes, not claims about a particular project.
Document the current limitation and how you will judge improvement. Include the cost of keeping the old system running during the work. An attractive new architecture does not remove that operational responsibility.
Compare options against the same constraint
| Option | A reason to investigate it | Evidence needed before commitment |
|---|---|---|
| Improve the current application | The required change is bounded and the surrounding system remains useful | A reproducible build, understood dependencies, and tests for affected behavior |
| Add an integration or interface | A new workflow can use existing business capabilities | Suitable access, data ownership rules, and failure handling |
| Replace a component gradually | The application has boundaries that can support coexistence | A routing or transition plan, compatible data, and rollback criteria |
| Replace the application | The required behavior cannot reasonably be supported by the existing system | A migration plan, validated replacement scope, and an operational transition plan |
Microsoft’s description of the Strangler Fig pattern explains gradual replacement through an intermediary that routes requests. It also identifies limitations, including situations where requests cannot be intercepted. Treat it as one possible approach, not a default architecture. Microsoft architecture guidance.
Investigate what the old system actually does
Interview the people using and supporting the application. Identify manual workarounds, scheduled jobs, exports, and integrations that may not appear in the visible interface. Separate behavior that must be preserved from behavior that should be deliberately changed.
Create a dependency list with an owner for each connection. Mark unknown dependencies as investigation work rather than silently including them in a fixed implementation estimate.
Define the release evidence
For the first change, agree which workflow will be tested, which representative records will be compared, and who can approve the result. Include unsuccessful operations, not just a demonstration of the happy path.
If data will move, define how to reconcile the old and new records and how to handle writes during transition. If the change fails acceptance, know whether you can return to the previous state and what work that requires. Do not assume a deployment rollback also reverses a data change.
Buy the next decision, then the implementation
When uncertainty is high, scope an assessment with explicit outputs: the current constraint, dependency map, options, unknowns, and a recommended first implementation step. Agree its commercial terms separately from a larger build.
A useful assessment should narrow the decision. It should not simply restate that the system needs modernization. Use those outputs to request comparable proposals and review the software handover checklist when defining delivery responsibilities.
Put it into practice.
Explore our software modernization services service or send us the problem you are working on.