Project Management for Cloud Migration

A migration is one project pretending to be many

A cloud migration doesn't fit inside a sprint, or even inside the mental model most sprints are built for. It's one dependency graph spread across months: inventory before sequencing, sequencing before cutover, cutover before decommission. Most of the pain doesn't come from any single move being hard, it comes from planning each wave as though the others don't exist.

Two things reliably break a migration timeline. The first is a dependency discovered mid-wave that should have been mapped before sequencing started, a service nobody flagged as talking to the one being moved this week. The second is an architecture decision made in a meeting that nobody wrote down, so the same debate happens again three months later, with a different set of people and no memory of why the first decision was made.

Both are planning failures, not technical ones, and both get worse the longer the project runs, which a migration reliably does. A six-week plan can survive living in someone's head. A nine-month migration, moving through several engineers who join or leave the project along the way, cannot.

ShipSprint doesn't touch AWS, Azure or GCP directly, there's no cloud-provider integration of any kind. What it holds is the plan itself: the sequence, the capacity, and the decisions, in a form built to survive a project long enough to outlast the people who started it.

Why the wiki matters more here than on a normal project

Most projects are short enough that institutional memory survives on its own, the person who made a call is still around to be asked. A migration is often the exception. It can run long enough that the engineer who chose to re-platform rather than lift-and-shift a given service has moved teams, or left, by the time someone downstream needs to know why.

A wiki page written at the time of the decision, sitting next to the wave it concerns, with history intact, is the difference between that reasoning being retrievable and it being reconstructed from guesswork six months later. And because any sentence on a wiki page can become a task, a decision that implies follow-up work, "revisit this once the new VPC is live", doesn't have to be remembered by a person; it gets written down as work instead.

Rollback plans belong on the same wiki, written before cutover rather than improvised during it. A migration wave that goes wrong at 2am is a bad time to be inventing the rollback procedure from scratch. That's really what the wiki is buying you here: the difference between a 2am incident and a 2am incident where someone already wrote down what to do.

What a migration plan needs before wave one

• Every service mapped as a task with its dependencies before sequencing begins, not discovered mid-wave
• Architecture and rollback decisions written to the wiki at the time they're made, not reconstructed from memory later
• Capacity for the migration planned as its own workload, not squeezed into the gaps of business-as-usual sprints
• A named owner per wave who checks the forecast directly, rather than relying on the two engineers doing the work to flag a slip themselves

One place for a project that touches every team

A migration this size rarely stays inside engineering, finance wants the cost trend, security wants sign-off per wave, leadership wants to know if the date is still real. Engineering, HR, marketing and operations each get their own templates and vocabulary on one subscription, so pulling another function into the loop doesn't mean a separate spreadsheet or a translated status update.

ShipSprint also connects to Claude and ChatGPT, so a question like "what's blocking wave 4" can be answered in plain language without interrupting whoever's actually doing the work.