---
name: cursor-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."
disable-model-invocation: true
metadata:
  decimalai-skill-id: "956ce4f7-11dd-405d-8ab0-177614bb4440"
  decimalai-version-id: "eea356b2-db32-4df9-aec2-1a66329d9be3"
  decimalai-version: "1"
  decimalai-body-sha256: "652cd8d0ce8551959d4ab59f36721775d57dd8dc46f6b08536ce077f43f4ccd5"
  decimalai-name: "cursor/principle-migrate-callers-then-delete-legacy-apis"
  decimalai-format: "1"
  decimalai-invocation: "user"
  decimalai-category: "coding"
  decimalai-source: "https://app.decimal.ai/s/cursor-principle-migrate-callers-then-delete-legacy-apis@1/SKILL.md"
---
# 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 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.