In 2021, our client requested Autoverse move their DB2 HADR clusters and applications from IBM's cloud to AWS with a hard deadline of one year. They had over 200 DB2 HADR clusters which served 3 specific applications around the globe. A methodical and automated solution needed to be devised in order to complete this project on time.
With a hard project deadline in place, migration assessment and deep dive into our client's application and database framework began right away. Our migration assessment is aligned with the AWS Cloud Adoption Framework, which identifies key information based on six organizational perspectives. These perspectives are: business, people, Governance (non-technical) and platform, security, operations (technical). Full day migration workshops were planned at project onset and determined the following:
Align with Leadership
Determine Decision Interdependency
Identify Gaps and Readiness
Uncover Friction Points
Clarify Objectives and Requirements
Determine Systems, Applications and Environments
Determine Security Standards
Identification of Best Practices
After the migration assessment was completed, we worked with their team to get detailed information on each of the IBM DB2 Clusters involved in this migration effort. The Acoustic team provided a detailed listing of each server, IBM DB2 version and specific HADR information. We also requested performance monitoring output which was aggregated over a full year. Server resource consumption was greatly affected by Black Friday and Boxing Day sales, having performance information for a full year allowed us to correctly right-size these IBM DB2 HADR clusters. With detailed server information and our migration assessment we created a detailed project plan which included:
Clear Action Plan and Architectural Diagrams
Statement of Work and RACI Matrix
Defined Decision Makers and Method of Approvals
Resource Requirements and Team Build
After our project plan was evaluated and approved by stakeholders we started to work on deployment scripts and automation. Our goal was to automate as much of the DB2 HADR deployment process as possible. Deployment scripts created both EC2 instances, installed all software, setup DB2 configuration and restored the latest backup that was located in S3. Our scripts even automated the process of connecting the HADR between both EC2 instances that were created on AWS. This was accomplished by uploading specific files for each deployment to S3 and having the bootstrap scripts wait until this file is created in order to proceed. Our automation scripts provided an end-to-end deployment for creating IBM DB2 HADR in AWS. Deployment of 200+ IBM DB2 instances can now be accomplished easily by passing parameter files for each cluster to our automation scripts.
Once all infrastructure was deployed, it was time to start near real-time replication of data from on-premise systems into AWS. Our deployment scripts required that an offline full backup of each IBM DB2 database be uploaded to S3 and this backup was restored with our automated process. Our automation scripts also setup HADR from the primary DB2 instance in AWS to the secondary EC2 in AWS, this ensured that all networking and connections are tested and confirmed working prior to migration. To set up near real-time replication from on-premise system to AWS our database team had to login to the IBM DB2 primary instance and stop HADR replication within AWS, restore the same backup that was located in S3, but this time they will create a HADR connection with the on-premise server to the server located in AWS. The AWS IBM DB2 instance will now play the role of the secondary instance until migration cutover.
Once near real-time replication was enabled, it was time to plan for migration cutover. Cutover plans were created in conjunction with the application team with a step-by-step action plan. All details of whom, what and when of each step to be completed were included. Migration of IBM DB2 into AWS required us to perform a "TAKEOVER" which essentially switched the primary server located on-premise to the server located on AWS. At this point, we stopped HADR replication from between on-premise and AWS, took an offline backup of the AWS DB2 database and uploaded it S3. We then notified the application team to switch application database connection to this new system. While the application team was changing their configuration, we restored the latest backup to the secondary IBM DB2 server in AWS and re-established HADR connection within AWS. Re-establishment of this HADR connection marked the final step for migration.
The result of this migration was a huge success, and we were able to migrate 200+ IBM DB2 instances to AWS within the 1-year time restriction. Our solid and innovative automation scripts proved to be worth the time and effort and was the sole reason this project was completed on time. Furthermore, with so many servers and so many environments, our cutover plan was executed and modified with lessons learned many times. When it was time to migration production servers, the cutover was seamless and everyone on each of the teams knew exactly what to do and when.
The greatest challenge with this migration was that it was global. Our client had IBM DB2 clusters in Europe, India, Australia and China. Cutover needed to be planned during off hours of each system, which resulted in many sleepless nights and many overtime hours, which presented a risk as the team was exhausted. For our next global cutover, it will be advised to obtain a few more short term resources for cutovers in UAT, QA and Production.