A Project Management Playbook for Cloud Services Companies

Six migrations running at once, and one whiteboard trying to hold all of them

Picture a cloud services company of around sixty to ninety people, providing hosting, infrastructure management and migration support to other businesses. At any given time the delivery team is running several customer migrations in parallel, each on its own timeline, each with its own runbook, while also carrying platform engineering work and rotating on-call responsibility for incidents across every customer they host. It's not one project. It's five or six, plus whatever breaks at 2am.

Each individual migration is planned reasonably on its own. The problem shows up at the level above any single engagement: nobody has one place to see, across all of them at once, which migrations are on track, which are quietly behind, and which engineer is nominally staffed across three of them but actually underwater on all three. That view either doesn't exist, or it exists as a spreadsheet someone updates manually and everyone half-trusts.

This is the situation many cloud services teams are in before they adopt a system that gives every engagement its own board and gives leadership one honest view across all of them.

Before: migrations that looked fine individually, and a blind spot above them

The first problem is capacity that's committed on paper but not actually real. An engineer assigned 50% to one migration and 50% to another looks fully staffed on a resourcing sheet, but there's no shared, current view of whether that split is holding up week to week, especially once an incident on a third customer's infrastructure pulls that same engineer off both for two days.

The second problem is change requests and runbook updates landing in individual inboxes rather than a shared queue. A customer asks for a scope change mid-migration, or an on-call engineer resolves an incident and knows exactly what caused it, and both pieces of information tend to live with one person until someone happens to ask. Postmortems and runbooks end up scattered across docs, tickets and whatever the on-call engineer remembers writing down at 3am.

The third problem is the view leadership actually has. Asked "which of our six active migrations is at risk this week," the honest answer usually requires pinging five different engineers and hoping their individual answers add up to something coherent, rather than looking at one screen.

After: a blind spot that became one screen

The realistic shift for a team like this isn't that six parallel migrations become simpler to run. It's that the view above them stops being a reconstruction exercise. A migration quietly falling behind shows up because its board's WIP limit is stuck full, or its forecast starts drifting, weeks before the customer's go-live call turns into an uncomfortable conversation. Leadership gets an honest answer to "what's at risk this week" by looking at one place, not by polling the team.

It's honest that this doesn't reduce how much work six simultaneous engagements actually require. What changes is that overcommitment becomes visible before it becomes a missed date, and the postmortem written at 3am after an incident becomes something the next engineer on that account can actually find, instead of institutional memory that leaves the company the day that engineer does.