Incremental modernization is worth considering when a function has boundaries you can identify and compatibility you can test. A technology’s age alone is not a reason to rewrite the whole system. Compare the risks of staying, migrating and temporarily operating two systems before choosing a route.
Name the problem you need to solve
Is a critical report unreliable? Does the permission model prevent a new branch from opening? Are security updates no longer available? These are different problems. Some need maintenance, tests or database work rather than replacement. A redesigned interface will not resolve business rules nobody has agreed.
Inventory known data sources, integrations, scheduled jobs, files and reports. Mark unknowns explicitly. Screens are not the entire contract: an overnight export may be essential to a department that never uses the interface. Involve those downstream users before selecting the first component to replace.
Choose a first boundary deliberately
| Factor | Promising separation candidate | Reason for deeper discovery |
|---|---|---|
| Interface | Known inputs and outputs | Direct writes across many shared tables |
| Acceptance | Reproducible comparison examples | Success depends on one person’s memory |
| Data | One write owner and defined exchange direction | Competing writers without conflict rules |
| Reversal | Old path can resume safely | New side effects cannot easily be undone |
| Operations | Named monitoring and cutover owners | No reliable visibility or decision authority |
This is not an automatic scoring exercise. A single serious risk, such as losing financial records, can outweigh otherwise simple boundaries. Business owners and engineers must agree what evidence is needed before proceeding.
Consider a limited reporting example
A read-only reporting component may be a suitable first experiment if its inputs and data-access permissions are well understood. Compare its results with the current report using controlled data, investigate differences and let representative users review them. Only then consider routing a limited group to the replacement.
This is a proposed approach, not a client case study or a claim that all reports can be separated. Copying data introduces its own access, retention and privacy obligations. For a write-heavy function, define who owns writes during transition and how records created after cutover will be handled if the team returns to the old path. “Run both systems” is not a plan when both can alter the same business fact.
Plan reversal before changing traffic
Set stop conditions, name the cutover decision-maker and test the recovery procedure in an isolated environment. Retain actual observed timings, but do not turn one rehearsal into an unconditional recovery promise. Include monitoring, reconciliation, temporary dual operation and data cleanup in the estimate.
Track the remaining dependency on the old system. A temporary bridge with no retirement criterion can become another permanent system to maintain. Decide what evidence permits each next step and what would stop the programme.
This work differs from ongoing maintenance. Use legacy modernization assessment and the Laravel takeover checklist to identify what must be discovered before pricing a full rebuild.
Sources and editorial status
- Microsoft: Strangler Fig pattern.
- Martin Fowler: Strangler Fig Application.
- Original contribution: the first-boundary decision card and illustrative reporting experiment.
