Moving to the cloud: what to decide before the first server moves

A cloud migration gets expensive when it is treated as a removal job for servers. The decisions that fix the bill and the risk are taken before anything moves: which workloads exist, which are worth rebuilding, which can simply be switched off. This is the order we follow with mid-sized companies leaving their own data centre or a hosting provider.

The inventory decides more than the provider does

Nothing can be migrated that is not understood. The first deliverable of any migration is a list of workloads with five facts against each: what it does and who uses it, what it depends on (databases, shared files, integrations with the ERP), what availability it needs, how sensitive its data is, and what it costs today across hardware, licences and maintenance hours.

With that list, each workload gets one of six decisions.

In practice, the exercise usually turns up workloads nobody has touched for months, and they are switched off before anything starts. It is the cheapest saving in the whole migration.

The bill goes up when servers are copied as they are

Copying every virtual machine from the data centre to a virtual machine in the cloud is the quickest route and the most expensive one six months later. The machines arrive at the size they had, sized for a peak that happens twice a year. In the cloud, that size is billed by the hour.

What changes the bill is using what already comes managed. A database on Azure SQL or Amazon RDS removes the server that had to be patched and backed up by hand. A nightly job starts in an Azure Functions or AWS Lambda function, runs its Python script and stops, with no machine running the rest of the day. And an application packaged in Docker deploys the same way on a small server as on a container service, without depending on how the machine was set up.

The load process behind Grupo Pomona Iberia's data warehouse has that shape: a Python ETL that runs every night, reads Excel files, SharePoint folders and the ERPs of four companies, and leaves the data ready in Power BI before management arrives. That job runs for minutes a day. It is the kind of workload that belongs in a scheduled task rather than on a permanent server.

The foundations come before the first workload

Before anything is migrated, the network, identity and backups have to be in place. It looks like paperwork, and it is what stops the first move ending in an incident.

Network: a virtual network with separate subnets for what faces the internet and what does not, and a VPN between the cloud and the offices for everything that stays on site. At Pomona, the permanent connection to the ERPs was solved with a VPN and direct SQL access, and that is the same kind of link a migration needs to move data without interrupting service.

Identity and access: who can create resources and who can see data, with two-step authentication and permissions by group rather than by person. Encryption at rest and in transit switched on by default. Automatic backups, with a test restore done before the first database is migrated.

Cost: tags on every resource (project, environment, owner) and budget alerts from day one. Without tags, the cloud invoice is a single number nobody can explain at month end.

A low-risk pilot teaches more than the plan does

The first workload to move should be visible and non-critical: an internal tool, the corporate website, a test environment. If something fails, nobody stops invoicing. If it goes well, the team has learnt the procedure on a workload that forgives mistakes.

After the pilot, the rest moves in waves ordered by risk. For each workload the script is the same: prepare the environment, migrate the data (almost always the slow part), deploy, test, redirect traffic, watch for a week or two and switch off the old environment. It is worth budgeting for both environments running at once during that period. That is the cost of migrating without downtime.

Switching off the old environment is the step that slips most. As long as the old server stays on just in case, the migration is not finished and everything is paid for twice.

Azure or AWS: the answer is in what the company already uses

For a company running Microsoft 365, Business Central and Power BI, Azure is the natural choice. Identity is already in Entra ID, and the data and AI services fit what the team already knows. For a company whose product is its own software, with containers and services exposed to customers, AWS is an equally solid base and one we build on too.

What is worth avoiding is spreading workloads across two providers without a specific reason. Each cloud demands its own network, identity and monitoring, and running two doubles the operational work. Multi-cloud makes sense under a regulatory requirement or for a particular service that only exists on one of them. In every other case it is complexity with no return.

Where to start this week

• List the ten most important workloads with their dependencies, data sensitivity and current monthly cost.
• Mark the ones nobody uses and switch them off before buying anything.
• Choose a visible, non-critical pilot and agree how its success will be measured.
• Turn on cost tags and budget alerts in the cloud account from the very first resource.
• Run a test restore of the current backups; if it fails on site, it will fail in the cloud.

If the case fits, we review it in a first 60-minute call.