---
name: migration-planner
description: Produce a phased migration plan from vendor A to vendor B (firewall, switch, SD-WAN, cloud, directory) with feature-mapping, risk register, rollback checkpoints, and stakeholder comms.
version: 1.0.0
author: VantagePoint Networks
audience: Network Engineers, Architects, Project Managers, Engineering Leads
output_format: Markdown — phase plan, feature mapping, migration waves, rollback gates, comms calendar.
license: MIT
---

# Migration Planner

A Claude Code skill for infrastructure migrations — "Cisco ASA → Palo Alto", "on-prem AD → Entra ID", "Meraki → Fortinet SD-WAN", "vSphere → AWS", "Splunk → Sentinel". Produces a phased migration plan with feature mapping, waves, rollback gates, and comms.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/migration-planner`. Describe the source, the target, the scope, and the deadline.

## When to use this

- A vendor refresh is approved and you need a project plan before the PM starts asking.
- A merger / acquisition forces platform consolidation.
- An EOL date is driving migration timing.
- A cost-cutting exercise is moving you off a premium platform.
- You're responding to an RFP and need to show a defensible migration approach.

## What you'll get

A Markdown migration plan with:

1. **Executive summary** — source, target, driver, high-level timeline, risks.
2. **Feature map** — source feature → target equivalent → notes / gaps.
3. **Scope inventory** — what's in-scope, out-of-scope, dependency order.
4. **Wave plan** — low-risk pilot → broader cohorts → long-tail → decommission.
5. **Per-wave runbook skeleton** — pre-checks, cutover steps, validation, rollback.
6. **Rollback gates** — defined criteria at each wave for go/no-go.
7. **Risk register** — ranked, with owner + mitigation.
8. **Comms calendar** — stakeholder updates, change tickets, customer notifications.
9. **Decommission plan** — what happens to the old kit/service at the end.

## Clarifying questions I will ask you

1. **Source platform** — exact version / model.
2. **Target platform** — exact version / model.
3. **Scope** — how many sites / devices / users / services.
4. **Timeline** — start, desired go-live, immovable dates (audit, budget).
5. **Team capacity** — how many engineers + hours/week.
6. **Risk tolerance** — conservative (many waves) or bold (big bang).
7. **Compliance constraints** — change freezes, audit windows.
8. **Existing documentation** — config exports, topology, dependency map.
9. **Budget / licence state** — any parallel-run licence cost limits.

## How I build the plan

1. **Understand the as-is.** Map source features in use, not just features available.
2. **Feature-map against target.** For each source feature: identical / different-syntax / alternative-approach / gap.
3. **Gap analysis.** What target can't do, what source can't do, where we lose/gain.
4. **Dependency graph.** What must migrate before what.
5. **Wave sizing.** Low-risk pilot (1–5% of scope) → progressive cohorts.
6. **Decision gates.** Each wave has explicit success criteria + abort conditions.
7. **Parallel run.** Where feasible, operate both platforms to reduce risk.
8. **Decommission.** Clean exit from source platform at end.

## Example output (excerpt)

Input: *"Migrating from Cisco ASA 9.20 (cluster pair in HQ) to Palo Alto PA-5450 (HA pair). Same physical location. 3-month window. 800 firewall rules. 6 site-to-site VPN tunnels. Remote-access VPN via AnyConnect to 500 users. No ASA→PA experience in-house."*

```markdown
# Migration plan — Cisco ASA → Palo Alto PA-5450

## Executive summary
- **Source:** Cisco ASA 5585-X cluster, 9.20(3), HQ LON-DC1.
- **Target:** Palo Alto PA-5450 HA pair, PAN-OS 11.1.x, same rack.
- **Driver:** ASA EoL + consolidation onto single-vendor NGFW.
- **Scope:** 800 rules, 6 S2S VPNs, 500 AnyConnect users, HQ + 3 data paths.
- **Timeline:** 12 weeks — 2 design, 2 lab, 4 pilot, 4 full cutover + stabilisation.
- **Top risks:** team inexperience (P1), VPN client transition (P1), rule-base accuracy (P2).

## Feature map (abbreviated)

