# Principle Migrate Callers Then Delete Legacy Apis

> Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.

- Skill: `v1truv1us-ai-eng-system/principle-migrate-callers-then-delete-legacy-apis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add v1truv1us-ai-eng-system/principle-migrate-callers-then-delete-legacy-apis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/v1truv1us-ai-eng-system/principle-migrate-callers-then-delete-legacy-apis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: v1truv1us (https://skillmd.com/u/v1truv1us-ai-eng-system)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/v1truv1us-ai-eng-system/principle-migrate-callers-then-delete-legacy-apis

---


# Migrate Callers Then Delete Legacy APIs

When we decide a new API is the right design, migrate callers and remove the old API in the same refactor wave instead of preserving compatibility layers.

**Rule:**
- Do not keep legacy API paths alive only because internal callers still exist
- Inventory callers, migrate them, and delete the old API immediately
- Treat temporary adapters as exceptional and time-boxed, not default architecture
- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details

**When this applies:**
- No external users depend on backward compatibility
- The project can absorb coordinated breaking changes
- The new API is part of a simplification or refactor initiative

Keeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.