A cloud migration doesn't start when the first server moves. It starts weeks earlier, with a set of decisions that most companies skip or push forward until they turn into problems halfway through the migration.
The usual approach is to pick a provider, set up a subscription, and start moving things across. That works fine for a proof of concept. But a real business has real users and dependencies hanging off everything, and there it tends to produce a migration that stalls halfway, or one that technically finishes but needs rebuilding three months later. And the second one is worse, because by then everyone has already celebrated.
So this is what I'd sort out before anything moves.
Identity
Before you touch any infrastructure, figure out how your people are going to log in to cloud resources. If you run Active Directory on-prem, Azure gives you two main routes. You can extend it with Entra Domain Services, or you can sync everything to Entra ID (Microsoft's cloud identity platform) and manage it from there. And those two look almost the same on a slide, but they take you to very different places. They change how applications get migrated and which services you can actually use natively. Get it wrong and you're rebuilding your identity layer later, with every workload you already moved sitting on top of it.
On AWS the question is a bit different, mostly whether you federate your existing identity provider into IAM Identity Center or set up access some other way. But the answer shapes the same things: how developers get into accounts and what your access control looks like from day one.
Network
On-prem networks are usually flat. Everything can reach everything, not because someone decided that, but because nobody decided anything. The cloud doesn't work that way, and the sooner you accept it the cheaper it gets.
In Azure you define Virtual Networks and subnets before you deploy anything serious. Same idea in AWS, just called VPCs. What you're really deciding is which workloads need to talk to each other and which ones should never be able to. Redoing that while everything is running is expensive and annoying. Doing it up front costs you a few workshops.
Data
You need to know what you're actually moving. Not "the databases", but which ones, how big they are, what performance they need, and whether any of them hold data that isn't allowed to leave the country under GDPR. Most businesses in the Netherlands have at least some data like that, so this is rarely a step you get to skip.
And yes, data classification is slow and kind of boring. But it's the step that surfaces the surprises, and you want those now. Not three months in, when half your estate is already in the cloud.
Team readiness
Someone has to own the environment after go-live. That person needs to know what they've inherited and what to do when something breaks at an inconvenient hour (it will be an inconvenient hour). If the answer to "who owns this?" is "we'll figure it out", that needs an answer before the project starts, not somewhere after.
You can train someone on your own team, if there's a person with the time and the interest. Or you can bring in someone external who has done this before, which sounds expensive until you compare it to a migration that drags on for months because nobody owns it. Both routes work, as long as the decision is made early.
Making these decisions is not the most fun part of a migration to the cloud. There's no architecture yet and nothing to spin up, just decisions, documentation and a lot of talking to people. Which is exactly why it gets skipped too often.
The migrations that end in a clean state are the ones that spent the first few weeks on the boring stuff.