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.

Workflow notes: For an active track, read docs/tracks/<track-id>/notes.md at phase entry or resume and update it when useful context changes or before handoff. Capture observations, tentative ideas, outcomes, blockers, and next actions with evidence links. Follow the memory-management running-note and document-metadata protocols; honor explicit read-only or file-scope limits and keep writes outside pinned verification or release targets.

When to Use

• Replacing an old system, API, or library with a new one
• Sunsetting a feature that's no longer needed
• Consolidating duplicate implementations
• 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 system 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.

Deprecation Planning Starts at Design Time

When building something new, ask: "How would we remove this in 3 years?" Systems designed with clean interfaces, feature flags, and minimal surface area are easier to deprecate than systems that leak implementation details everywhere.

The Deprecation Decision

Before deprecating anything, answer these questions:

1. Does this system still provide unique value?
   → If yes, maintain it. If no, proceed.

2. How many users/consumers depend on it?
   → Quantify the migration scope.

3. Does a replacement exist?
   → If no, build the replacement first. Don't deprecate without an alternative.

4. What's the migration cost for each consumer?
   → If trivially automated, do it. If manual and high-effort, weigh against maintenance cost.

5. What's the ongoing maintenance cost of NOT deprecating?
   → Security risk, engineer time, opportunity cost of complexity.

Compulsory vs Advisory Deprecation

Default to advisory. Use compulsory only when the maintenance cost or risk justifies forcing migration. Compulsory deprecation requires providing migration tooling, documentation, and support — you can't just announce a deadline.

The Migration Process

Step 1: Build the Replacement

Don't deprecate without a working alternative. The replacement must:

• Cover all critical use cases of the old system
• Have documentation and migration guides
• Be proven in production (not just "theoretically better")

Step 2: Announce and Document

## Deprecation Notice: OldService

**Status:** Deprecated as of 2025-03-01
**Replacement:** NewService (see migration guide below)
**Removal date:** Advisory — no hard deadline yet
**Reason:** OldService requires manual scaling and lacks observability.
            NewService handles both automatically.

