Because the OS / Platforms were different for each application , we needed two separate migration approaches .
Because the OS / Platforms were different for each application , we needed two separate migration approaches .
a new instance using older legacy versions of the apps and , more importantly , the complexity of configuring the various components to mimic the existing production systems .
We determined that cloning servers similar to the “ lift and shift ” approach would be better than Greenfield installs . Because the OS / Platforms were different for each application , we needed a different approach for each migration .
We conducted a detailed portfolio analysis to identify all end points and dependencies for each of the applications . The following breakdown describes the unique challenges and how they were addressed .
Application 1 Challenges
• Domain trust and computer passwords
In an Active Directory environment , Windows servers use various mechanisms for mutual authentication , including a unique SID per server and a computer password update mechanism . The passwords are updated on a regular basis and the Domain Controller allows or denies access . Because we wanted upfront time to prepare the servers in AWS , we used a group policy to temporarily disable the password update mechanism to avoid Domain Trust issues .
In our testing we also found that the AWS ELBs were not suitable for this application due to a URL redirect , incompatibility with CNAMEs , and SPN requirements . We used a Linux based load balancer with HAProxy and keepalived for clustering .
Application 2 Challenges
• Legacy applications and websites
• Lack of configuration documentation
• Hardcoded IP addresses
• Lack of documentation and knowledge of various scripts
All the content that was served by the application was hosted on a Netapp storage appliance using NFS . The content size was in TBs , and we had to make sure it all was seeded , synced , and available in AWS for the migration . We used an NAS Virtual Appliance as an NFS server in AWS , and used rsync to seed and constantly sync the content . Because the content was mainly write once and read , the time it took for the initial sync was much longer compared to the incremental syncs that were regularly done right up to the migration window .
The application also relied on URL redirects at the load balancer level . Therefore , AWS ELBs could not be used . Similar to Application 1 , we used a Linux based load balancer with HAProxy and keepalived for clustering .
Migration Approach
At a high-level , the lift-and-shift migration included replicating the servers to AWS using a disk replication product , backing up the database and then restoring it in AWS onto a Greenfield database server . During the migration
10 | THE DOPPLER | SPRING 2016