Workload Migration Methodology

Migration Methodology Overview:

This blog is intended to provide a high-level overview of typical Workload migration methodology and process flow using lift and shift migration strategy.

When we engage with any customer in their modernization journey by addressing their concerns and queries for migrating the applications and workloads, we provide our consultative inputs and provide assessments reports with our proven methodologies and migration expertise.

In any given Workload Migration Engagement there are 3 important key phases which play a vital role for the project success.

• Discovery Phase
• Analysis & Planning Phase
• Execution Phase

1. Discovery Phase:

There are 2 ways of performing discovery of customer environment.

• Automated Discovery – Using any discovery & assessment tool.
• Manual Discovery – Existing customer CMDB, RV Tools and by conducting more Application & Infrastructure workshops.

During this phase of engagement, ideally consultants/vendors would perform an inventory discovery and application dependency mapping using various discovery tools which are available in the global market (VMware Aria operations for Network, Device42, DTM, etc.)

Below are the key tasks which would be performed during this phase:

• Collection of Discovery Data
• Physical inventory and assets
• Baseline Data and Workshops

During this process, initially any of the assessment tool would be deployed in the customer on premises environment to collect meta data of the VM.

In our use case, let’s consider VMware Aria operations for Network for Assessment as a Discovery & App dependency tool.

We have deployed 2 VM’s as part of VMware Aria operations for Network formerly vRNI (Platform & Proxy/Collector) VM’s. Platform VM’s provides the UI with dashboard, metrics, micro segmentation recommendation, VM – VM communication path and lot others.

Collector/Proxy VM doesn’t store any data wherein it collects the flow data from vSphere Distributed Switch once the IPFIX is enabled on vDS. Once these 2 appliances are successfully deployed, we would add vCenter as a data source into vRNI to collect meta data of the objects from vCenter.

It is always recommended to have the vRNI data collection runs for 2 weeks to analyze good amount of data.

2. Analysis & Planning Phase:

During this phase of engagement, consultants/vendors would perform discovery validation, analyze the data, identify the gaps and dependencies and build the move bundles for each migration move events.

In our use case, we used the flow data which is already collected using vRNI to perform data analysis and application dependency mapping. If Flow based Application Discovery (FBAD) is already available as part of Enterprise license feature, it discovers application groups based on flow data or network communication between VMs. That would be further classified into 3 different categories (High/Medium/Low) based on deterministic or good number flows. If FBAD unable to classify them into any of applications, then they become unclassified VM’s.

Note: If a customer is using Advance license of VRNI, then we may have to create application sets manually to perform application dependency and mapping between VM’s.

Once we extract the flow data from vRNI, below are the key tasks which would be performed during this phase:

• Validate the discovered data and identify the dependent groups.
• Perform bundling workshop with customer stakeholders.
• Identify the appropriate migration type and build strategy for the workloads depending on the characteristics of workload.
• Identify and align migration wave for each dependent group.
• Create runbooks for each migration wave.
• Schedule meetings for respective migration waves
• Collect the required documentation from application teams to be captured into runbook.

3. Execution Phase:

During this phase of engagement, a team of migration engineers would perform migration execution by leveraging various migration tools which are available in the global market (HCX, Zerto, Doubletake etc.)

Execution Phase is composed with 3 parts as shown below:

In our use case, we used HCX to migrate VM’s and to stretch Layer 2 broadcast domain so that customer would retain the same IP schema in all the VM’s and associated applications on the target landing zone.

HCX components would be deployed on the source and target environment to provide hybridity mobility and seamless migrations. All the Management and Data plane components would be configured to communicate internally and across the environments for data replication and layer 2 stretch using a secured IPsec tunnels created by each appliance. The following figure below gives us detailed information about different migration types supported by HCX, which customer could chose based on the business criticality and downtime.

Below are the key tasks which would be performed during this phase:

• Pilot Migration (Choose some low hanging fruits/non-critical applications and perform a dry run to understand any underlying issues, showcase tool capability and boost confidence to the customer
• Pre-Migration activities (Validate access to source and target environments, Pre-clones, Resources availability, Base replication etc.)
• Migration activities (Perform cutover/switchover of a VM, Monitor and report progress, UAT etc.)
• Post-Migration activities (Migration event sign off, Lessons Learnt etc.)

This is how we assist our customers during complex workload migrations and help them to perform seamless migration with workload mobility and security by leveraging industry best class migration tools.

Happy Learning!