deprecation-and-migration

Safely sunset a legacy API by first defining a functional replacement, issuing advisory or compulsory deprecation notices, creating migration tooling, and verifying zero active usage before final removal. Incremental migration patterns like the Strangler pattern reduce risk during the transition.

Advisory deprecation warns users that a system is outdated and provides migration guidance, while compulsory deprecation enforces a hard deadline for removal. Choosing between them depends on consumer dependency scale, migration cost, and the maintenance cost of inaction.

Use the Strangler pattern for migration planning when incrementally replacing a legacy system to reduce risk. It allows you to route functionality to a new implementation over time, preserving user behavior until the old system can be safely removed.

Identify zombie code by locating unowned-but-required functionality within legacy systems. Handle it by driving the code toward either formal ownership and investment or complete removal using a structured deprecation and migration plan.

Before starting feature deprecation, define a functional replacement, evaluate ongoing value and consumer dependency scale, and determine whether an advisory or compulsory mechanism is appropriate based on migration cost and maintenance burden.

Consolidate duplicate implementations by selecting a primary replacement, migrating consumers incrementally using adapter patterns, and verifying zero active usage of the duplicates before final removal to preserve user behavior.