Migrations in #infrastructure and in engineering product teams as a whole are inevitable. If you have built something which is no longer serving its purpose, the people building it mostly would have built it to satisfy the earlier required use cases and not overengineering (1/n)
It's often helpful to work with 1 or 2 of the most challenging teams, work with them to build, evolve and migrate to the newer system, creating a sense of confidence, reliability around what you are building, in the process having covered most of the edge cases if not all. (2/n)
It's suggested not to start with an easy team while starting the migration, as this creates a false sense of security. The idea is to build automation, using the earlier experience, to migrate these easy services to the newer system, as this helps in future migrations. (3/n)
Good documentation and self-serving tooling is as important as the process you are setting up for the migration efforts. The idea is to keep improving the documentation as the migration process evolves organically. (4/n)
Migrations are always gonna be there, be it migrating from VM's to #containers, or from a monolith to a SOA architecture. The goal should always be to achieve 100% adoption, otherwise, you would be left maintaining both the systems, the legacy, and the new system. (5/5)
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.