Entrazure
What we build
We move workloads off VMware, off ageing on-premise hardware and off other clouds into Azure. Every plan is built from measured dependencies rather than an asset spreadsheet, because the asset spreadsheet is always wrong about what talks to what.
A dependency map, not an inventory. We deploy the Azure Migrate appliance in your environment and let agentless discovery run for at least two weeks, long enough to catch the month-end batch and the reporting job nobody documented. The output is traffic-based: which server calls which port on which other server, how often, and what breaks if it stops.
Wave planning. Workloads are grouped by dependency cluster, not by hostname, owner or alphabet. A wave is defined as something you can move inside one maintenance window and reverse inside one hour. In practice that is 8 to 25 servers, or one application with its database and its integrations.
Right-sizing and a cost model before the first move. Azure Migrate sizes from observed CPU, memory and disk throughput rather than from the specification somebody bought in 2019. We build the monthly run cost per wave, including reservations, Azure Hybrid Benefit and SQL Server licensing, and we show you the waves where the cost case is weak. Lifting a badly sized estate into Azure at list price is how organizations conclude that the cloud is expensive.
The destination, built first. Workloads land in a governed subscription or they land in something you will pay to unpick later. If you do not already have one, the Azure landing zone is built before wave one: management groups, Azure Policy, network topology, identity and logging. If you do have one, we assess it and fix what the migration will expose.
Database moves. SQL Server to Azure SQL Managed Instance or Azure SQL Database, with the compatibility assessment done before the target is chosen rather than after. PostgreSQL and MySQL estates move to their managed equivalents. High availability and disaster recovery are designed at this point, not bolted on in year two.
Modernization where it pays back. Most servers are rehosted, because rehosting is fast, reversible and cheap to reason about. A small number of workloads are worth refactoring in flight: a web tier to App Service, a containerised service to Container Apps, a genuinely distributed platform to Azure Kubernetes Service. We are direct about which is which, and we say plainly when Kubernetes is not the answer.
What stays behind. Azure Arc brings the servers, SQL instances and clusters that are not moving under the same policy, monitoring and update management as everything else. The point is one operating model, not two.
The VMware exit, specifically
Broadcom’s repackaging of VMware into subscription bundles has changed the arithmetic for a lot of estates, and the renewal date is usually what starts the conversation. That deadline is the main risk in the project. A renewal quote that lands eight weeks before expiry does not leave time for a considered migration, and a rushed migration costs more than a bridging renewal.
So the first thing we do is establish the real deadline and work backwards from it. If the timeline does not fit, we say so and help you scope a one-year bridge, then migrate properly. If it does fit, discovery starts immediately, because dependency data has a two-week floor that cannot be compressed by adding people.
The technical work is unremarkable and that is the intention: agentless discovery, replication through Azure Migrate, a rehearsed test failover per wave, then the real cutover. What makes the difference is the sequencing (which cluster leaves first without stranding the others), the licensing arithmetic (Azure Hybrid Benefit changes the answer materially for Windows and SQL estates), and the decommission plan that actually ends the VMware contract instead of leaving four hosts running because nobody was sure.
How the engagement runs
Weeks 1 to 3, discovery. Azure Migrate appliance deployed, agentless discovery running, application owners interviewed. We build the dependency map, the application inventory with a named owner per application, and the first cut of the wave plan. Anything with no owner is flagged, because an application nobody owns is either a retirement candidate or an incident waiting for a migration to trigger it.
Weeks 4 and 5, design and business case. Target architecture, sizing, run cost per wave, network path, identity model and the downtime expected per application. Output is a migration plan you can take to a steering committee: waves, dates, cost, risk and the rollback trigger for each one.
Weeks 6 and 7, pilot wave. One low-risk wave, moved end to end. The pilot exists to test the process, not the workload. We rehearse the rollback for real, measure the actual cutover duration against the estimate, and correct the runbook before the estate is committed.
Weeks 8 onward, production waves. One wave every two to three weeks. Each has a written runbook, a validation checklist signed by the application owner, a rollback procedure and a post-cutover review. Sources stay intact for 14 days after each move.
Closing, decommission. The part that gets dropped when a project runs long, and the part that pays for the project. We produce the decommission list, confirm each source is genuinely unused with 30 days of monitoring data, and stay involved until the hypervisor licenses and the hardware maintenance contracts are actually cancelled.
What you keep
- The dependency map and the application inventory, with a named owner per application.
- The wave plan, including the waves we recommended against and why.
- Infrastructure as code for everything built in Azure, in your Git organization.
- The run cost model per wave, with the assumptions visible and editable.
- A cutover runbook and a rollback procedure per wave, already rehearsed.
- The decommission list, with the contracts and licenses it lets you cancel.
- A written record of every workload deliberately left on-premise, and the condition that would change that decision.
Who this is for
Organizations of roughly 50 to 5,000 people running 50 to 1,000 workloads on VMware, physical servers or a colocated estate, with a renewal date, a lease expiry, a data center exit or an acquisition forcing the timeline. It works well alongside an infrastructure as code engagement, because the migration is the moment your estate becomes reproducible or stays hand-built. Regulated environments are normal for us: see how this runs under clinical constraints in healthcare, and how residency and audit requirements are handled in compliance architecture.
Who this is not for
If you want a lift-and-shift of everything, as fast as possible, with no discovery phase, we are the wrong firm. That project is available cheaper elsewhere and it produces an Azure bill roughly twice what it should be, plus an estate nobody can govern.
If your applications are undocumented, unowned and unsupported by their vendors, migration is not your first problem. Fix the ownership question first, or accept a longer discovery than you want to pay for.
If the decision to move has not actually been made and you need a business case to make it, start with a scoped assessment rather than a migration engagement. And if you are moving to Azure mainly to reduce cost with no plan to change how anything runs, read managed Azure and FinOps first: the savings come from operating discipline after the move, not from the move itself.
Related
- Azure landing zone, the governed destination built before wave one.
- Managed Azure and FinOps, who runs the estate once it is migrated.
- Cybersecurity and Entra ID, the identity work a migration always exposes.
- All Azure services, the full engagement catalog.
Questions we get
How long does a migration take?
Discovery takes three weeks because dependency data needs at least two weeks of observation to be worth anything. After that, plan on one production wave every two to three weeks. A 120-server estate typically runs five to seven months end to end, including the decommission.
Can you migrate without downtime?
Some workloads, yes. Stateless web tiers and clustered databases can move with minutes of interruption. A monolithic application server with a single SQL instance cannot, and pretending otherwise is how migrations fail at 3am. We publish the expected downtime per wave before the wave is approved, and we agree the rollback trigger with you in advance.
What happens if a wave goes wrong?
We roll back. Source systems stay powered off but intact for at least 14 days after each cutover, DNS time-to-live is lowered before the window so a reversal propagates in minutes, and the rollback procedure is rehearsed during the pilot wave rather than improvised during the real one.
Do we have to move everything?
No, and most estates should not. Some workloads are cheaper and safer where they are, some are three months from end of life and should be retired instead of migrated, and some have a hardware dependency that Azure will not satisfy. We use Azure Arc to bring what stays under the same policy and monitoring, so you do not end up running two operating models forever.
Is our data staying in Canada?
Yes, if that is the requirement. Region restriction is enforced by Azure Policy at the management group level before the first workload moves, so a wave cannot accidentally land in a US region. The same mechanism covers data residency commitments you have already made to your own customers.
Do you resell the Azure subscriptions?
We can. Entrazure is a direct CSP, so licensing and support can run through us with consolidated billing. It is never a condition of the migration, and consulting is quoted separately from licensing so you can compare each on its own merits.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.