### Migration Guide
1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`
2. Update configuration (see examples below)
3. Run the migration verification script: `npx migrate-check`

Step 3: Migrate Incrementally

Migrate consumers one at a time, not all at once. For each consumer:

1. Identify all touchpoints with the deprecated system
2. Update to use the replacement
3. Verify behavior matches (tests, integration checks)
4. Remove references to the old system
5. Confirm no regressions

The Churn Rule: If you own the infrastructure being deprecated, you are responsible for migrating your users — or providing backward-compatible updates that require no migration. Don't announce deprecation and leave users to figure it out.

Step 4: Remove the Old System

Only after all consumers have migrated:

1. Verify zero active usage (metrics, logs, dependency analysis)
2. Remove the code
3. Remove associated tests, documentation, and configuration
4. Remove the deprecation notices
5. Celebrate — removing code is an achievement

Migration Patterns

Strangler Pattern

Run old and new systems in parallel. Route traffic incrementally from old to new. When the old system handles 0% of traffic, remove it.

Phase 1: New system handles 0%, old handles 100%
Phase 2: New system handles 10% (canary)
Phase 3: New system handles 50%
Phase 4: New system handles 100%, old system idle
Phase 5: Remove old system

Adapter Pattern

Create an adapter that translates calls from the old interface to the new implementation. Consumers keep using the old interface while you migrate the backend.

// Adapter: old interface, new implementation
class LegacyTaskService implements OldTaskAPI {
  constructor(private newService: NewTaskService) {}

  // Old method signature, delegates to new implementation
  getTask(id: number): OldTask {
    const task = this.newService.findById(String(id));
    return this.toOldFormat(task);
  }
}

Feature Flag Migration

Use feature flags to switch consumers from old to new system one at a time:

function getTaskService(userId: string): TaskService {
  if (featureFlags.isEnabled('new-task-service', { userId })) {
    return new NewTaskService();
  }
  return new LegacyTaskService();
}

Database Schema Migrations (Expand/Contract)

A schema change is the riskiest migration because the data is the one thing you cannot roll back by reverting a deploy. The failure mode is coupling the schema change to the code change: rename a column in the same release that starts using the new name, and during the rollout window — when old and new code run at once — one of them is querying a column that doesn't exist. The fix is to never change a column in place. Migrate in additive phases so old and new code are both valid at every step.

EXPAND ──────────────→ MIGRATE ──────────────→ CONTRACT
add the new column,    backfill existing rows,  once no code reads the
nullable, alongside    dual-write old+new from  old column, drop it in
the old one            the app                  a later, separate deploy

Worked example — renaming name to full_name:

1. Expand. Add full_name as nullable. Deploy. (Old code ignores it; nothing breaks.)
2. Dual-write. App writes both name and full_name on every insert/update. Deploy.
3. Backfill. Copy name → full_name for existing rows, in batches, so you don't lock the table.
4. Switch reads. Point the app at full_name, keep writing both. Deploy and bake.
5. Contract. Stop writing name, then — in a separate, later deploy — drop the column.

Each step is independently deployable and reversible: if step 4 misbehaves, roll the code back and full_name is still being populated. Apply the delivery fork: give separately mergeable stages their own implementation tracks and PRs under a coordination initiative, even for one column rename. Record rollout dependencies and removal evidence in the parent index and each stage's acceptance criteria. Expand and destructive contract must use separate tracks and PRs; /build auto cannot cross that boundary on the same branch. Deployment and backfill checkpoints alone do not require extra implementation tracks.

Rules:

• Additive first, destructive last and alone. Adds (new nullable column, new table, new index) are safe in any deploy; drops and renames get their own deploy after no code references the old shape.
• Every migration has a tested down path. A migration you can't reverse is a deploy you can't roll back. Write and run the down before merging.
• Backfill in batches, off the hot path. A single UPDATE over millions of rows locks the table; chunk it and throttle.
• Build large indexes without blocking writes (e.g. Postgres CREATE INDEX CONCURRENTLY).
• Decouple from code by feature flag when the cutover is risky, exactly as in the Feature Flag Migration pattern above.

Zombie Code

Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:

• No commits in 6+ months but active consumers exist
• No assigned maintainer or team
• Failing tests that nobody fixes
• Dependencies with known vulnerabilities that nobody updates
• Documentation that references systems that no longer exist

Response: Either assign an owner and maintain it properly, or deprecate it with a concrete migration plan. Zombie code cannot stay in limbo — it either gets investment or removal.

Common Rationalizations

Red Flags

• Deprecated systems with no replacement available
• Deprecation announcements with no migration tooling or documentation
• "Soft" deprecation that's been advisory for years with no progress
• Zombie code with no owner and active consumers
• New features added to a deprecated system (invest in the replacement instead)
• Deprecation without measuring current usage
• Removing code without verifying zero active consumers
• A schema change and the code that depends on it shipped in the same deploy
• Expand and contract (or dual-write and drop) landed in the same PR because /build auto ran the whole migration
• A column renamed or dropped in place rather than via expand/contract
• A migration merged with no tested down path, or a backfill that locks the table

Verification

After completing a deprecation:

• Replacement is production-proven and covers all critical use cases
• Migration guide exists with concrete steps and examples
• All active consumers have been migrated (verified by metrics/logs)
• Old code, tests, documentation, and configuration are fully removed
• No references to the deprecated system remain in the codebase
• Deprecation notices are removed (they served their purpose)

After a database schema migration:

• The change ships in additive phases (expand → backfill → contract), not a single in-place edit
• Old and new code are both valid against the schema at every deploy step
• Each migration has a tested down path; backfills run in throttled batches
• Destructive steps (drop/rename) ship in their own deploy after no code references the old shape