| ASA feature | PA equivalent | Notes |
|---|---|---|
| ACLs on inside/outside | Security policies on zones | Rule ordering semantics differ; default-deny implicit on PA |
| Object groups | Address/Service groups | 1:1 after normalisation |
| NAT (static / dynamic / policy) | NAT policies | PA NAT evaluated before security; design impact |
| IPsec VPN (IKEv2) | IPsec VPN | Crypto-map → IKE gateway + IPsec tunnel + proxy-id |
| AnyConnect SSL VPN | GlobalProtect | Client needs re-deploy via SCCM / Intune |
| Threat-Detect + Botnet Filter | Threat Prevention + WildFire + URL Filtering | Major uplift; licences required |
| Context-Aware inspection | App-ID | Shift from port-based to application-aware (major mental model change) |
| Syslog to SIEM | Syslog / LEEF | Format differs; SIEM parsers to update |
| ClusterXL / Active-Active | HA Active-Passive or A/A | PA A/A has distinct caveats; Active-Passive recommended |
| TACACS+ admin | TACACS+ | Same config pattern |
| Cisco RSA tokens for AnyConnect | SAML / TOTP in GlobalProtect | Replace RSA tokens |

## Scope inventory
- 800 rules → after `/firewall-rule-deduplicator` pass: estimate ~600 keep, 200 retire.
- 6 VPNs → pair-by-pair migration windows.
- 500 AnyConnect users → staggered GP client rollout.

## Wave plan

### Wave 0 — preparation (weeks 1–2)
- PA hardware delivered + racked.
- Lab build of PA + ASA side-by-side.
- Rule extraction from ASA, translation tooling test.
- Team training — 2 engineers through PA PCNSE fundamentals.

### Wave 1 — lab (weeks 3–4)
- Translate 100-rule subset.
- Validate each rule via `/config-diff` principle — same permit/deny decisions.
- Build VPN 1 of 6 in lab + test with partner.
- GlobalProtect client test with 5 internal users.

### Wave 2 — pilot (weeks 5–6)
- Move inbound internet (web/DMZ traffic) to PA for 1 DMZ subnet (10% of prod DMZ traffic).
- Rollback gate: if latency > +10% or error rate > +0.1%, revert.
- Start AnyConnect → GlobalProtect migration with IT + security team (50 users).

### Wave 3 — primary cutover (weeks 7–10)
- Cut inbound → PA fully, ASA passive standby.
- Cut one VPN per maintenance window.
- GP client rolled to 250 more users per week.

### Wave 4 — stabilisation + decom (weeks 11–12)
- Complete remaining GP rollout.
- Monitor for regression 2 weeks post full cutover.
- Decommission ASA cluster (preserve config export for 1 year).

## Rollback gates
Each wave has criteria to proceed / revert:

**Wave 2 gate:**
- All 100 translated rules produce identical decisions on a traffic-replay test.
- GP clients can establish + transmit for pilot users.
- WildFire / URL filter not blocking legitimate traffic above baseline rate.
**If any fail:** stay at wave 1 until fixed.

## Risk register

| # | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| 1 | GP client deployment breaks for % of users | Med | High (access loss) | Staggered rollout; parallel AnyConnect up for 4 weeks | Client team |
| 2 | Rule translation error blocks legitimate traffic | Med | High | Automated diff vs ASA; traffic replay; staged cutover | NetSec lead |
| 3 | PAN-OS bug in newly-deployed version | Low-Med | Med | Pin to the latest recommended version; monitor PSIRT | Platform lead |
| 4 | Team capacity shortfall | Med | Med | Contractor support reserved; training done wave 0 | Project manager |
| 5 | VPN partner coordination delays | Med | Med | Early engagement; maintenance window booked | Partner manager |

## Comms calendar

- Weekly project update — PM to stakeholder list every Friday.
- Customer comms — None expected unless outage; prepared template on hand.
- Change tickets — one per wave gate (CAB scheduled).
- IT user comms — GP client rollout emails at T-14, T-7, T-0, T+1.
- Exec update — monthly steering committee slide.

## Decommission plan
- Last traffic off ASA confirmed via netflow absence for 7 days.
- Configuration snapshot archived to long-term storage with 7-year retention.
- Licence portal de-registration.
- Physical hardware: wipe flash + certificate of destruction, or donate with same.
- Update asset inventory + CMDB.
```

## What I won't do

- I won't promise a feature-for-feature 1:1 migration — there are always trade-offs and I'll call them out.
- I won't recommend big-bang cutover unless the scope genuinely warrants it.
- I won't omit rollback plans to save space; every wave has one.
- I won't plan the project without your deadlines; if they're immovable, I'll compress waves and flag risk.

## Reference

- PMI / PRINCE2 project management principles
- Cisco + Palo Alto official migration guides
- ITIL change management framework
- Internal experience from real enterprise migrations

## Attribution

Built by **Hak** at **VantagePoint Networks**. MIT licensed.