Migration 🛤️

Problem statement

We have a service in production and we want to migrate traffic to a new service.


Define an interface

Ryan King expressed this succinctly: always start a migration by defining an abstraction layer. Splitting traffic behind an abstraction is easier than moving clients from one interface to another.

Tools like gRPC, Thrift and Open API simplify this process for services by enabling us to declare a service interface.

Avoid features

Migrating is like refactoring. We want to change implementation without changing behavior.

Avoid adding features during migration, to maintain focus on the migration and minimize the risk of destabilizing the old system, which is being migrated away from for a reason.

Pushing back on feature development can be hard if the migration takes a long time because migration, ideally, is invisible to customers, meaning its value is hidden.

Maintain parity

If we must add features during the migration, maintain feature parity between the new and old system to ensure the product is always shippable. In Agile terminology, we always want "working software".

Only building features in the new system can be attractive because the new system doesn't have legacy cruft, but this means customers are now blocked on shipping the new system, which puts pressure on the migration.


Thoughts? Suggestions? Hit me up @erikeldridge


Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 International License, and code samples are licensed under the MIT license.