Migrations

This is a migration post with a slight change of viewpoint. I’m not going to write about how to migrate a vSphere environment from the infrastructure perspective, there is lots of very good content that covers how to migrate to vSphere 6.5.

This is the first post in a series that I’m going to write about migrations from the point of view of the most important assets, the virtual machines themselves.

Discovery

Every environment is different, every virtual machine is configured to support business needs.  There is never going to be a single blanket approach that will cover every single migration type.  Assigning a migration approach to virtual and physical assets begins with discovery.

These are hard yards, shortcuts cannot be taken.  From a simple technical standpoint discovery is straight forward, what OS’ are installed, what are the CPU, RAM and Storage configurations, what networks are connected, what software is installed and what services are running.

The software and services discovery elements should also include analysis of the application to identify how applications hang together.  Is an application monolithic? Is the data decoupled?

Discovery also needs to consider technical dependencies between devices and consider what the business impact is on those dependencies.  You need to be able to answer the question, if I move device X what is the impact on other devices, and what is the impact on the services that those devices support?  When I migrate device X will the business services offered from other devices still function?

Migration Types

There are many different migration options available to be applied to devices, a few are captured below

Device to Cloud

There has been a lot of focus on the cloud, and the business benefits and economies that cloud adoption can bring.  There are many different cloud options available when considering cloud migration.

IaaS

Effectively replicating a VM approach, migrating to a cloud IaaS service is the most straight forward.

PaaS

Identifying and extracting an application from the OS’ and reconfiguring it to run it on platform as a service.  There are PaaS options for databases, functions and webservices.  Depending on the resource available, it is also a viable option to break down existing applications to functions and adopt a micro service architecture.

SaaS

Perhaps through discovery a service is identified and being internally hosted, that can be hosted using a SaaS model.

Virtual to Virtual

A migration approach that could encompass utilising tools to migrate between different vSphere platforms, or indeed using native commands and utilities to move between platforms.

Physical to Virtual

The P2V approach is where discovery identifies that a physical server can be transformed into a virtual machine.  Many tools exist in the marketplace to perform this conversion.

Physical to Physical

For myriad reasons during discovery it might be identified that a machine cannot be virtualised. In this case again many tools exist in the marketplace to perform this conversion.  In many cases the same tool that performs a V2V can be utilised to perform a P2P

Do Nothing

Do nothing is always an approach.  Perhaps the data gathered and analysed highlights that a workload is so intrinsically linked into the environment it is resident in, that it cannot be moved or cannot be decoupled from the hardware that it is running on.

Over the coming weeks I’ll take some time to expand upon each of these methods, but for now I’ll leave it short and sweet.

Thanks

Simon