ASSESSMENT AND MIGRATION CANDIDATES
Criticality Criteria
Network Criteria and Impacts Storage Criteria
Server inter-dependencies
SYSTEM STABILITY
APPLICATION AND DATA MAINTENANCE
Disk Cleanup
Application Licensing
Operating System and Application Upgrades
MIGRATION CONSIDERATIONS
SERVER LEVEL MIGRATION
SYNCHRONIZATION CONSIDERATION
Maintenance Windows Rollback PlanAPPLICATION CONSIDERATIONS
Application Assessment Application Functionality Hardware DependanciesCustomer Requirements and Impacts Application Upgrades
Windows Based Applications and Services Active Directory Domain Services
Joining Windows Target to Domain Controller
3
3
3
4
4
5
5
5
5
5
5
6
6
6
6
7
7
7
7
7
7
8
8
8
CONTENTS
ASSESSMENT AND MIGRATION CANDIDATES
CRITICALITY CRITERIA
NETWORK CRITERIA AND IMPACTS
Prior to moving workloads out of a local datacenter, it is important to assess the applications, data, workflow, and user impact.
After this assessment, the scope of the migration project can be set and you can identify the servers that can be migrated.
The source servers for migration into the cloud need to be assessed for suitability in the target cloud. In addition to suitability there are a number of additional factors such as order, function and criticality. For example: a specific source server may need to be migrated before dependent source-servers are migrated to the cloud.
Assessing the server candidates may depend on one or more of the following criteria: A. Data criteria
1. Stores confidential non-public information on individuals
2. Stores other legally protected, contractually protected or nonpublic data B. Level of impact if server becomes unavailable
1. How will your server be affected if it is brought down? 2. Will it affect a group, department or corporate? 3. Other important mission-related functions C. Additional criteria
1. Important software applications 2. Large number of users
3. Financial liability
4. Impact upon the reputation of your enterprise
During the workload relocation process, all the data from the server can be collected and transferred via a SaaS-based solution for processing and deployment to the target environment. During the collection phase for migration, a large amount of data will be transferred and it is important to have adequate available bandwidth to support both daily business operations and the transfer of data. The amount of time taken to complete the collection process will be dependent on the bandwidth available and amount of data transferred.
• Network bandwidth considerations should be taken into account prior to initiating a migration. • The number of NICs present on the source server and how they translate to vNICs in the target
Analysis of current networking requirements including but not limited to, network address translation (NAT), load balancing, and firewall configurations for applications and services should be performed. The results of this analysis will enable the correct networking set up on the target platform.
Most enterprise data centers topologies today exhibit the following characteristics: • High number of virtual servers and virtualized storage
• Storage from multiple vendors coexisting in data centers • Multiple data-centers spread out across long distances
• Over-allocation of storage capacity to cover worst-case scenarios.
Storage configurations and requirements to be considered as part of your migration solution’s plan and prep phase include:
• Storage protocols used in source (NAS or SAN) • Fiber Channel (8Gb, 4Gb, 2Gb)
• iSCSI (10GbE, 1GbE) or Fiber Channel over Ethernet (FCoE).
It is important to assess the requirements and current configurations to ensure operability once a server has been migrated.
Your migration solution should not move or remap NAS/DAS storage on the source/target servers. If NAS/DAS is required in the target environment it will need to be moved and reattached outside of the migration process.
As part of the planning for migration to Cloud, the inter-dependencies of servers must be considered before the migrations can begin. If there is a cluster of servers offering a specific service, it has to be carefully planned how they are migrated. Does the cluster migration require sequential or a parallel migration?
This hierarchical sequence of migrating servers will help in establishing the service from the target cloud platform.
NOTE: Internal networks often use private-range IP addresses. It may be possible to easily duplicate the source network environment in the target environment - resulting in minimum number of changes
downstream systems.
• Verification of the source servers’ networking requirements is also important.
STORAGE CRITERIA
It is highly recommended that the source server and applications are stable prior to initiating your migration solution process. Server and application stability will ensure that business operations can continue while the migration process is running. This will also help ensure that the migration process completes successfully. If there are known system and/or application instabilities, they should be addressed prior to initiating the migration process.
It is further recommended that the order in which the servers are migrated be given careful consideration in case of any hierarchical dependencies.
SYSTEM STABILITY
APPLICATION AND DATA MAINTENANCE
MIGRATION CONSIDERATIONS
During the migration process, a collection phase will capture all data stored on the source system. To reduce the overall time for the migration process to complete, remove any data or applications that are not needed prior to initiating the migration. This will reduce your storage footprint in the target environment, which may reduce costs.
Review application terms-of-use and licensing agreements. During the migration process application licenses must be up to date. Extensions may be required for legacy and integration software. Software licenses should be renewed or sunset accordingly since the legacy platform must remain operational long enough to complete all migration phases.
Your migration solution should be SaaS and do an as-is migration (with the exception of drivers) and should not upgrade the Operating System or applications versions during the migration process. Depending on the target destination, there may be specific requirements for the Operating System version. In this scenario, the source server must be upgraded prior to beginning the migration process.
A successful migration requires collaboration with the data-center architect/administrator to map out the source-server environment and configuration. A typical migration in a production environment involves multiple servers, each running different applications.
DISK CLEANUP
APPLICATION LICENSING
SYNCHRONIZATION CONSIDERATION
Your migration solution should be designed to relocate applications and databases at a server level. If an application involves software components installed across multiple servers, then the entire set of servers should be migrated.
In scenarios where only a subset of servers are migrated, firewall rules, network access and policies may be required opened up to the non-migrated servers in the legacy environment. It’s not recommended to do this, as it creates complexity in the management and maintenance of network resources and access rules.
Target Booted and Verified
A successful migration requires both the applications and the database running on both source and target servers to be synchronized for final cutover to production. Before your migration solution initiates their synchronization process, the target server in the virtual environment must be successfully booted and verified. The purpose is to reduce the delta between source and target. Using this synchronization method should reduce synchronization time during cutover as described in the next paragraph. Maintenance Mode Boot
The other method is for a final synchronization for cutover to production. In order to carry out this method, both source and target servers need to be rebooted into maintenance mode where only the required system services are started to allow the synchronization process to run. While in this mode, both source and target servers will be unable to provide services to the end users. Therefore it is important to plan a maintenance window with the datacenter administrator and the customer. During this window, the administrator/customer must test all applications/databases on the target server after the final synchronization and before bringing it on-line for the end users.
As part of your migration process, maintenance windows will be necessary for times of synchronization and final cutover. It is important to establish adequate time frames for these processes to complete. In the event of issues during the cutover after a server migration has completed, it is important to have a rollback plan identified and documented. This will allow business activities to resume with minimal interruptions on the legacy systems while the issue in the target environment can be troubleshot and addressed.
MAINTENANCE WINDOWS
ROLLBACK PLAN
APPLICATION CONSIDERATIONS
Your migration solution should relocate systems as a whole. However, the characteristics of the applications running on the servers must be kept in mind while preparing for the migrations. This chapter will highlight key considerations for applications for the migration process.
Some applications are better suited for the cloud environment than others. Carefully assessing which applications are suited for the cloud will help determine which applications should be hosted locally and which can benefit from being hosted in the cloud.
Application Functionality
Understanding the function and the services performed by an application will help determine whether a server should remain local to the datacenter, migrated to a cloud, or a specific cloud if multiple environments exist.
For example, servers that manage backups and store backup data should be situated near the servers that they are servicing. It is not advisable to move the backup server into the cloud to support servers that are in the local data center.
Hardware Dependencies
Some applications require specific hardware to function. In cases where hardware is proprietary to the software vendor, it may not be feasible to migrate the server into the cloud. In other cases, virtual hardware may be available to facilitate the application in the cloud environment. It is important to fully assess the application requirements to ensure no hardware dependencies exist.
Customer Requirements and Impacts
It is important to fully understand the customer requirements for a given application before migrating the server into the cloud. Some customers have strict SLA’s or usage requirements to retrieving information and providing data. By understanding the needs and requirements of the customer, an assessment can be made on whether a server can be migrated to the cloud and still meet the requirements and expectations of the user base.
Application Upgrades
Your migration solution should not upgrade software as part of the migration process. If server migration efforts coincide with software upgrades, a decision will need to be made about whether the upgrade should be performed before or after migrating the server to the target environment.
Active Directory Domain Services
A customer with a small datacenter might have redundant domain controllers with active directory service. In some cases, a server might be configured to provide active directory domain services while concurrently running another application and database. It is important to work with the datacenter architect/administrator to prepare a plan to migrate these applications and services. If done incorrectly, the domain controller could become tomb-stoned in the active directory and unable to synchronize. It is recommended that one of the domain controllers be demoted or decommissioned and that a brand new domain controller be installed and provisioned in the virtual environment. Once the new domain controller is synchronized and all the source servers are migrated, decommission the partner domain controller in the legacy environment. Then create a new one in the cloud to revert the configuration back to the original settings.
Joining Windows Target to Domain Controller
Some Windows customers prefer (or are required) to join the migrated target to the same domain controller that the source is joined to. This can be helpful for post-migration application verification and testing. Since the migrated target has the same system identity as the source, it is necessary for the target to obtain a new and unique SID through the Windows sysprep process.
Once applications and system services are verified on the target, a periodic synchronization process can be started to minimize the delta between the servers until a final full synchronization is carried out to bring the target into production.
