What a Cloud Migration Actually Looks Like From the PM Seat

Here is something that surprises people. The project manager running a cloud migration barely touches the cloud.

You would think the person leading the move to Azure or AWS would be deep in the technology. They are not. The engineers handle that. The PM is managing something else entirely, and it is the thing that actually decides whether the whole project succeeds or blows up.

I have been an IT project manager for over 10 years, inside real enterprise environments. Infrastructure projects, system migrations, the kind of work where you are moving things the whole business runs on and you cannot afford to break them. So this is not a description from a certification slide. It is the view from the seat, including the parts that go wrong that nobody puts in the project plan.

The misunderstanding that stops people before they start

When people hear “cloud migration,” they assume it is a technical project. So they think one of two things. Either “I could never run that, I am not technical enough,” or they picture the PM sitting there configuring servers and writing scripts alongside the engineers.

Both are wrong. On a real migration, the deep technical work belongs to the cloud engineers, the architects, and the vendor. That is their job and they are good at it. If the PM tried to do it, they would just get in the way.

So what is the PM actually doing? Here is the part people miss. A cloud migration only fails for a handful of reasons, and almost none of them are technical. It fails because something got moved before the thing it depended on. It fails because nobody planned for what happens if the move goes wrong at two in the morning. It fails because the team that owns a critical system was never brought along, so they quietly fought it the whole way. It fails because the business got surprised by an outage nobody warned them about.

A cloud migration almost never fails because the technology did not work. It fails because of bad sequencing, no backup plan, and people who were not brought along. Every one of those is a project management problem, not a technical one.

That is the whole reason the PM is there. Not to move the technology. To make sure the business does not break while it moves.

The one question that is the entire job

If you strip the job down, the PM on a cloud migration owns the answer to one question, asked over and over, at every single step.

“If we move this now, what could break, and what is our plan when it does?”

That question is the entire job. The engineers know how to move a system. Your value is knowing what depends on that system, what order things have to move in, who needs to be warned, and what the rollback plan is if the move fails. Risk, sequence, and people. That is what you own.

The engineers own how it moves. The PM owns what breaks if it moves wrong. Those are two completely different jobs, and only one of them requires you to be technical.

This is also why these projects run in phases. The phases are not bureaucracy. They exist to take an enormous, risky move and break it into controlled steps, so that at no point are you betting the whole business on one big switch. Here are the four, the way you would experience them from the seat.

Phase 1: Discovery and assessment

The least glamorous phase, and the one that quietly decides whether the whole project succeeds.

Before you move anything, you have to know what you have got. The team builds an inventory: every application, every server, every database the company runs. And more importantly, how they all connect. Because the killer on these projects is dependencies. This app secretly talks to that database. This system pulls data from another one at 2 a.m. every night that nobody remembered. If you move one and not the other, something breaks in a way that is really hard to trace.

Then, for each application, somebody decides the strategy. Do we lift and shift it as is? Tweak it to fit the cloud? Rebuild it? Or, honestly, retire it because nobody has used it in two years? You do not need to make those technical calls yourself, but you drive the process that gets them made.

What you own here is making discovery actually happen, which is harder than it sounds. The app owners are the ones who resist. They are busy, and you are asking them to stop their day job to help you document something so you can go touch their baby. A lot of them stall, give half answers, or quietly hope the project loses steam. Getting real information out of reluctant people is pure project management, and it is most of the job in this phase.

The number one reason migrations blow up later is a dependency nobody found early. On these projects, the thing you did not know about is always what hurts you.

Where this phase breaks is simple. You rush it. Someone wants to look fast, discovery gets half done, and three months later a “simple” server move takes down a system on the other side of the building that nobody knew was connected. Time spent here is the cheapest insurance on the whole project.

Phase 2: Planning and sequencing

This is where all that discovery turns into an actual sequence, and it is the most PM-heavy phase of the project.

You do not move everything at once. You group things into waves. A wave is a batch of systems that move together, and the order of those waves is everything. You lead with the low-risk stuff: the test environments, the systems almost nobody depends on. You do that on purpose, so the team gets reps, builds confidence, and finds the surprises on things that do not matter before you touch the things that do. The mission-critical systems, the ones that take down the business if they hiccup, go later, once the process is proven.

This is where sequencing becomes an art. Those dependencies from phase one dictate the order. You cannot move an application into the cloud and leave the database it relies on sitting in the old data center, unless you have planned exactly how they will talk across that gap in the meantime. Get the order wrong and you create outages out of thin air.

What you own here is a lot. The wave plan. The schedule, including negotiating maintenance windows, which means convincing business units to accept a little downtime at 6 a.m. on a Sunday. The communication plan, so nobody gets surprised. And most importantly, making sure every single move has a defined rollback plan and clear success criteria before it happens.

Never approve a move without knowing two things: how you will tell if it worked, and how you will undo it if it did not. A migration step without a rollback plan is not a plan. It is a gamble.

Everyone resists here, because everyone wants to control their own timing. One business unit wants to go last because they are scared. Another insists they cannot take any downtime, ever. Finance is watching the bill and asking why it is taking so long. Your job is to hold the sequence together against all of that pressure, because the sequence is what keeps the risk controlled.

Where it breaks is when the plan is really just a wish. Aggressive dates nobody believes, no real rollback plans, maintenance windows that were never actually agreed to. A pretty Gantt chart that everyone privately knows is fiction.

Phase 3: Migration and cutover

