How a migration engagement actually runs
Week one is discovery, and it is mostly reading: inventorying what runs, what talks to what, which dependencies are load-bearing and which are folklore. The output is a wave plan — workloads grouped by risk and coupling, each wave with its own cutover playbook and a rollback path that has actually been rehearsed. Stateless edges move first; the database moves last, with the most ceremony.
Then waves ship. Lift-and-shift where the workload is fine and the data center is the problem; replatform to managed services where the ops burden is the problem; refactor only where the architecture itself is the constraint — scoped honestly, because refactors are where migration budgets go to die. Every wave ends with the same question: does the runbook let your team do the next one without us?
Choosing the destination is its own decision, and we are deliberately indifferent to it: the honest comparison of the big three is written up in AWS vs Azure vs GCP. If Kubernetes is part of the answer, the platform work is a separate discipline — see Kubernetes consulting and the managed vs self-hosted decision. What the estate costs once it lands is the billing practice's job.