Migrating away from VMware

How it is deployed

1. 1Survey of the current environment and active contracts.
2. 2Target design and validation criteria.
3. 3Migration test with non-critical machines.
4. 4Phased migration with a documented rollback plan.
5. 5Operation and monitoring of the new platform.

What the project delivers

The project delivers an inventory of the current environment, a target platform proposal with sizing, a migration plan by group with windows and owners, the execution with user validation, the new backup strategy and documentation of the resulting environment. Operating system and application licences remain with the company, and their compatibility with the target platform is confirmed with each vendor before dates are committed. A closing report sets out what moved, what remains and the decisions taken along the way.

What is at stake if it is left unaddressed

• Hidden dependencies between machines

  Services that call each other by fixed IP address or host name break when only part of the set is moved.

• Backups tied to the hypervisor

  If the backup tool is integrated with the current platform, the change affects the backup strategy too and must be planned at the same time.

• Application vendor support

  Some products only declare support on specific platforms. Confirm it before committing to a schedule.

Frequently asked questions

Does everything have to move at once?

No. Work proceeds in machine groups, starting with the least critical ones to validate the procedure.

Can we keep our current physical servers?

In many cases yes, if the hardware is under warranty and meets requirements. This is assessed during the inventory.

What happens to backups during migration?

The source backup is kept until the target has been validated and tested.

Can we simply stay on VMware?

That is a valid conclusion too. The point of the analysis is to decide with data, not to force a change.

Does everything have to move, or can part of it stay?

Part of it can stay. A common outcome is keeping tightly coupled workloads on the current platform and moving the rest to managed infrastructure or private cloud. The decision is made with the inventory in front of you, weighing licence cost, hardware life cycle and the requirements of each application.

How long does this kind of migration take?

It depends on the number of machines, the volume of data and the windows available. What stays constant is the order: inventory and testing first, migration by groups next, and an observation period at the end. Fixing a date before the inventory is the surest way to end up improvising.

What happens to backups during the change?

Protection of the source environment is maintained until the destination has verified backups of its own. Both strategies run side by side during the transition, and the previous one is only retired once a restore test has been completed on the new platform.

Can the inventory be done without committing to migrate?

Yes, and it is the sensible first step. An inventory of machines, real consumption and dependencies has value in itself: it supports renewal negotiations with the current vendor, reveals reserved capacity nobody uses and allows the decision to move — or not — to be made on data.

Do users notice the change?

If the migration is done properly, very little beyond the agreed downtime. Applications, shared folders and printers keep working the same way, because the change happens underneath them. What does change is how the platform is operated and what it costs. Users are told the window in advance and given a contact for the first days, which is usually enough to keep the transition uneventful.