birds migrating in the clouds Getty Images

How to Leverage Your VMware Migration to Redesign Your Infrastructure Architecture

If migrating from VMware, consider doing more than a "mere migration." Instead, consider accomplishing your long-term objectives through an infrastructure redesign.

You've chosen to migrate from VMware. Now you need to decide exactly how to do it.

One approach is simply to migrate to an alternative platform that lets you run virtual machines (VMs) in the same way you did with VMware, except using a different hypervisor.

Another is to think more creatively by re-evaluating your entire infrastructure and workload strategy. This is more effort, but it may deliver greater value in the long run.

This article explores that latter VMware migration option. It explains why you might want to treat VMware migration as an opportunity to redesign your infrastructure strategy, and how to do it.

'Mere Migration' vs. Infrastructure Redesign

To start, let's say a bit more about the two types of VMware migration options described above.

The first option is what you might call "mere migration." It involves simply taking the VMs you currently have running in VMware and moving them to a different hypervisor. You'd have to learn some new tools, and you might have to convert VMs to a different format. But you wouldn't be making major changes to the way your infrastructure is designed or how your workloads operate.

The other approach could be labeled infrastructure redesign. If you take this route, you don't simply lift and shift your VMs into a different hypervisor using the same type of infrastructure. You might instead move on-premises VMs into the cloud. Or you could evolve into a hybrid cloud model where some VMs run on-prem while others are hosted in the cloud, all the while being managed through a central control plane. 

Turning VMware Migration Into an Opportunity

Redesigning your infrastructure as part of VMware requires more work than simply lifting and shifting VMs into a VMware-like platform, of course. So why would you opt for this route? The main reason is that it's a way to turn what would otherwise be an obligation into an opportunity.

If you're like many folks considering migrating away from VMware, you're probably doing so in a reactive instead of proactive way. You're concerned about what VMware's acquisition by Broadcom may mean for the VMware products and platforms you use, and so you feel forced to migrate to an alternative.

But what if, instead, you embraced VMware migration as a proactive way to improve the efficiency or scalability of your infrastructure? That's arguably the healthier approach to VMware migration. Businesses shouldn't view migration as a retreat from a platform they've used for years; they should envision it as an opportunity to build an even better infrastructure strategy.

Ways to Redesign Your Infrastructure During Migration

Now that we've gone over why you might want to redesign your infrastructure architecture as part of a VMware migration process, let's talk about how you do that.

Step 1: Identify a new infrastructure model

The first step is deciding which type of infrastructure architecture to migrate to. Do you want to get all of your VMs into the cloud so you no longer have to manage on-prem infrastructure? Is your goal to implement a hybrid cloud so you have more flexibility about where workloads run?

Or maybe you want to make an even bigger change, like refactoring your VM-based apps so they can run as microservices on a platform like Kubernetes — which you could also deploy both on-prem or in the cloud, but which would give you more scalability than you'd get from conventional on-prem or cloud-based infrastructure.

Step 2: Acquire infrastructure

Next, you need to acquire the actual infrastructure to support the new type of setup you intend to build. If you're moving into the public cloud, infrastructure acquisition may be as simple as deploying new VMs using a service such as Amazon EC2 or Azure Virtual Machines. Alternatively, if some or all of your workloads will remain on-prem, you'll want to make sure you have adequate servers to support them.

Step 3: Implement a control plane

Before migrating workloads, you'll likely want to build a control plane that will allow you to manage your new environment in an efficient way. Ideally, the control plane will be centralized so that it can support all parts of your new architecture.

If you're shifting to a hybrid architecture, one way to implement a central control plane is using cloud vendors' hybrid cloud services, such as AWS Outposts or Azure Stack. An alternative is to adopt a third-party vendor offering like Nutanix NC2, which gives you a control plane that is not linked to a particular cloud platform.

Step 4: Complete your migration

Finally, move your actual workloads. The details of the migration process will vary depending on which new environment or infrastructure setup you're targeting, and migration can be a lot of work if you have to move each VM separately. However, it's likely that the vendor you've chosen to provide your control plane offers migration tools for moving VMware workloads into their platform, which can simplify migration in many cases.

Conclusion: A Proactive Approach to VMware Migration

Ultimately, migrating from VMware (or any platform, for that matter) shouldn't only address the challenges you face today. You should also think about your longer-term goals, and how migration can serve them. Treat migration as a way to add new value, not just keep doing what you were already doing.

About the author

Christopher Tozzi headshotChristopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish