A Replacement Is Not Finished Until the Old Component Has No Callers and Is Switched Off
The most common outcome of a migration is not failure; it is two systems where there was one. The new one is live, the old one still runs because something might still be using it, and nobody can prove that nothing is. That state costs money every month, doubles the surface that has to be patched and monitored, and quietly makes every later change harder, because a change now has to be made twice or reasoned about twice. Retirement is therefore a designed piece of work with a sequence, not a tidy-up. Announce the component deprecated with a date. Measure who still calls it, using its own traffic rather than a search of the code, because callers you do not know about are exactly the ones the search misses. Give the remaining callers the replacement and a deadline. Then turn it off in a way you can undo for a short window, before deleting anything, so that a caller you missed announces itself while recovery is still cheap. Finally remove the resources and the access it held, and record the date. You can now write the ending of a migration plan: how you will know the last caller is gone, and what switching off actually consists of.
This Concept is waiting for its first lesson!
The most common outcome of a migration is not failure; it is two systems where there was one. The new one is live, the old one still runs because something might still be using it, and nobody can prove that nothing is. That state costs money every month, doubles the surface that has to be patched and monitored, and quietly makes every later change harder, because a change now has to be made twice or reasoned about twice. Retirement is therefore a designed piece of work with a sequence, not a tidy-up. Announce the component deprecated with a date. Measure who still calls it, using its own traffic rather than a search of the code, because callers you do not know about are exactly the ones the search misses. Give the remaining callers the replacement and a deadline. Then turn it off in a way you can undo for a short window, before deleting anything, so that a caller you missed announces itself while recovery is still cheap. Finally remove the resources and the access it held, and record the date. You can now write the ending of a migration plan: how you will know the last caller is gone, and what switching off actually consists of.
Are you a teacher? Sign in to start contributing.
Sign In