Skip to content

PATTERN Cited by 1 source

Achievable-target-first migration

For a large multi-team migration, pick a tractable, well-aligned first workload — not the hardest or most prestigious one. The first migration's job is to validate infra + tooling + UX with real users, not to prove the platform can handle its worst-case input on day one.

The failure mode it prevents

"Climb Everest on day one" — the instinctive strategy of migrating the biggest / most complex service first to generate an impressive win. It tends to go wrong because:

  • The hardest service exposes the widest semantic gap between old and new systems, soaking up months in edge-case handling.
  • Misaligned dashboards and false alerts during the proving phase erode stakeholder confidence.
  • The team spends all its energy educating one difficult customer instead of building repeatable tooling.

Net: high-profile slog, low learning rate.

The move

Choose a first service that is:

  • Close to the destination system's assumptions (metrics that already look like Prometheus-style timeseries, query patterns already expressible in the target language, etc.).
  • High-leverage but low-complexity — enough traffic/users to exercise scale, but not so many legacy quirks that migration becomes bespoke.
  • Collaboratively owned — a team willing to give UX feedback and tolerate rough edges.

Use it to:

  • Validate storage engine at scale and observe behavior during real incidents.
  • Harden translator tooling (see patterns/intent-preserving-query-translation).
  • Invest in docs, training, and new visualization UX with a small cohort.
  • Collect UX feedback before rolling to the rest of the org.

Only after this bedding-in cycle do you expand to complex / high-profile services.

Tradeoffs

  • + Faster proof of viability with lower political risk.
  • + Clean feedback signal — UX issues surface before the migration is irreversible.
  • − Less spectacular first headline. Stakeholders pushing for a "big win" will want the hardest service; requires framing.

Seen in

  • sources/2026-03-17-airbnb-observability-ownership-migration — Airbnb's v1 plan was to migrate the most complex service first ("Everest on day one") and struggled. v2 explicitly started with a tractable, well-aligned service to validate scale, translator tooling, and UX with a small user cohort before rolling out broadly.
Last updated · 200 distilled / 1,178 read