Platform Migration Pipeline Template
Run platform migrations in a live command center
If you are leading a platform migration, work quickly sprawls across spreadsheets, tickets, and slide decks. This template turns that chaos into a single, navigable Instaboard pipeline. Start by duplicating the System / Service micro-template in Intake & Discovery so every app has a clear record of platform, strategy, risk, and dependencies. Use the risk and wave micro-templates to group work into waves with realistic windows, and apply labels so you can filter for High risk, Customer-facing, or Internal-only systems. As cards move from discovery through cutover and decommission, everyone sees the same live board instead of status spreadsheets, and critical runbooks stay attached to the work they describe.
- See every system and migration status in one shared, real-time board
- Plan waves and cutover windows with structured risk and wave micro-templates you duplicate instead of rewriting
- Keep owners, due dates, and runbooks on the same card that moves through the pipeline
- Attach architecture diagrams, dashboards, and runbooks directly to migration cards so context travels with the work
- Reduce migration risk by using structured cards and labels so dependencies and rollback paths stay visible for every system
Start in Intake & Discovery — log systems
Open the Platform Migration Flow section and start in the Intake & Discovery column. Duplicate the System / Service micro-template card for every app, service, or job you plan to move, then drag each new card into this list. Fill in current platform, target platform, migration strategy, risk level, and key dependencies so anyone can understand the work at a glance. Assign an owner on each card and set a realistic due date based on when you expect that system to move. Attach architecture diagrams or inventory spreadsheets as files or links so technical details live on the same card you use to track progress.
Pro tip: Keep Intake & Discovery visible during planning sessions so engineers and platform leads can add migration candidates as they spot them.
Assess risk and define migration waves
Once a system has basic details, move its card into Assessment & Scope. Duplicate the Risk Assessment micro-template when a migration needs deeper thought, and fill in impact, likelihood, mitigations, and status directly on the card. Use the Wave micro-template to define Wave 1, Wave 2, and beyond with clear entry and exit criteria, change windows, and communication plans. Apply labels like High risk, Medium risk, Low risk, Customer-facing, Internal-only, or Requires downtime window so you can filter the pipeline when prioritizing. During planning meetings, use Instaboard’s filters on this column so everyone in the room sees the same sliced view of systems by risk or wave instead of juggling separate spreadsheets.
Pro tip: If you are unsure about a system, leave it in Assessment & Scope with a Medium risk tag until the team can review it together.
Design runbooks and rollback paths for critical systems
For migrations that are customer-facing or revenue-critical, drag their cards into Plan & Runbook (optional). Duplicate the Runbook Outline micro-template and fill in pre-checks, migration steps, validation checks, and rollback plan in one place. Attach runbook documents, change requests, and dashboard links directly to the card so on-call engineers do not have to hunt through other tools. Because the runbook, current stage, owner, and labels all live on the same card, anyone scanning the board can see exactly how to execute and when to roll back. Use the description field to call out approvals, sign-offs, and any coordination needed with finance, support, or legal before moving the card into Pilot / Proof of Concept or Wave Migrations In Progress.
Pilot, then run wave migrations with clear owners
Use the Pilot / Proof of Concept column to try migrations on low-risk or internal systems first. Convert key actions into task cards with checkboxes so you can track progress through pilot steps, and attach monitoring dashboards to confirm the new platform behaves as expected. As you promote systems into Wave Migrations In Progress, keep each card assigned to a clear owner and maintain due dates that line up with your change calendar. Indent smaller tasks under the main system card to keep the column tidy while still showing the work involved, and collapse or expand those indented cards during standups depending on how much detail you need. Move cards forward as pilots succeed and waves complete so the board always reflects reality.
Pro tip: Treat each wave as a mini-project — a handful of system cards plus the wave definition card give you a focused view of what is shipping this week.
Cut over, monitor, and decommission safely
When a migration is ready to go live, drag its card into Cutover & Go-Live. Record the cutover window and key checks in the description, and attach the final runbook and monitoring dashboards so on-call engineers have everything in one place. Use labels like High risk and Requires downtime window to make high-stakes events stand out on the board for leadership and on-call. After a successful cutover, move the card into Stabilization & Decommission and create or duplicate cards for post-migration monitoring summaries and decommission tasks. Assign owners and due dates to cleanup work so legacy clusters, load balancers, and configuration are actually retired instead of lingering unnoticed, and keep this column as a living decommission log you can reference with auditors later.
Pro tip: Link directly to a filtered Stabilization & Decommission column from your runbook so stakeholders always land on the live record of what moved, when, and how it was verified.
What’s inside
Seven-stage migration flow
Intake & Discovery, Assessment & Scope, Plan & Runbook (optional), Pilot / Proof of Concept, Wave Migrations In Progress, Cutover & Go-Live, and Stabilization & Decommission — drag cards left-to-right so leaders can scan the shared board and instantly see which systems are ready, in motion, or blocked.
System and risk micro-templates
Micro-templates for System / Service, Runbook Outline, Risk Assessment, and Wave definition give every card consistent fields for platform details, migration strategy, mitigations, and change windows without rewriting structure each time, and the structure stays visible on the card instead of hiding in a separate doc.
Labels tuned for migration risk
High risk, Medium risk, Low risk, Customer-facing, Internal-only, Requires downtime window, and Blocked labels make it easy to slice the pipeline by risk level, user impact, or operational constraints during planning and standups.
Example migration cards
Filled demo cards show realistic migrations like Billing API and internal analytics jobs with owners, due dates, labels, and attached inventories or reports so your team can duplicate a good example instead of starting from a blank board.
Stabilization and decommission lane
The Stabilization & Decommission column holds post-migration monitoring summaries and decommission tasks so you actually retire legacy infrastructure instead of leaving half-migrated systems hanging around.
Why this works
- Turns scattered migration documents and tickets into a single end-to-end pipeline view
- Keeps system details, risk assessments, and runbooks attached to the same cards that track progress
- Helps teams plan realistic migration waves by combining labels, due dates, and wave definition cards
- Reduces cutover risk by making pre-checks, validation steps, and rollback paths explicit on the board
- Ensures stabilization and decommission work is tracked instead of forgotten after the first successful cutover
FAQ
Is this only for cloud migrations?
No. You can use this pipeline for data center moves, SaaS-to-SaaS migrations, internal platform shifts, or any multi-system change where you move services from one environment to another.
Can we track multiple platform projects on one board?
Yes. Keep one board per major migration program and use waves, labels, and card titles to group systems by platform, region, or business unit while still seeing the full pipeline in one place.
How does this differ from a normal project board?
Instead of generic tasks, this template uses micro-templates tailored for systems, risk, waves, and runbooks so each card carries the details platform teams actually need, and those fields, labels, and attachments stay visible on the card as you drag it across stages instead of hiding in separate tickets or docs.
What size teams is this template for?
It is designed for small platform or engineering teams who need a single place to see migrations across services, but it scales up by adding more waves, owners, and labels as programs grow.