The best thing about a migration is the day it ends. Until then, Brandt Building Services pays twice: two ways that somebody has to test, two copies of every rule, a protective layer, switches, bridges and metrics for both worlds. Only with the switch-off does the rebuild turn into savings, and only then do you lose the way back. This lesson plans the end as carefully as the beginning.
Two terms up front. The old program is the version of the Order Book that talks directly to the database (DataSet, ADO.NET, Windows sign-in). Whoever keeps the Windows shell and shows the new pages in it (lesson M4.4) removes the old way from it; whoever replaces it entirely with the web switches the program off. The procedure below applies to both, and where they differ, it says so. And the facade in the sense of the strangler fig pattern is, for us, not a proxy but the shared API together with the selector (lesson M1.4).
What Microsoft says about the end
Microsoft's documentation on the strangler fig pattern describes the end in three sentences that count for the Order Book:
- Once all features are migrated and there are no more dependencies on the legacy system, it is decommissioned; after that the facade is removed, and the client talks directly to the new system.
- The facade can also be kept, as an adapter for legacy clients, while the core is renewed for newer clients. Microsoft calls it a transitional architecture, whose benefit (less risk) has to be weighed against its limited-time costs.
- For the database: The way back stays open as long as the old structures and the synchronization are still there. Whoever removes the old objects would have to restore them and replay changes, which raises effort and risk considerably. Removal is therefore a deliberately last step, only after the validation of the new system.
From this follows the order of the lesson: first everything that can be reversed (block access, observe), last everything that cannot be reversed (contract, delete).