When a feature disappears, the fallback is part of the change

A removed feature is not only a product decision. It is a broken route for someone who had already built work around it.

The painful cases are usually practical: a free export becomes paid, an old search filter disappears, a print button moves behind a new menu, a bulk edit tool is removed, or a familiar shortcut stops working after a redesign. The product team may have a good reason. The user still needs to finish the old task today.

A responsible change record should therefore include the fallback, not just the announcement. If export is now paid, what can a user still download for free? If a filter is removed, what query or page replaces it? If a shortcut is gone, how long does the old route remain? If a permission changes, who can approve the same task now?

The fallback does not have to preserve everything. It does have to say what remains possible and what is gone. A user can accept a worse route more easily than a silent disappearance. The worst version is when support has to answer with guesses because the public note says only that the interface was improved.

There is also a timing issue. A fallback that appears after complaints is weaker than one that ships with the change. The moment a known path stops working, the user should see where to go next. If the change has a grace period, the record should say when the old route ends. If there is no grace period, it should say why.

The useful fields are simple: old task, removed or changed path, new path, fallback, grace period, preserved data, and who should ask for help. This turns a frustrating update into a navigable one.

The rule is straightforward: if an update removes a route people used, the fallback is part of the release, not a support afterthought.

When a feature disappears, the fallback is part of the change

// COMMENTS

ON THIS PAGE