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.
Installs into .claude/skills of the current project.
Are you the author of Principle Migrate Callers Then Delete Legacy Apis?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/v1truv1us-principle-migrate-callers-then-delete-legacy-apis)
---
name: principle-migrate-callers-then-delete-legacy-apis
description: 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.
metadata:
version: 1.0.0
tags: cursor-import, pstack
---
# 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.
