Azure, AWS or stay where you are?
The platform question is rarely technical. It is about which licences you already pay for, which skills your team has, and which applications refuse to move. Those three answers usually decide it before anyone opens a comparison chart.
For most Benelux mid-market organisations already on Microsoft 365, Azure is the path of least resistance: identity, licensing and support all sit in one place. AWS is the stronger choice where the workload is a custom application, where the development team already works there, or where specific managed services justify a second platform.
Staying on-premises is still a valid answer. Since the VMware licensing changes, we see organisations moving to Nutanix or Proxmox rather than to public cloud, particularly where data volumes make egress cost the deciding factor.
Whatever you pick, budget for cost governance from day one. Cloud spend does not drift because of the platform, it drifts because nobody owns the bill.
Start from what you already pay for
Nearly every organisation we work with already has Microsoft 365. That means identity, device management, email and collaboration are already there, and often a chunk of Azure credit alongside. Adding Azure to that estate is mostly configuration; adding a second platform is a second set of skills, a second bill and a second support relationship.
That is not an argument that Azure is technically superior. It is an argument that the total cost of a platform includes the people who have to run it at eleven at night.
When AWS is the better answer
Three situations, in our experience. When the workload is a custom-built application and the development team already knows AWS tooling; moving them is expensive and slow. When a specific managed service genuinely has no equivalent and is central to the product. And when a customer or a sector expects it.
We manage AWS estates alongside Azure ones, and running both is entirely workable. It just needs to be a decision rather than an accident, because two platforms that grew by accident cost more than either would deliberately.
The VMware question
The licensing changes at VMware pushed a lot of organisations to reopen a decision they thought was settled. There is no single right answer, but the options have become clearer.
| Option | Fits when | Watch out for |
|---|---|---|
| Stay on VMware | The estate is large, stable and the renewal is still affordable | Model the next renewal, not just this one |
| Nutanix | You want a supported commercial platform with a migration path and vendor backing | Hardware compatibility and the cost of the transition itself |
| Proxmox | The team is comfortable with open source and the estate is modest in size | Support model: decide who you call at three in the morning |
| Move to Azure or AWS | Workloads are already cloud-friendly and data volumes are modest | Egress cost and applications with licence models that punish cloud |
The applications that refuse to move
Every environment has one or two. A line-of-business application with a licence tied to a physical machine, a Citrix-published application nobody wants to touch, an SAP landscape with its own change calendar, or something with a hardware dongle. Those are not reasons to abandon a migration, but they are reasons to plan the migration around them rather than discovering them halfway.
We inventory those first. Where containers make a move easier we use Docker and Kubernetes; where the operating system is the constraint we work with Red Hat, SUSE and Ubuntu.
Keeping the bill from drifting
Cloud cost rarely explodes. It creeps: a test environment nobody switched off, a storage tier chosen once and never revisited, backups retained for seven years because that was the default. Six months later the bill is forty per cent higher and nobody can point at the cause.
Three habits fix most of it. Tag everything so spend can be attributed to a team or a project. Review the top ten line items monthly, not annually. And set a budget alert that goes to a person, not to a shared mailbox.
Cloud does not remove the backup question
Moving to Azure or AWS changes where the data sits, not who is responsible for recovering it. The shared responsibility model means the platform guarantees the infrastructure; your data and configuration are yours. We back up cloud workloads with Veeam for the same reason we back up on-premises ones, and the reasoning is set out under data and business continuity.
How we run a migration
Inventory first, then a wave plan, then a pilot group that includes at least one difficult user, then waves with a rollback that has actually been tested. We migrate outside your peak hours, which for a retailer means not in December and for a school means not in exam weeks.
Migration and day-to-day operations are described under cloud services, and the independent view on which direction to go under IT consultancy.
Questions we get about this
The questions that decide a platform choice.
Azure or AWS for a mid-market company?
If you already run Microsoft 365, Azure in most cases. Identity, licensing and support sit in one place and your team already knows half of it. AWS is the better answer when a development team already works there, when a specific managed service is central to your product, or when a customer requires it.
Is it still sensible to run our own servers?
Yes, in plenty of cases. Large data volumes, applications with licence models that penalise cloud, and predictable steady workloads often stay cheaper on your own hardware. The question is not cloud or not, it is which workload belongs where.
What should we do about VMware licensing?
Model the next two renewals before deciding anything. If the number is acceptable, staying put is the cheapest option because migration itself is not free. If it is not, Nutanix and Proxmox are the two alternatives we most often implement, and the choice between them comes down to how you want support to work.
How long does a Microsoft 365 migration take?
For a hundred users with straightforward mailboxes, a few weeks including a pilot. What extends it is shared mailboxes, public folders, an on-premises application that authenticates against the old directory, and archives nobody has looked at in years. We inventory those before quoting a timeline.
Where this lands in our work
Where a platform decision lands.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.