Infrastructure Nomads: Making Migrations Boring

Why doesn’t a successful deployment necessarily mean that an infrastructure migration is complete? Drawing on five migrations, I’ll share how our team moved from manual operations and knowledge held by individual engineers to a repeatable process with clear checks and ownership.

We’ll examine an external cron job that quietly masked an application defect and a repeated Strapi content migration that forced us to recover from an old bucket we had kept in reserve. Using an illustrative example, we’ll see how a subtle Kubernetes selector mistake can send requests to the wrong component even when the applications appear healthy. I’ll show how Infrastructure as Code (IaC), Helm, and GitOps helped make deployments reproducible. I’ll also explain how we kept service and environment profiles up to date by linking documentation to deployments: a pipeline collected information from deployment repositories and opened merge requests in a documentation repository. We’ll discuss preparing a standby database with replication before cutover, monitoring technical and business metrics, rehearsing migrations, and planning rollback. We’ll also explore the human side of migration: sharing knowledge, raising risks early, and working with developers rather than carrying old workarounds into every new environment.

This is not a universal migration recipe, but a practical account of mistakes, constraints, and lessons you can adapt to your own infrastructure. The goal is to help you identify weak points early and make your next migration more predictable—and less dependent on heroics.