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.



