| name | migrating-apis |
| description | Implement API migrations between versions, platforms, or frameworks with minimal downtime.
Use when upgrading APIs between versions.
Trigger with phrases like "migrate the API", "upgrade API version", or "migrate to new API".
|
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash(api:migrate-*) |
| version | 1.25.0 |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| license | MIT |
| tags | ["api","migration","migrating-apis"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
Migrating APIs
Overview
Implement API migrations between versions, frameworks, or platforms with minimal downtime using strangler fig pattern, parallel running, and traffic shadowing. Generate migration plans that map old endpoints to new equivalents, transform request/response formats, and validate data consistency between legacy and target implementations.
Prerequisites
- Source API codebase and OpenAPI specification accessible for analysis
- Target framework or platform environment provisioned and accessible
- Traffic routing capability for gradual cutover (reverse proxy, feature flags, or API gateway)
- Database migration tools if schema changes accompany the API migration (Flyway, Alembic, Prisma Migrate)
- Integration test suite covering all existing API consumers
Instructions
- Inventory all existing endpoints using Grep and Read, documenting HTTP methods, URL patterns, request/response schemas, authentication mechanisms, and consumer dependencies.
- Generate an endpoint mapping table that pairs each legacy endpoint with its target equivalent, flagging breaking changes in URL structure, field names, data types, and authentication flow.
- Create request/response adapters that transform legacy format to target format, handling field renames, nested-to-flat conversions, and enum value changes.
- Implement a traffic router (reverse proxy rules or middleware) that directs requests to either the legacy or target implementation based on migration phase, endpoint, or feature flag.
- Set up traffic shadowing to duplicate production requests to the target implementation without serving target responses, comparing outputs for data consistency validation.
- Build a migration dashboard tracking per-endpoint migration status (legacy-only, shadow, canary, migrated), error rates, and latency comparison between implementations.
- Execute phased cutover: shadow (compare only) -> canary (1% traffic to target) -> gradual ramp (10%, 25%, 50%, 100%) -> legacy decommission, with automatic rollback triggers.
- Validate migration completeness by running the full integration test suite against the target implementation and comparing response bodies with legacy for a representative request sample.
See ${CLAUDE_SKILL_DIR}/references/implementation.md for the full implementation guide.
Output
${CLAUDE_SKILL_DIR}/migration/endpoint-mapping.json - Legacy-to-target endpoint mapping with change annotations${CLAUDE_SKILL_DIR}/migration/adapters/ - Request/response transformation functions per endpoint${CLAUDE_SKILL_DIR}/migration/router.js - Traffic routing middleware with phase-based switching
