Introduction:

I received a text from a former colleague and friend out of the blue today that read “I guess VMware is officially dead now that they’re just part of the Broadcom portfolio”. I had already started to write this article, but his sentiments really hit home with what I was feeling throughout the process of working through things; I felt a little like I was writing an obituary for a friend. Not that VMware is dead, but after the Broadcom acquisition there is certainly a sense that the company and technology that I have been passionate about for the last 15+ years will be changing in the very near future.

I started working with VMware technologies in the mid-2000’s and instantly knew that virtualization is where I wanted to focus my efforts in the IT industry. I’ve passed at least 7 VMware certifications (3 of which were VCAPs), I attended 4 VMworlds, and was recognized as a vExpert for 3 years. I’ve worked with most of their Datacenter-centric products and some of the End User Computing (EUC) technologies. I’ve spent long hours in the middle of the night with VMware support to resolve critical outages, and I’ve had the privilege of being employed at a software company that competes with VMware in some areas, and augments them in others for the past 5 years. It has been an exciting ride, and anyone else who’s taken a similar journey can probably relate. But with the latest news (now a few weeks old) out of Palo Alto, change is very likely on the horizon.

In this article I am attempting to summarize what I’ve heard from my customers who are leveraging VMware and concerned with the recent Broadcom acquisition. Migration with VMware can be a complex problem, and I hope to offer some guidance for customers who are wondering if this is something that they should be considering, as well as address some best practices on what a migration might look like. The challenge with attempting to tackle something like this is that the answer (as with so many other things in IT) is not a one-size-fits-all approach. Each organization has its own processes, procedures, requirements, and personnel that are uniquely its own and all of these will play into the decision for migration as well as the path towards any such efforts.

A Cause for Concern?

Over the past 6-12 months I’ve spoken with customers all over the spectrum as far as what their priorities would be if and then when the Broadcom acquisition closed. Some customers were ready to jump ship altogether, others on the opposite end of the spectrum were indifferent to the acquisition and considered things to be business as usual. Most customers, however, at least wanted to understand what their alternatives were so that they could take a measured approach to migration should the need arise.

From the customers that I have spoken with, their concerns with the acquisition are usually centered around three pain points. None of these have actually come to fruition yet. Nonetheless, we are already starting to read the tea leaves by way of layoffs, office closures, and product line spinoffs, which will all have an impact on customers in both the short and long term. The bottom line is that Broadcom is following a playbook that has been very familiar to them across previous acquisitions – they are seeking to capitalize on their investment by increasing revenues and cutting costs. The typical concerns that I am hearing include:

1. Broadcom price increases: Broadcom has a history of increasing prices post-acquisition with other products. In previous instances, they knew customers were reliant on solutions that Broadcom purchased and had no other option than to accept steep price hikes upon their next renewal. All indications are that this is happening again now.
2. Product discontinuation: Customers are also wondering which products may find themselves being discontinued. If these decisions impact their critical workloads they want to be better prepared for the road ahead.
3. Future roadmap/investment: Will there continue to be investment in the products under Broadcom leadership? In previous acquisitions, the pace and depth of innovation waned significantly; in some cases it stopped altogether.

Discovery Phase – Should we Migrate?

With VMware, the migration question comes with a very complex answer due to the nature of VMware technologies potentially being embedded in a majority of all IT systems in the datacenter, and at times the public cloud as well. These days, the VMware technologies stack encompasses far more than their original breadwinner of vSphere for server virtualization. A lot of customers have bought into the entire VMware ecosystem – VMware technologies are hosting all of their compute workloads, running their virtual desktops and remote access systems, providing security, networking, disaster recovery, storage, identity management and application access just to name a few.

If you are happy with the VMware technologies that are in use today, and have zero concern surrounding the Broadcom acquisition, I would say that this is a pretty straightforward answer. You are in a good position to continue with your current investment in VMware. VMware has been a leader in the industry for a long time for a good reason; hopefully, under Broadcom leadership, this trend continues and you can expect the same innovation and service levels that you are accustomed to as a VMware customer.

Discovery Phase Considerations

For the rest of us, here are some good steps and questions to consider when making this determination:

1. Take inventory: What VMware solutions are we licensed for/using? How mission-critical are these technologies? Who are the stakeholders for each system? Identify dependencies for each solution in use.
2. Assess the organization’s ongoing need for each solution: Can we do without any of these solutions? Which products are not being actively used and have transitioned to being shelfware (you might be surprised at this answer when asked of the stakeholders)?
3. Discover product overlap: What other technology investments has the organization made that have overlapping capability sets? Do these solutions meet the requirements that we have for the corresponding VMware capability?
4. Evaluate alternatives for each solution: Are there best-of-breed alternatives in the market that meet our organizations requirements for the challenge that this technology is being used to solve? Do these technologies offer a migration path? Do some of these alternatives better position us for migration away from other VMware technologies in the future?
5. Account for the cost of migration: The cost to migrate IT systems can often be drastically underestimated. How much work is needed to migrate? How much will ramp-up time on a new technology cost the organization?

Discovery Phase Outputs

When the discovery phase is complete, you should understand at least the following about the task at hand:

1. All VMware Products currently licensed, dependencies and the stakeholders for each
2. VMware Products that aren’t actively in use (shelfware)
3. Existing (competitive solutions) investments with overlapping capabilities
4. Viable alternative solutions
5. Estimated costs for migration
6. VMware products that are essential to the organization’s strategy that cannot be initially migrated either due to criticality of the system or lack of viable alternative solutions

The Decision Point

Armed with your outputs from discovery, you should be in a position to determine whether to move away from VMware or not. There are really only three outcomes here, but I suspect that most customers will probably fall into the third bucket

1. No migration:
   1. We are happy with all of our current investments
   2. The cost to migrate is too great; we are willing to accept potential price increases and risks
2. Migrate everything
3. Migrate the surrounding solutions that we identified where good alternatives have been identified:
   1. Stop paying for shelfware.
   2. Reduce overall VMware licensing cost by investing in third-party solutions where it makes sense.
   3. Leave core critical VMware solutions alone but migrate the add-on solutions.

Quite a few of the customers that I’ve spoken with who have already completed their discovery phase here are planning on paring back to just the core VMware SDDC services (Compute (vSphere), Networking (NSX), and Storage (vSAN/others)). Others are planning on doing away with things like the Aria suite and other solutions for which they’ve identified good alternatives.

Planning – Migration Strategy

Now that the decision has been made to migrate – just remember a few key adages :

1. “Manage the migration like a product”
   1. Gather and manage ideas
   2. Determine specs
   3. Create a product roadmap
      1. Can some products be migrated in parallel?
      2. Are there any dependencies on other migrations?
   4. Prioritize work
   5. Delivery
   6. Testing/Measurement
   7. Gather feedback: involve end-users early and often – close the feedback loop
2. “Leverage existing investments first”
   You already have the skillsets to manage these solutions.
3. “Not everything needs to migrate right away”

Start in areas with the greatest cost impact. Just remember that there is no need to boil the ocean.

Conclusion

Hopefully this article has been thought-provoking and has further helped set a framework to navigate what could be a daunting task. I would be remiss if I didn’t mention that here at CloudBolt offer solutions that are great options – ones I honestly believe are better – for key components of the VMware suite of products should you decide that migration is a path that you are considering. Please reach out to our team with any additional questions, or if you would like to set up a demonstration to discuss your needs.

CloudBolt Cloud Management Platform – Directly replaces the Aria Automation and Aria Orchestration capabilities. Easy Python (the language of automation) backed extensibility. We have a migration path for Aria Automation customers that helps to minimize any burden of migration to CloudBolt and allows you to continue to leverage the development work you and your team did in vRA/vRO specifically. Be on the lookout for additional demonstrations and posts surrounding this migration capability in the coming weeks. (Spoiler alert: CloudBolt makes it easy. Seriously)

CloudBolt Cloud Cost Management – directly replaces the VMware Aria Cost powered by CloudHealth capabilities and offers an innovation pace and path that Broadcom will never keep up with post-acquisition. Stay tuned for some amazing announcements in the coming weeks on this, as well.

The post Navigating the VMware Acquisition: A Pragmatic Approach to Migration in the Broadcom Era appeared first on CloudBolt Software.