Where do we start an Azure migration?

Short answer: with a readiness assessment, not the move — what you have and what depends on what; which workloads to modernize, lift-and-shift or retire; where the sensitive data sits; what it costs now and should cost after; and the order of steps, with a way back. Lift-and-shift alone rarely saves money; the savings come from modernizing what you moved.

The migrations that go sideways almost always skip the same step: they start moving things before they understand what they're moving.

Why teams skip the assessment

There's pressure to "move to the cloud", so a team picks the first application and starts. Then the surprises arrive: a hidden dependency on an old server, a licence that doesn't transfer, a database feature the target doesn't support, a compliance requirement nobody flagged. Each one is a delay. Stack enough of them and a three-month project becomes a twelve-month one.

What a readiness assessment answers

Before anything moves, you want written answers to five questions:

What do we actually have, and what depends on what? The inventory, including the dependencies nobody wrote down.
Which workloads modernize, which lift-and-shift, and which should simply be retired? Not everything deserves to make the trip.
Where is the sensitive data, and what does compliance require around it? Decided at the start, with your compliance owners, not discovered halfway through.
What does it cost today, and what should it cost after? Without a baseline, nobody can say whether the migration worked.
What's the order of operations, and where's the way back if a step fails? Every step needs a rollback, not just a plan.

It's the least glamorous step and the one with the most leverage: a short assessment routinely saves months of migration.

Why lift-and-shift disappoints

"We moved to the cloud and it cost more, not less" almost always traces back to one decision: lift-and-shift — taking servers exactly as they are and running them as cloud virtual machines. It's the fastest way to migrate. But a VM running around the clock in the cloud is just a more expensive version of the server you already had. You moved the box; you didn't change why it was expensive.

The savings show up when you modernize what you moved:

An application on a VM becomes an App Service that scales down when nobody's using it.
A database server becomes a managed database you don't patch or babysit.
Files on a disk become object storage, which costs a fraction as much.
Idle resources actually switch off instead of billing all night.

Lift-and-shift is a fine first step when you need out of a failing data centre fast. It's a poor final destination. If your bill went up after migrating, you don't have a cloud problem — you have an unfinished migration.