A cloud migration scoped from a server inventory alone will technically move workloads and commercially disappoint, because the inventory tells you what exists, not what depends on what. Scoping properly starts with application dependency mapping — understanding which systems talk to which, and in what order they need to move for nothing to break mid-migration.
The scoping decision that gets skipped most often is deciding, honestly, which workloads shouldn't move at all in the first phase — or possibly ever. A large, chatty on-premises application with local SQL and file shares will move technically fine and cost more to run in the cloud than it did on-premises, while still carrying the same operational overhead, unless it's re-architected first. That's a legitimate finding to surface during scoping, not a failure to admit later.
A workable scope separates the estate into categories: workloads that are genuinely simple to move (isolated stacks, dev/test environments, anything already blocked on ageing hardware), workloads that need a landing zone and identity foundation before anything moves, and workloads that need an application-level decision before migration makes sense at all.
The scope should also define what "done" means before the project starts — a landing zone that's operable from day one, not perfect; a wave sequence your operations team can actually staff and support; and a rollback plan for each wave, because a migration project that has no defined way to reverse a bad cutover is scoped optimistically, not realistically.
The projects that go well treat scoping as the majority of the risk-reduction work, with implementation following a plan that's already answered the hard questions — not as a formality before the technical work everyone actually wanted to start doing.
All technical perspectives