Cloud Migration: Ten Insights from Real Lift-and-Shifts

Cloud migrations look neat in the proposal and messy in the conference room at 9pm on cutover weekend. I have been through enough of them — both sides of the table — to have developed opinions. What follows is not a project plan. It is ten things I wish every sponsor understood before they signed the statement of work. Some of them are uncomfortable. All of them are things I have seen play out more than once.

One: the first workload will take three times as long as you think

Every migration underestimates the first workload. Not the average one — the first one. The first workload teaches you the things you did not know you needed to learn. Network connectivity. Identity federation. DNS cutover. Firewall rules. Backup integration. Monitoring. Change management. None of these show up in a discovery spreadsheet, because they are not workload-specific. They are environmental, and the first workload pays the cost of building the environment.

Plan for it. Budget a long runway for the first workload, assume later workloads will go faster, and do not let anyone extrapolate the first workload's timeline across the rest of the portfolio. That extrapolation produces schedules that miss by a factor of two.

Two: discovery is never complete

Somebody will find a server in week six that nobody told you about. It will be running a critical business process. It will have been set up in 2014 by a person who no longer works there. It will have a dependency on a file share that nobody documented. This is universal. Budget for it.

The practical version is to run discovery tools for longer than you think you need. CloudEndure, Azure Migrate, RVTools, whatever your flavor — let them collect for weeks, not days. Capture traffic patterns, not just inventory. Then interview people and still expect surprises.

Three: network and identity come first, always

Do not migrate workloads before you have network connectivity and identity federation solved. I have watched teams get excited about moving a workload, succeed in getting it running in the cloud, and then discover that users cannot log in because the AD trust was never set up. Or that the app is trying to reach a database on-prem and the site-to-site VPN has not been configured. Or that DNS resolution inside the cloud VPC does not see the on-prem namespace.

The boring foundational work — VPC, subnets, routing, VPN or ExpressRoute, DNS conditional forwarders, AD federation — has to happen first. It is not exciting. It is not a milestone you can show to the steering committee. It is the thing that makes every subsequent workload migration boring instead of painful, and boring is what you want.

Four: monitoring must move in parallel, not after

Teams routinely defer monitoring to "after the migration" and then spend three months debugging performance issues blind. Do not do this. The workload that lands in the cloud needs the same observability it had on-prem, plus new observability for cloud-specific things like IAM events and network flow. Set this up before cutover, not after. The first time you have a problem in production, you will wish you had done it.

Five: your cost estimates are wrong

Nobody's cost estimates are right on the first pass. They are wrong in predictable directions. Storage costs are usually underestimated because backup and snapshot consumption adds up. Data transfer costs are almost always underestimated because nobody models traffic accurately until the workload is running. Reserved instance purchases are usually made prematurely and end up not matching the actual usage pattern.

What works: migrate, run for 90 days without commitments, measure actual consumption, then purchase reservations against real usage. Do not let finance push you to lock in reservations upfront "to save money." You will save less money than you think and you will be stuck with capacity that does not match reality.

Six: you will discover applications you should retire

Halfway through the migration, you will find applications that nobody actively uses, or uses so rarely that migrating them is not worth the effort. The natural instinct is to migrate them anyway "just in case." Resist. Every migration is an opportunity to shrink the portfolio, and the applications that can be retired without complaint are the ones that should be retired.

The political version of this is harder. Someone owns every application, and the owner will fight retirement even if no one has used it in eighteen months. Present data, not opinions. "This application has received four requests in the past six months, three of them from the same person, and the nearest alternative covers the same use case" is harder to argue with than "we think nobody cares."

Seven: change freezes never happen the way they are planned

The business will tell you to schedule cutover for a weekend when nothing is happening. That weekend does not exist. Something is always happening. Month-end close, quarter-end, a product launch, an investor meeting, a board prep, a customer commitment. If you wait for the perfect weekend you will wait forever.

The practical answer is to pick a good enough weekend, communicate clearly, negotiate the exceptions, and execute. Cutover weekends are survivable if everyone knows their role and the rollback plan is real. They are not survivable if half the team is dealing with a competing priority.

Eight: rollback plans that do not account for data divergence are lies

Everyone has a rollback plan. Most rollback plans are theater. The hard question is what you do if the cutover goes wrong after transactions have started landing on the new environment. You cannot simply flip back, because the data in the new environment has moved forward while the old one sat frozen. If you roll back to the old environment, you lose those transactions.

Real rollback requires one of two things. Either you can replay the transactions, which means you captured them in a way that supports replay. Or you accept a small window of data loss and document it in advance so the business agrees to the risk. Pretending your rollback is perfect when it is not is how you end up making a decision under pressure that costs you more than the original incident.

Nine: people leave mid-migration

On any migration that lasts longer than six months, someone important will leave. They will take knowledge with them that is not written down. The migration plan needs to survive this. Documentation discipline matters not for the audit — it matters because the person who built the last network diagram might not be there when you need the next one.

Write things down as you go. Record the decisions, not just the configurations. The why is what nobody else knows when they pick up the work, and the why is what lets them continue without re-litigating every question.

Ten: the business outcome is not "we moved to the cloud"

This is the biggest one. The business outcome of a cloud migration is whatever the business wanted when they approved it. Faster time to market. Lower fixed costs. Elastic capacity for seasonal spikes. Compliance certifications. Better developer experience. Pick the outcome at the start, measure it, and report against it.

The failure mode is declaring victory when the last workload lands in the new environment. That is not victory. Victory is when the business outcome happens. If you migrated to save money and you are not saving money, the migration is not done, regardless of where the workloads are running. If you migrated to move faster and you are not moving faster, same thing.

The honest test at the end of a migration is not "did we finish on time and on budget." It is "did the thing we said would happen actually happen." If the answer is no, there is follow-up work that nobody budgeted for, and you need to have the honest conversation before the team disbands and moves on to the next project.

What I keep coming back to

Cloud migrations are not technical projects. They are organizational change projects that happen to have a lot of technical detail. The technical detail is tractable. The change management is what sinks them. Budget accordingly, communicate more than feels necessary, and remember that the goal is not the migration itself — the goal is whatever the migration was supposed to enable. Keep your eye on that, and the ten things above will feel like annoyances rather than crises.