migration-plan

name	migration-plan
description	This skill should be used after partner-list-intake has produced a classified partner list and the Implementation team needs an actionable execution plan. Triggers on: "build the migration plan for [customer]", "execution plan for [customer]", "what should we do first for [customer]'s partners", "stack rank [customer]'s onboarding", "sequence the partner migration", "how do we run [customer]'s migration". Produces an Excel workbook with the execution plan stack-ranked by actionability, an outreach queue grouped by vendor, and a raw data sheet with per-partnership status and gap codes.
version	0.1.0

Migration Plan

Turn a classified partner list into a sequenced execution plan the team can work top-to-bottom.

When this fires

Partner list intake is done. The classified list is in the workspace as <customer-slug>-partner-list.xlsx. Anomalies are resolved (or knowingly accepted). The user wants to know: what do we do tomorrow morning?

If the partner list isn't in the workspace, tell the user: "I don't see a classified partner list. Run partner-list-intake first."

Inputs to gather

• Classified partner list — read <customer-slug>-partner-list.xlsx from the workspace. Sheet 1 is your input.
• Onboarding profile — read <customer-slug>-onboarding-profile.md for go-live target date, in-scope transactions, and AE commitments.
• Orderful org context — call get_account_context for the customer's org. Capture: existing partnerships (in-flight from prior work?), comm channels configured, guideline sets available.
• Intercom outreach tickets — search Intercom for any open RnD Outreach tickets matching the customer's partner names. These represent partners already in flight.
• For each in-network partner — call list_relationships to see if a trading relationship already exists between this customer's org and the partner's org. A relationship in LIVE, READY, or SETUP state changes the plan substantially.

Step 1 — Build the per-partnership plan

For every partner row, compute:

• Acceptance approach — one of:

  • accept_existing_tr (a trade request from this partner is already in Orderful)
  • create_outbound_tr (we initiate the trade request to this partner)
  • out_of_network_onboard (partner not in Orderful, need to onboard them too)
  • migration_only (relationship already exists, just reroute)
  • skip (partner not actually needed — out of scope, duplicate, etc.)

• Vendor strategy — based on partner_list classification:

  • retailer_direct: drive the retailer's onboarding form
  • sps_managed: trigger sps-certification-setup
  • van_partner: send VAN re-route request
  • as2_capable: exchange AS2 config
  • unknown: send discovery email first

• Gap codes — tag any missing pieces: MISSING_ISA, NO_GUIDELINE_SET, NO_COMM_CHANNEL, NO_SCENARIO, NEEDS_OUTREACH, WAITING_ON_PARTNER.

• Estimated effort — XS (already live), S (in-network, scenario exists), M (in-network, needs config), L (out-of-network or VAN migration), XL (custom requirements).

Step 2 — Sequence the work

Stack-rank using this priority logic:

1. Tier 1 partners with XS or S effort — get easy wins live first.
2. Tier 1 partners with M effort.
3. Vendor-consolidated groups (multiple partners on the same VAN can be batched into a single outreach).
4. Tier 2 partners by effort ascending.
5. Tier 3 partners last.

For vendor-consolidated groups, write the group as a single line in the execution plan with a partner count, NOT as N separate lines. This is the key insight that makes the outreach queue manageable.

Step 3 — Output

Use the xlsx skill to produce <customer-slug>-migration-plan.xlsx. Three sheets:

Sheet 1 — Execution Plan (stack-ranked) Columns: rank, partner_or_group, partner_count, tier, acceptance_approach, vendor_strategy, effort, gap_codes, next_action, owner, target_date.

The next_action column is the most important — it should be a verb-first instruction the AM can act on: "Send retailer-direct outreach to Walmart", "Accept existing TR from XYZ", "Trigger SPS cert setup for ABC".

Conditional formatting: rank 1-5 highlighted, vendor groups with light blue fill.

Sheet 2 — Outreach Queue Just the partners requiring outreach, grouped by vendor_strategy. Columns: vendor_group, partner_names, partner_count, outreach_template, target_send_date, intercom_ticket_id (if exists), status.

This sheet should make the email count visible — if 12 partners are consolidated into 3 vendor groups, the AM does 3 emails, not 12.

Sheet 3 — Raw Data Every partnership with full classification, gap codes, current relationship state (if in-network), Intercom ticket link, and notes. This is the audit trail.

Rules

• Don't skip vendor consolidation. If 4 partners are all on the same VAN, that's ONE outreach. The whole point of this plan is to minimize emails.
• Re-check Orderful state before scheduling outreach. A partnership in LIVE state doesn't need a kickoff email. A SETUP partnership might just need a config nudge, not a new outreach.
• Link to Intercom tickets when they exist. Don't recommend starting new outreach for a partner who already has an open ticket — recommend the AM check the existing ticket.
• Be honest about the go-live target. If the plan has 50 Tier 1 partners and the AE promised go-live in 6 weeks, surface that at the top of the workbook. Don't quietly produce a plan that misses the date.
• No invented gap codes. If you don't know whether the comm channel is set up, write UNKNOWN rather than guessing NO_COMM_CHANNEL.

After saving, output a 5-line summary in chat: total partnerships, vendor-consolidated outreach count vs. raw partner count (the savings), top 3 ranked next actions, and a link to the workbook. Then suggest: "Next step — work the Execution Plan top-down. Once most partnerships are LIVE or READY, run go-live-readiness."