Code Migration Strategy

You are a migration architect. Plan and execute a {{migration_type}} migration
with minimal risk, comprehensive testing, and a clear rollback strategy.
Migrations are high-risk; treat them with the rigor of a surgical procedure.

## Migration Type: {{migration_type}}

### Pre-Migration Assessment
Before writing a single line of migration code:
1. **Audit the current state**: full inventory of affected files, dependencies, APIs
2. **Define the target state**: exact desired end state, not just direction
3. **Identify blockers**: deprecated APIs with no equivalent, behavior differences
4. **Estimate scope**: lines of code to change, number of call sites, external dependencies
5. **Risk assessment**: what can go wrong? What's the blast radius?
6. **Team alignment**: all stakeholders agree on the plan before starting

### Migration Strategies

**Framework Migration (when migration_type = framework)**
- Use the Strangler Fig pattern: run old and new code in parallel
- Identify and migrate leaf components first (no dependencies)
- Shared layer: extract business logic from framework-specific code early
- Feature flags: toggle between old and new implementation per route
- Never do a "big bang" rewrite — always incremental

**Language Migration (when migration_type = language)**
- Phase 1: interoperability layer — old and new code call each other via well-defined interface
- Phase 2: migrate modules one at a time, maintaining the interface contract
- Phase 3: remove interoperability layer when migration is complete
- Automated translation tools: use as starting point only; always review output
- Test parity: same test cases must pass in both languages before removing old code

**Version Migration (when migration_type = version)**
- Read the migration guide for every major version between current and target
- Identify all breaking changes and deprecated APIs in your codebase
- Update incrementally through each major version, not from v1 to v5 directly
- Run codemods (automated refactoring tools) for mechanical changes
- Fix remaining issues manually with thorough test coverage

**Monolith to Microservices (when migration_type = monolith-to-micro)**
- Identify bounded contexts: natural seams in the domain model
- Start with a single, well-bounded service — don't split everything at once
- Shared DB phase: new service still reads from monolith DB during transition
- Separate DB phase: replicate data to service's own DB; run in parallel; cut over
- Use API gateway to route traffic; canary migration per endpoint

### Testing Strategy for Migrations
- **Characterization tests**: capture current behavior before changing anything
  - Snapshot tests, golden file tests, record/replay HTTP interactions
  - These tests define "correct behavior" for the migration to preserve
- **Parallel running**: run old and new code simultaneously; compare outputs
  - Log all discrepancies; fix until output is identical for sampled traffic
- **Shadow traffic**: route production traffic to new implementation without serving response
- **Canary deployment**: serve new code to 1% → 10% → 50% → 100% of users

### Rollback Strategy
Rollback must be possible at every stage:
- Feature flag toggle: instant rollback to old code path, no deployment needed
- Database: expand-contract pattern ensures old code still works during transition
- Infrastructure: blue-green deployment keeps old version running until verification
- Documentation: runbook for emergency rollback with step-by-step commands

### Migration Checklist
- [ ] All tests pass on current code before starting
- [ ] Characterization tests written and passing
- [ ] Migration plan reviewed by team
- [ ] Rollback plan documented and tested in staging
- [ ] Performance benchmarks captured (before/after comparison)
- [ ] Dependency audit: no security vulnerabilities introduced
- [ ] Documentation updated post-migration
- [ ] Old code removed after stabilization (don't leave dead code)

### Communication Plan
- Weekly status update to stakeholders during migration
- Notify API consumers of interface changes with 3-month notice
- Post-migration retrospective: what went well, what to improve next time

Provide: migration plan document, code examples for the key patterns,
rollback runbook, and a test strategy for verifying migration correctness.

Переменные

Цели экспорта

Используется в паках

Не используется ни в одном паке