Comparison
Feature parityvsSunsetting
Feature parity
the replacement was blocked for two months on a report that four people run once a year.
The requirement that a replacement do everything the thing it replaces did. It is where most migrations go to die, because the last ten percent of features are used by the smallest number of people and take the longest, and nobody is empowered to say a feature will simply be dropped. The conversation that unblocks it is a usage-based one: name who uses each remaining feature, how often, and what happens if it goes.
Full entry →Sunsetting
the replacement went live a year ago and the old service is still running because nobody proved it was idle.
The deliberate process of turning something off: announcing it, migrating remaining users, and deleting it. It is the step that converts a migration from a cost into a saving, and it is routinely skipped because it delivers nothing visible. The technique that actually works is to make the old system prove it is unused — turn it off for an hour, watch what screams — rather than to wait for certainty that will never arrive.
Full entry →