Design System Migration Plan

Generate a step-by-step migration plan for moving between design system versions, tools, or architectures.

When to Use

  • Upgrading to a new major version of your design system
  • Moving from one component library to another (e.g., Material to custom)
  • Migrating token formats (e.g., Tokens Studio to Style Dictionary)
  • Consolidating multiple design systems into one

The Prompt

Create a detailed migration plan for the following design system change:

**From:** [current system/version/tool]
**To:** [target system/version/tool]
**Scope:** [tokens only / components / full system]
**Team size:** [number of designers + engineers]
**Products affected:** [list products/apps]
**Timeline constraint:** [desired completion date or "flexible"]

Include:

1. **Impact assessment** — What breaks? What's deprecated? What's new? Rough % of codebase affected.
2. **Migration phases** — Break into phases with clear milestones. Each phase should be deployable independently.
3. **Token mapping table** — Old token name to new token name, with any value changes noted.
4. **Codemods / automation** — What can be automated? Provide regex or codemod pseudocode.
5. **Risk register** — Top 5 risks with likelihood, impact, and mitigation.
6. **Testing strategy** — Visual regression, accessibility, functional testing approach.
7. **Rollback plan** — How to revert each phase if something goes wrong.
8. **Communication plan** — Who to notify, when, and what they need to do.
9. **Definition of done** — How you know each phase is complete.

Format as a Markdown document I can share with stakeholders.

Example Output

# Migration Plan: Design Tokens v1 to v2

## Impact Assessment
- 47 tokens renamed, 12 tokens removed, 8 new tokens added
- Estimated 60% of component styles affected
- 3 products, ~200 component files

## Phase 1: Alias Layer (Week 1-2)
- Add v2 tokens as aliases pointing to v1 values
- No visual changes, no breaking changes
- Teams can start adopting new names immediately
- Done when: All v2 names resolve correctly

## Phase 2: Gradual Adoption (Week 3-6)
- Replace v1 token references with v2, product by product
- Codemod: find `--color-primary` replace `--color-brand-primary`
- Run visual regression after each product
- Done when: No v1 references remain in Product A

## Phase 3: Deprecation (Week 7-8)
- Mark all v1 aliases as deprecated (console warnings)
- Done when: All products migrated, zero v1 usage

## Phase 4: Removal (Week 9-10)
- Remove v1 tokens entirely
- Run full test suite
- Done when: Clean build with no deprecated token warnings

## Risk Register
| Risk                       | Likelihood | Impact | Mitigation                    |
|---------------------------|------------|--------|-------------------------------|
| Missed token in codemod   | High       | Medium | Visual regression catches it  |
| Third-party theme breaks  | Medium     | High   | Keep aliases for one release  |
| Team doesn't adopt in time| Medium     | Low    | Extend alias period           |