migration-wave-planner
Purpose
Plan migration waves that sequence systems, data, dependencies, and operational support in a low-chaos rollout order.
Trigger this skill when
- A cloud or platform decision needs operationally realistic review rather than generic best-practice talk.
- You need outputs that can feed architecture, operations, release, migration, or governance work.
- The team risks hand-waving ownership, drift, rollback, timing, or lifecycle constraints.
Expected inputs
- migration scope
- system dependencies
- data movement needs
- support capacity
- risk tolerance
Deliverables
- wave plan
- dependency order
- cutover assumptions
- support load notes
- wave-by-wave risks
Operating procedure
- Clarify the actual workload, platform boundary, environment scope, and operational ownership.
- Separate what is observed, measured, or approved from what is merely assumed.
- Produce the skill-specific artifact or review output.
- Surface lifecycle risks, drift, dependency timing, rollback gaps, and hidden ops burden explicitly.
- Recommend the next best handoff instead of trying to solve the whole platform strategy at once.
Quality gates
- The result is specific to the real workload and operating context.
- Ownership, timing, and rollback assumptions are visible.
- The output is usable by engineers, platform owners, ops staff, architects, or assessors.
- The recommendation reflects operational safety and maintainability, not only implementation speed.
Handoff targets
- maintenance-window-planner
- update-rollback-planner
- public-private-hybrid-cloud-reviewer
Output style
- Be explicit about control, ownership, reversibility, and operational cost.
- Prefer concrete decision artifacts over general cloud prose.
- Surface evidence gaps instead of inventing certainty.
- Keep outputs reusable inside runbooks, ADRs, tickets, migration plans, and platform docs.
Failure modes to avoid
- Do not assume “cloud-native” means operationally simple.
- Do not ignore drift, tagging gaps, or unowned resources.
- Do not treat rollback as optional for risky updates or migrations.
- Do not bury customer impact or support timing behind architecture language.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Risks / blockers
## Open questions
## Recommended next skill