Cloud/ Datacenter Migration Data Gathering

According to my experience, Datacenter/ Cloud migration projects are one of the challenging and painful projects. Technically, actual server migration is not complicated, but Application dependencies on other apps or infrastructure components (SMTP, LDAP, Exchange, Load balancers, etc.) makes tough with respect to the planning of migration (schedule). The success of the migration depends on what level of data is available about a particular server/application and how you are capturing the details and migration schedule. To take an informed decision about when to migrate a particular server/ application, all application/ server needs to be available.

In this article, I would like to list the information which you need to capture for each server to plan and migrate the server to other data center or your favourite Cloud platform (like your private Cloud (Infrastructure as a Service), Microsoft Azure, AWS, Rackspace, Google, etc.) Even though I have listed some possible information to capture but all of it may not be required for your project based on migration scenario/ environment.

Some of the following details need to be captured for source and target environments if you are planning to change the server configuration in target platform or target platform is different to source platform (for example, VMware to Hyper-V, physical to virtual, virtual to Cloud migrations). Again what data you capture also depends on whether the server is virtual or physical, type of target platform (the type of cloud, datacentre etc.) and migration tool (manual provision of target server vs automatic provisioning).

Data Gathering Item	Description/ Justification to capture the item
Host/ Server Name	It’s obvious that you need to know the server name you are planning to migrate J
Server Description	Server function/ description
Server Operating system (Windows xx, Redhat Linux. Ubuntu etc.)	This helps to understand the OS version and the migration method/approach
Physical/ virtual?	This helps to identify the migration method/approach
Source/ target hypervisor	Source and target hypervisor needs to captured if the server is virtual as if you are moving from one hypervisor o other, management tools needs to be updated
IP addresses	Capture all assigned IPs to a particular server. In some cases, you need
VLAN	VLAN ID where the server is hosted at the moment. This is required if you are planning to re-IP VM as part of the migration
Number of CPUs (Virtual or physical)	To plan target CPUs if  you intend to change hardware config
Memory size (in GBs)	To plan target memory size if  you intend to change hardware config
Number of NICs and their IPs	If you need to reconfigure target VMs in advance, you need to know the number of NICs to provision
Number of hard disks and sizes	If you need to reconfigure target VMs in advance, you need to know the number of hard disks to provision. Refer to some Tips how to reduce Cloud costs after migration
Storage tier (Tier 1, 2, 3 etc.)	To map the target VM to one of the Cloud storage tiers in the target platform.
VM/ application/ database backup schedule	To ensure that VM/ application can be configured with the same backup schedule as it is in the source environment
VM/Application support hours	Based on app/server support hours, migration can be scheduled after hours
Site/ DC name	The physical location of the server
Application name	Application name- which helps to create migration server groups based on the application name
Application/Server owner	App/ server owner to whom migration team has to contact for migration window, test plans etc.
Application/Server environment (Prod/dev/Test)	To classify the server or application based on prod vs non-prod
Is application configured for High Availability within site	If yes, you can migrate one set of servers at a time to avoid impact to end-users
Is application configured for Active Disaster Recovery	If yes, you can migrate one set of servers at a time to avoid impact to end-users
Is Server configured as part of the Microsoft Failover Cluster	If yes, the migration strategy/ method is different from a standalone server. And also need to ensure that the target platform supports MS failover clusters
Any licensing dependency of application of infrastructure (MAC address, Number CPUs etc.)	To plan and schedule application licensing reconfiguration after migration if there is any licensing dependency on infrastructure
Migration tool/ method (Platespin, DoubleTake, OVF export etc…)	To plan the number of migration tool licenses or effort.
Any VM/ Application dependency/ association with public IP	To plan any configuration changes required as part of the server migration
Is server configured to pick IP from DHCP?	If yes, need to plan the DHCP configuration or assign static IP as part of the migration.

There are a number of tools available in the market to capture the application dependencies. Some of them are. You may have an existing investment in one of the tools so you can leverage existing licensing.

-          ADDM – Application Discovery and Dependency Mapping tool from BMC and also from ManageEngine

-          Server and application monitor form Solarwinds

-          Application Dependency Mapping from ServiceNow

Refer to this article for the list of operating system related test cases post Azure/ AWS cloud migration. 

Please share on social media if you found this post helpful. If you have a comment or question, please post and add your voice to the conversation.