skills.rest
Shtian
ShtianCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

principle-migrate-callers-then-delete-legacy-apis

Migrate internal callers to new APIs and delete legacy paths in one refactor wave.

4|1|Updated Dec 16, 2023
Search Tags:#refactoring#software design#technical debt#legacy code#code cleanup#api migration#breaking change
One-click install
npx skills add https://github.com/Shtian/AuthentiClash --skill principle-migrate-callers-then-delete-legacy-apis-shtian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-migrate-callers-then-delete-legacy-apis
Source: https://github.com/Shtian/AuthentiClash/tree/main/.claude/skills/principle-migrate-callers-then-delete-legacy-apis
Command: npx skills add https://github.com/Shtian/AuthentiClash --skill principle-migrate-callers-then-delete-legacy-apis-shtian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When introducing a new internal API, teams often keep the old API alive alongside compatibility layers, creating dual-path complexity and an append-only codebase. This Skill enforces a refactoring principle: migrate all callers and delete the legacy API in the same wave. ## Core Features & Use Cases - Caller Inventory and Migration: Guides you to inventory all internal callers, migrate them to the new API, and remove the old API immediately. - Time-Boxed Adapters: Treats temporary adapters as exceptional and time-boxed rather than default architecture. - Test Cleanup: Updates tests to assert the new contract and deletes tests that only protect pre-refactor implementation details. - Use Case: You are replacing an old scoring service interface in a SvelteKit app. Apply this principle to migrate every caller, delete the legacy interface, and update tests in a single coordinated change instead of leaving both paths in place. ## Quick Start Apply the migrate-callers-then-delete-legacy-apis principle to refactor the old game service API and remove all legacy code paths.

Frequently Asked Questions about principle-migrate-callers-then-delete-legacy-apis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate callers to a new API without breaking the codebase?▼

Inventory every internal caller of the old API, migrate them all to the new contract, and delete the legacy API in the same refactor wave. Coordinated breaking changes are safe when no external users depend on backward compatibility.

When should I keep a backward compatibility layer for an old API?▼

Keep compatibility layers only when external users depend on the old API. For purely internal APIs, treat temporary adapters as exceptional and time-boxed rather than default architecture, since dual paths create lasting complexity.

Should I delete tests after removing a legacy API?▼

Update tests to assert the new API contract, and delete tests that only protect pre-refactor implementation details. Tests tied to the old implementation add maintenance cost without verifying current behavior.

What are the risks of keeping both old and new APIs?▼

Keeping both APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only. Future developers must understand two paths, and the legacy path tends to persist indefinitely.

When does the migrate-then-delete principle not apply?▼

It does not apply when external consumers depend on the old API or when the project cannot absorb coordinated breaking changes. In those cases, a deprecation period with versioned APIs is the appropriate strategy.

Related Skills

Explore More Software Engineering Skills→
cursorcursor
6.6k

principle-migrate-callers-then-delete-legacy-apis

Migrate internal callers to a new API and delete the legacy API in one refactor wave.

Official
Basic
snoodleboot-iosnoodleboot-io

api-versioning-strategy

Guides API versioning decisions using compatibility classification, expand-migrate-contract, and sunset patterns.

Official
Intermediate
hack-inkhack-ink

code-housekeeping

Scan codebases for compatibility shims, dead code, and stale artifacts.

Official
Intermediate
herdiansahherdiansah
23

code-refactoring

Refactor legacy codebases and migrate outdated frameworks using the Strangler Fig pattern.

Community
Advanced