This is the part people picture when they think of a migration, and it is where all the planning either pays off or falls apart.

You run the waves you planned. Within each wave, the big moment is cutover: the point where you actually switch production over from the old environment to the new one. It usually happens in a tight window, often a weekend or overnight, when the fewest people are using the systems.

Cutover is intense. Engineers execute a step-by-step runbook, a document listing every task in order with who does it and how long it should take. You are on a call with the whole team, sometimes for hours, moving through it task by task. And you, the PM, are running that call. Tracking whether you are on schedule, surfacing problems the second they appear, keeping everyone calm and coordinated while the clock runs.

Then comes the single most important moment of the whole project: the go/no-go decision. At a certain point you have to look at the validation results and decide. Is this working? Do we commit and finish the cutover? Or is something wrong, and we roll back to the old environment before users show up Monday morning? That call has to be made against the criteria you set in phase two, not against how much everyone wants to be done.

The hardest thing a PM does on a migration is call the rollback. Everyone is exhausted, everyone wants to be finished, and you are the one who has to say we are not there, we are reverting. Knowing when to pull that trigger is the whole job.

Where this phase breaks is ego and exhaustion. The move is running late, something looks off, and the pressure to push through and declare victory is enormous. So people override their own go/no-go criteria, finish the cutover on a shaky result, and users log in Monday to a system that is half broken with no clean way back. The disciplined PM would rather roll back at 4 a.m. and try again next weekend than hand the business a mess. That discipline is exactly what they are paying you for.

Phase 4: Stabilization and closeout

The phase everyone wants to skip, which is exactly why it is where a lot of the value leaks out.

Right after a successful cutover you are not done. You go into what is often called hypercare. For the next stretch, days or weeks, you watch the new environment like a hawk. Little things surface: performance is slower than expected here, a report does not quite match there, a nightly job fails the first time it runs. The users are on the new system now, and you are tracking and knocking down every issue fast before it turns into a crisis. You usually keep the old environment on standby for a bit, until everyone is confident.

Then two things have to actually happen, and this is where PMs earn their keep.

First, you decommission the old environment. You shut down and turn off the old servers and data center footprint. This matters more than it sounds. Until you turn the old stuff off, the company is paying for both. The entire financial case for the migration, the cost savings everyone promised leadership, does not exist until decommission happens.

A migration does not save a dime until you turn off the old thing. The savings everyone promised leadership are sitting in the decommission step that everyone is too tired to finish.

Second, you close it out properly. What went well, what went wrong, what you would do differently on the next wave or the next project. On a migration with many waves, that lesson learned literally makes the next cutover smoother.

Human nature is what resists here. The exciting part is over, so people drift off to the next shiny project and leave the old servers running and the lessons unwritten. Where it breaks is a project that technically succeeded but never captured its savings and never got smarter, because nobody had the discipline to finish. The PM who drives the boring closeout is the one who actually delivered the value they were hired to deliver.

The nightly job that failed an hour from done

I was on a migration where we were moving a batch of systems over a weekend. Everything on the runbook was green. We were maybe an hour from calling it done, and everyone was ready to go home.

But part of our validation was checking that a nightly financial process still ran correctly in the new environment. It failed. When we dug in, we found a dependency that discovery had missed. That process quietly pulled data from another system we had not moved yet, and across the new setup it could not reach it.

Here is the moment. Nothing was on fire. Users would not even notice until that process failed to produce numbers a couple of days later. It would have been so easy to say “we will fix it Monday” and declare the cutover a success. Half the room wanted to.

But that was exactly the kind of thing that turns into a finance team with no month-end numbers and a very bad Monday. So we made the call. We rolled back that piece, went home, fixed the dependency during the week, and moved it cleanly the next weekend.

Nobody outside that room ever knew anything happened. And that is the point. The engineers found the failure. But the decision to roll back instead of pushing through was the PM call. That is the seat. Not touching the technology. Owning what happens if it goes wrong.

Three things to do with this

1. Learn the four phases cold. Discovery, planning and sequencing, migration and cutover, then stabilization and closeout. That is the spine of every migration. If you can walk someone through those four phases and what happens in each, you already sound like someone who has been near this work, because most people cannot.

2. Remember where your value actually sits. Not in the technology. In risk, sequence, and people. On any migration your job is to always know what depends on what, what order things move in, who needs to be warned, and what the rollback plan is. You do not need to be technical to own that. You need to be the person relentlessly asking, “if we move this now, what breaks, and what is our plan when it does?”

3. You do not have to lead a massive one to have the experience. Get onto a migration in any capacity. Own the runbook for a single wave. Track the dependencies. Run the cutover call. Coordinate the comms so nobody gets surprised. Any one of those is real, describable migration experience, and it is the kind of thing that gets you the next role.

It is a project management problem

A cloud migration sounds like the most technical, intimidating project in the building. From the outside, it is. But now you have seen it from the seat, and you know the truth. Underneath the technology, it is a project management problem. Sequence, risk, and people, managed carefully across four phases so the business never breaks while it moves.

That should change how you see these projects. Not as something you need a computer science degree to touch, but as one of the most valuable and most in-demand kinds of experience you can go get. The company needs someone to own what happens if it goes wrong. That someone can be you.

So the next time you see “cloud migration experience” on a job posting, you will not just know what it means. You will know exactly what the job is, and you will know you can do it.

Keep reading

• What actually happens in an enterprise IT project
• How IT projects actually get budgeted and approved
• What is a PMO?
• Project management experience examples