Design System Migration: A Campaign, Not a Mandate

WHY IT EXISTS: A new design system, no matter how well-built, is a disruption. Legacy systems are deeply embedded in products and workflows, and teams are busy with their own priorities. Migration projects often fail because they are treated as a purely technical task, ignoring the human factors of resistance, unclear benefits, and conflicting schedules.

THE MENTAL MODEL: Think of design system migration not as a technical refactor, but as an internal sales and marketing campaign. Your 'customers' are other product teams. Your goal is to persuade them to 'buy' the new system by demonstrating its value, making adoption easy, and aligning with their existing priorities. Success is measured by voluntary adoption, not just technical completion.

HOW IT WORKS: Migration is rarely a single, big-bang event. It's a series of strategic choices, often mixed and matched. Five common strategies exist. First, the Trojan Horse, where you sneak in new components during regular feature work. Second, Strategic Team Selection, where you partner with enthusiastic teams first to create success stories. Third, Incremental Micro-Adoption, where teams adopt the system in layers, like using design tokens first, then basic components. Fourth, Value-First Communication, which focuses on demonstrating benefits instead of demanding compliance. Fifth, the Start Small strategy, which builds out foundational elements first and then scales.

WHEN TO USE IT: A deliberate migration strategy is critical when replacing a legacy system with high inertia. This is especially true in organizations with autonomous teams, tight budgets, or mixed levels of design system maturity. The Trojan Horse approach works well with no dedicated migration budget. Strategic Selection is ideal for building momentum and creating internal champions. Micro-Adoption is suited for complex applications where a full rewrite is too risky.

WHEN NOT TO USE IT: A formal strategy is overkill for a brand-new, small-scale project (a 'greenfield' app) where the design system can be adopted from day one. It's also less critical in a small, single-team organization where communication is simple and everyone is already aligned on the new system's value. In these cases, direct adoption is often sufficient.

ONE CANONICAL EXAMPLE: A common hybrid approach combines the Trojan Horse and Micro-Adoption strategies. A team wants to migrate but has no dedicated time. The design system team first releases only the design tokens (colors, spacing). During their next feature sprint, the product team refactors their CSS to use the new color tokens instead of old hex codes. This is a small, low-risk change piggybacked onto existing work. Later, they can replace a legacy button with the new system's button component in another feature ticket, gradually migrating the app without a dedicated 'migration sprint.'