Exit the data centre with a clear plan
Leave a data centre or VMware estate for AWS, Azure or Google Cloud, improving the parts that matter during the move rather than copying every server as it is.
Overview
Data centre exits are often triggered by a date: a hosting contract ending, hardware out of warranty, or a VMware licensing change that rewrote the budget. Copying every virtual machine to the cloud unchanged is fast but usually costs more to run and keeps the same operational problems.
We use a lift-and-improve approach. Most servers move as they are, but databases go to managed services where it makes sense, backups and monitoring are rebuilt properly, and the new environment is defined in code. Servers that nobody uses are found and switched off instead of being migrated.
Signs you need this
- Your hardware support contract ends within the next year
- VMware renewal terms have changed and the new quote is under review
- Backups go to tape or a NAS in the same room as the servers
- There is no current list of which servers run which applications
What you get
- Estate inventory
- Servers, applications, owners, dependencies and traffic flows, collected with discovery tooling and checked with your team.
- Disposition per workload
- For each application: retire, rehost, move to a managed service or rebuild, with the reason recorded.
- Cloud landing environment
- Accounts, networking, hybrid connectivity, identity integration and backups ready before the first server moves.
- Replication and move groups
- Server replication configured and workloads grouped so dependent systems move together.
- Operations handover
- Monitoring, patching and backup routines for the new environment, with runbooks your team or provider can follow.
How the work runs
- 1
Discovery
2 to 4 weeks
Run discovery tools, interview application owners and build the dependency map. Mark candidates for retirement.
- 2
Landing and connectivity
2 to 4 weeks
Build the cloud environment and link it to the data centre with VPN or a dedicated connection.
- 3
Move groups
4 to 16 weeks
Replicate and cut over servers in groups, usually outside business hours, with tests by application owners after each group.
- 4
Exit
1 to 3 weeks
Confirm nothing still depends on the old site, wipe and return or dispose of hardware, and close the connection.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- Every server in the inventory is either migrated or recorded as retired
- Backups run in the cloud and a restore has been tested
- The data centre connection is closed and no traffic depends on it
- The new environment's network and accounts are described in code
Tools we work with
- AWS Application Migration Service
- Azure Migrate
- Google Migrate to Virtual Machines
- VMware vSphere
- Terraform
- AWS Site-to-Site VPN
- Azure ExpressRoute
- Microsoft Entra ID
- AWS Backup
- Ansible
Questions buyers ask
- Will every server need changes?
- No. Most move unchanged using replication tools. We only recommend changes where they reduce risk or running effort, such as moving a database to a managed service.
- How is downtime handled?
- Servers replicate continuously, so each cutover is a short switch, usually scheduled outside business hours. Application owners test before we close each move group.
- We do not have documentation. Is that a problem?
- It is common. Discovery tools and short interviews with application owners fill most gaps, and the inventory becomes your documentation afterwards.
- Who runs the cloud environment after the move?
- Your team, a provider of your choice, or us during business hours. The runbooks are written so any of these can take over.
Talk to us about on-premise to cloud migration.
Tell us what you run and where. We reply within one business day with questions or a quote.