Common Problems That Undermine VMware Transitions—And How to Avoid Them

VMware is used by so many teams for so many things that transitions can be brutal. Few likely made the effort to learn how the existing system was used, much less document it. And even less likely bothered to explore near-term environment changes. 

Many IT executives have made the transition from VMware to an alternative and lived to tell the tale. Usually, they have scars – largely due to a lack of preparation.

Any IT team that is considering making changes should pay attention to these top problems that undermine VMware transitions and how to avoid them. (And note that most of the guidelines apply to other enterprise migrations, too.)

Nobody Documented Where VMware is Currently Used

VMware is insidious, in a good way. 

Over the years, business units adopted VMware for a wide range of routine functions. The CISO’s team might use VCenter tags for policy compliance whereas the Compliance department might use NSX flow data for audit assessments. The CFO’s group might tap into VCenter files to help with chargebacks.

However, few departments bothered to document their efforts about the VMware integration, much less inform IT. As a result, once-reliable systems implode as soon as the switch is activated. 

Depending on the nature of the reliance, there are various outcomes if the transition team was unaware of the connection. The most likely outcome? The reliant function fails, as it can’t find the hooks it typically uses.

Many system migrations are a matter of swapping one platform for another. With VMware, the transition team must pay more attention to identifying the hooks that tied VMWare into existing business functions. Making the transition smooth goes way beyond avoiding BIOS versus UEFI boot mismatches.

What to do about it

Start by polling every department for a full list of everything that uses VMWare. The report should include APIs, storage/recovery, audits, and so on. 

This is a time-consuming and slow option. It is likely to yield a decent amount of information, but certainly not all of it, and not due to malice. People often are unaware of the integrations. Someone who held an employee’s job three predecessors ago might have connected an application to VMware without documenting it. It works fine, so the employee never needed to explore the external connections.

Next, have an IT team search all environments for any evidence of VMware reliance. This will likely unearth quite a bit more, but again, do not expect it to find everything.

At this point, a migration team might consider the nuclear option. Announce to all employees, contractors, partners, major customers and pretty much anyone with privileges in the global environment that IT is conducting preliminary VMware tests, with an eye on transition to a better system next year. Include anyone who might have a VMware hook. Tell those people that on a particular business day date, you will temporarily pull the plug. 

Then do it.

Your Help Desk and others immediately will hear from livid members of the workforce that a system stopped functioning. This is painful, but it is the best way to identify hidden dependencies. 

Unfortunately, you can’t perform this “reboot” only once. Some workers may not be on duty during the day of the first test. Repeat the exercise, perhaps on a different weekday or on a weekend. You want to reach as much of the workforce as practical. 

A fringe benefit: This tactic can also reveal cases of shadow IT that have nothing to do with VMware but still relied on it.

Another benefit: Consider this “reboot” tactic as a back road into producing a more useful data map that describes what the environment actually looks like. That has other benefits in efforts for corporate compliance, cybersecurity, licensing costs (expect to discover a massive number of redundancies that might allow you to squash licensing expenses), and even overall efficiency.

Project Planning Doesn’t Include the Organizations’ Upcoming Plans

Like most IT projects, VMware transitions overwhelmingly take far more time and budget than anyone projects – especially involving the time allocated to smooth the transition. (Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”) Wise IT managers work to minimize surprises.

A too-common issue for complicated enterprise migrations is failing to make them future-proof. Even a smooth transition may take six months to a year. Sometimes it takes as long as four years to complete everything, including post-transition training. 

During that time, the company’s global landscape absolutely will meaningfully change. 

What to do about it

Someone on the transition team should meet with the CFO and relevant line of business chiefs. Ask for confidential peeks into their plans, especially involving mergers and acquisitions. Is a division likely to be sold? What companies are on the short list to be acquired?

Then there’s geography. Is the company entering or exiting key countries? Does that change compliance needs that could impact what the VMware replacement has to do?

It is impossible to achieve a perfect crystal ball vision of an organization’s makeup 12 months from now. But making a serious effort for outreach at the beginning of the project can avoid roadblocks. Plus, senior management will have a more difficult time blaming the transition team about something no one bothered to share. 

Map the Old Functionality to the New 

The goal is obviously to adopt the best system possible, with the greatest range of features and capabilities. That said, it is hard to find an exact functionality match. 

What to do about it

Map the issues ahead of time, so that the transition team can adjust for shortfalls.

Plan for training. Not (only) in a general way (which knobs to turn), but with an eye to helping staff adopt the new solution. Even if the new system delivers the identical capabilities as the current setup, it almost certainly performs those functions differently.

For instance, the homegrown app that the CISO’s office uses for policy enforcement won’t deliver a plug-n-play transition. Those scripts must be rewritten to adapt to the new software, which means the DevOps team has to learn new skills and to allocate time to make the changes. The budget needs to anticipate that. 

Even if VMware Needs to Go, it May Not Need to Entirely Go

Once IT truly understands how VMware is used and what applications relying on it, the team can then meaningfully assess various alternatives. 

IT needs to know all capabilities the new system has to control and—critically—how those capabilities are handled. The analysis may reveal that some of the original VMware can remain. 

A transition doesn't necessarily mean everything must go. Consider phased migrations.

A recent Forrester report made an eloquent argument about establishing why a transition is happening. There may be some pleasant surprises. 

“In one example, a client had already initiated proofs of concept with multiple vendors before realizing that nearly 30% of their VMware estate could simply be maintained as is for the next two years,” Forrester’s report said. “In another case, a team migrated workloads successfully but struggled post-cutover because operational ownership and support models were never clarified.”

Don’t Skimp on Transition Planning

When transitioning from something as multi-talented and customizable as VMware, the upfront work is critical. Think of it as due diligence.

Teams routinely migrate software without putting in the upfront work. But then they are saddled with months of post-transition cleanup along with a plethora of glitches, which fuels downtime and operational inefficiency. 

In short, the IT team does not have to do this level of prep. But the CIO will be happier if it’s done. Line of business chiefs can get quite livid, even if it was their fault. 

To learn more about VMware alternatives, keep reading here.