An old application may still handle everyday work even though changing it is difficult. The problem appears when a developer proposes rebuilding everything while your company cannot stop accepting requests until the project finishes. The transition method becomes part of what you buy, alongside the new software's functions.
Phased replacement deserves discussion when particular functions can be separated while operations continue. It is not an automatic choice for every system: tightly connected dependencies or missing access may make a partial transition harder than another approach. Ask for an assessment explaining the choice before approving the schedule.
Choose a function whose transition can finish
In a fictional example, an equipment rental company manages service requests in an old application. It wants to receive requests through a new interface while technician dispatch temporarily remains in the previous system. The first phase is not “develop half the system”, but move a defined function with a beginning, an end and accountable people.
Ask who receives a request, where its number is assigned, which system updates its information and how it reaches dispatch. If an employee must copy every request manually, document the workload, its owner and when it ends. Do not hide the cost of coexistence inside the phrase integration between systems.
A five-field transition worksheet
| Field | Record with the developer | Acceptance question |
|---|---|---|
| Boundary | One function, its users and dependencies. | Do we know what remains in the old application? |
| Data authority | The system allowed to write each record type. | How are differences between copies resolved? |
| Pilot | A limited group and normal and exceptional cases. | What evidence is required before expansion? |
| Rollback | The stop decision and handling of subsequent writes. | Can work continue without losing new requests? |
| Retirement | Removed dependencies, an archive and an approver. | Is any hidden use of the old system left? |
Complete this worksheet for each phase; it is not a ready-made architecture specification. A starting point might be a read-only report or a relatively independent function. Another function may turn out to be unsuitable for separation yet. The choice should reflect actual operations rather than simply the order of screens.
Who controls writes during coexistence?
A record existing in two systems does not mean both should update it in the same way. In the example, the parties might agree to create service requests in the new system and send the information needed for dispatch to the old one, with a named authority for status changes. This is a proposed policy for the example, not a design for every project.
AWS guidance on gradual replacement discusses dependencies between functions and data consistency during coexistence. Microsoft's Strangler Fig pattern describes moving functions progressively while the old application remains available. These references explain tradeoffs; they do not require buying a particular cloud or converting every application into microservices.
Request evidence before expanding use
Agree on a sample covering request creation, amendment, cancellation and visibility to the next team. Add delayed data transfer and a temporary failure, then define how employees detect an exception and who resolves it. A request appearing on a new screen does not alone establish that its operational transition is complete.
A buyer could require every request in a defined fictional pilot group to be traceable between reception and dispatch, with differences explained before expansion. Sample size, duration and success criteria need agreement appropriate to the operation. This example supplies no standard success percentage or promise of a transition without downtime.
Rollback includes data added today
Ask directly: if we return to the previous application after accepting requests in the new one, where will the requests added during that period go? Restarting the previous version does not answer this by itself. Request a rollback rehearsal in an appropriate environment and a record of how new entries would be reconciled.
This decision distinguishes a transition plan from a backup restoration test. Restoration demonstrates an agreed recovery path; rollback between systems also needs rules for work completed after the switch. There may be a point beyond which reversal becomes expensive. Identify it before approval.
Give the temporary phase an end
Request an inventory of remaining uses: reports, exports, external connections, employee accounts and historical reading. Assign approval for ending each dependency and explain how necessary information remains available. Separate the cost of temporarily retaining the old application from building and maintaining the new one.
If you are still considering the underlying choice, read ready-made software versus custom development. When discussing software development with Nextwave, send one function example and the transition worksheet instead of a general request to rebuild everything. The discussion then starts with an outcome you can receive and assess.
Sources and limits
Both references were opened on 3 November 2026: Microsoft: gradual replacement and AWS: Strangler Fig pattern. They support coexistence and dependency and data risks. The acceptance worksheet and example are editorial proposals, not client project results.
