deprecation-and-migration

Deprecation and Migration

Overview

Code is a liability, not an asset. Every line of code has ongoing maintenance cost — bugs to fix, dependencies to update, security patches to apply, and new engineers to onboard. Deprecation is the discipline of removing code that no longer earns its keep, and migration is the process of moving users safely from the old to the new.

Most engineering organizations are good at building things. Few are good at removing them. This skill addresses that gap.

When to Use

• Replacing an old system, API, or NuGet package with a new one
• Sunsetting a feature that's no longer needed
• Consolidating duplicate implementations (two services doing the same thing, two DbContexts, two controllers)
• Removing dead code that nobody owns but everybody depends on
• Planning the lifecycle of a new system (deprecation planning starts at design time)
• Deciding whether to maintain a legacy project in the solution or invest in migration

Core Principles

Code Is a Liability

Every line of code has ongoing cost: it needs tests, documentation, security patches, dependency updates, and mental overhead for anyone working nearby. The value of code is the functionality it provides, not the code itself. When the same functionality can be provided with less code, less complexity, or better abstractions — the old code should go.

Hyrum's Law Makes Removal Hard

With enough users, every observable behavior becomes depended on — including bugs, timing quirks, and undocumented side effects. This is why deprecation requires active migration, not just announcement. Users can't "just switch" when they depend on behaviors the replacement doesn't replicate. For public NuGet packages and HTTP APIs this applies doubly — semantic versioning signals intent, but downstream callers bind to observed behavior regardless.