Cloud migration gets sold as a tidy process. Move everything to the cloud, save money, go home early. In practice, every organisation has years of accumulated decisions, workarounds, and systems that only one person truly understands. That makes it messier, and more rewarding, than the sales pitch suggests.
Discovery: Figuring Out What Exists
This phase always takes longer than anyone expects. A full picture is needed: every server, every database, every integration, every service running in the corner that nobody remembers setting up.
Critical reporting services running on forgotten EC2 instances in personal AWS accounts are not unusual. Engineers leave, institutional knowledge goes with them, and business-critical systems quietly depend on infrastructure nobody tracks. Discovery surfaces all of it.
Dependencies get mapped, compliance requirements identified, and unnecessary systems flagged. Every organisation has at least a few things running purely because nobody has been brave enough to switch them off. Migration is a good opportunity to finally ask the question.
Planning: Deciding What Goes Where
Not everything moves the same way. Some systems get lifted and shifted as-is. Some move onto managed services. Some get redesigned. Some get retired.
The sequence matters: least critical things first, validating the approach before touching anything important. Cutover criteria, acceptable downtime, and success metrics all get agreed before work begins.
Architectural decisions happen here too. Regions, networking, disaster recovery, security groups, backup strategy. It is not glamorous work, but skipping it is how migrations go sideways.
Migration: Moving Things
Early moves are usually the easy ones. Stateless services, standard databases, systems with clean boundaries. These prove the process works.
Things will go wrong. Performance behaves differently in the cloud. A dependency thought to be optional turns out to be load-bearing. Networking does something unexpected. Each problem caught early makes later moves smoother.
Some systems get replatformed along the way. An old SQL Server on a physical box becomes a managed RDS instance. A file share becomes S3. Migration is not just copying, it is an opportunity to reduce operational overhead.
Cutover: The Actual Switch
Before the switch, both environments run in parallel with real traffic. DNS TTLs get reduced well in advance. Rollback plans stand ready.
DNS propagation is not instant everywhere. The internal team sees success while a customer in another part of the country is still hitting the old system. Planning for a tail of stragglers is standard practice.
The actual flip is usually anticlimactic. Update DNS, monitor for 24-48 hours, and keep someone available. That is normal.
Post-Migration: Optimisation
Migration is not finished when everything has moved. Over-provisioning during the move is expected because requirements are uncertain. Real data from production use reveals what can be scaled down. Reserved instances for predictable workloads. Managed services used properly.
This is also when technical debt gets addressed. The new environment is stable, making it the right time to containerise where beneficial, improve monitoring, and clean up rough edges.
The people side
Migration is as much a people problem as a technical one. The infrastructure changes, but so does how teams work day to day.
Staff who managed on-premises servers need training on cloud-native tools. On-call responsibilities shift. Monitoring dashboards change. Deployment workflows that worked for years get replaced. Without proper communication and training, the technical migration succeeds while the team struggles to operate what they have been given.
Change management does not need to be elaborate. Regular updates on what is moving and when, hands-on sessions with the new environment before cutover, and clear documentation of new procedures cover most of it. The goal is that nobody is surprised on go-live day.
Costs during migration
Running two environments simultaneously is unavoidable during migration. The old infrastructure stays live until the new environment is proven, which means paying for both for weeks or months depending on the complexity.
Budget for this overlap explicitly. It is not wasted spend, it is the cost of a safe transition. Rushing to decommission the old environment to save money is how rollback options disappear when they are needed most.
The old environment should only be decommissioned once the new one has been stable under real load for an agreed period. For most organisations, two to four weeks of parallel running is the minimum.
Security during the transition
Two live environments means double the attack surface temporarily. Both need monitoring, patching, and access controls throughout the migration period.
Firewall rules, security groups, and access credentials created during migration have a tendency to become permanent if nobody cleans them up afterward. Temporary VPN tunnels between old and new environments, broad access rules for testing, and shared credentials all need to be reviewed and tightened once migration is complete.
A post-migration security review should be a standard part of the process, not an afterthought.
Common patterns
A few things appear on nearly every migration:
Data transfer takes longer than expected. Network bandwidth has limits. Terabyte-scale moves need proper time budgets, and tools like AWS DataSync or physical transfer are worth considering.
Legacy systems have hidden dependencies. Specific Active Directory users, obscure environment variables, files in very particular locations. These surface during testing, not before.
DNS propagation is uneven. Success for the team does not mean success for every user immediately.
Licensing surprises. Software included in on-premises contracts may need separate cloud licensing.
Cloud migration is worth doing, but it is not a weekend project. It takes proper planning, experienced hands, and realistic expectations about timelines.