Migration From On-Premise to AWS Cloud

At the beginning of 2019, cloud adoption was one of the key topics on top of my agenda. As such, we started developing a centralized cloud strategy with the objective to use it as the foundation for governing our evolution for the next few years.

“First Things First”

Our cloud strategy included both, the migration of our existing legacy systems as well as building new cloud-native Microservices platform.

For the migration of our existing on-premise legacy systems, we have determined what should be in our target environment and the migration strategy for each application. That brought us to adopt a combination of different approaches, in alignment with some of “The 5 R’s” that Gartner outlined in 2011.

My focus in this article is around the re-platforming approach (lift, tinker and shift)

Design. Design. Design. Migrate. Validate. Repeat. Cutover. Operate.

In summary this is how we did it and I believe this simple approach increased our chances of success.

Design. Design. Design.

Choose the Right Candidate

We had few critical business applications falling under the re-platforming option, and for us there were a few candidate applications to migrate first because of what the benefits migration can bring to business in terms of availability, security, performance and other factors.

We knew that for the first migration, we have to choose the right candidate for POC and pilot testing. When we started, the rule of thumb was to choose an application that is:

• the easiest to migrate,
• the most likely to fulfill the criteria of success,
• and the least prone to failure.

However, in our case what actually happened was different. we started with the applications that were the most business-critical and which had the biggest impact on business. We realized that we had to move fast with these applications when we experienced a major data center outage and for an entire day we could not serve our users and our business partners. That is when we decided that we have to move these business-critical applications in the cloud-first and we have to move them fast.

Choose the Right Cloud Platform

We chose Amazon Web Services (AWS) as our cloud provider because it provided us with the greatest scale and the broadest set of services and features. I will take you through the key reasons why we chose to move to AWS cloud.

• Their global footprint and high availability in each region
• We pay only for the compute power, storage, and other resources we use.
• Better performance and response time for hardware and software
• Opportunity to upgrade security, with an end-to-end approach to secure and harden our infrastructure.
• Opportunity to re-architect our solutions in the cloud and have access to agility to transform our solutions into cloud-native architecture.
• Having 95% of our systems on Oracle DB, it was an important factor in moving into RDS the AWS managed DB workloads.
• On AWS we can define the infrastructure as code using cloud formation and other tools
• We can spin-off environments in minutes and We can do that with no capex
• It allows us to automate CI/CD with less effort and following best practices giving simpler deployment process with higher availability and security.
• Using AWS tools allow us to have auto Scaling, and Elastic Load Balancing, based on demand.

Create a Migration-to-the-Cloud Cross-functional Team

You will never succeed without the right team. We have assembled an agile and cross-functional team, that is involved in all migration iterations from day one. The team we have put together included representatives from:

• Cloud Architecture and DevOps
• Applications Architecture
• Development from each impacted application
• IT/Operations from each impacted solution
• Test team
• On-premise infrastructure and Network teams including DB Administration and Security
• Products Owners from each impacted Application

Migrating to the cloud is an iterative process. Keep in mind that something can go wrong first time, so the team needs to be prepared for multiple iterations and must adapt quickly and continuously with changes in the approach.

Define the Cloud Target Architecture

Our legacy applications were monolithic, we had to re-architect them considering the cloud. We checked the present and historical performance data to make sure we provide enough CPU, memory, and IOPS.

We took the decision to use AWS RDS for Oracle as option to migrate our Oracle workload. Mainly for the following reasons:

• RDS is a fully managed solution and it lets us focus on the high value activities to our business.
• RDS manages all the time consuming DB management, provisioning patching etc.
• Focus on high level tuning tasks and schema optimization
• Lower the dependency on in-house managing databases
• We can deploy multiple editions of oracle in minutes with this approach

Design the New Process

We had to adapt the existing development processes to the cloud, as well as define new ones to cover the end to end CI/CD.

Migrate. Validate. Repeat

Define the Migration Approach

If you are familiar with AWS principles and best practices, you will immediately recognise the phases we have followed.

• Discovery phase, in which we had overall assessment of the application requirements, infrastructure, DB links and integration points with the rest of the applications.
• Migration path and timelines: after the assessment we confirmed our approach and timelines for the candidate application. Our overall target was to perform the POC reiterations and the migration within 8 weeks.
• Then we started designing and building what we called the first path.
• Then we did a validation through a POC so we have a very precise idea of what we will encounter when we migrate the entire applications. What problems we are going to be facing, what issues we will encounter in the first round and so on. In this step we really understand the interfaces dependencies, we simulate the backups and the restorations etc…
• After that, we have used the run book to perform few reiterations and simulate end to end migration. In our case we have performed 4 iterations before the cutover. This helped us to finetune the migration run book and ensure all team members are comfortable with their test at the cutover time.
• At the end of that phase we were able to build our full cutover plan, with timing, technical steps and roles of each team member.

Check Migration Feasibility

A successful migration effort requires not only the development of a comprehensive strategy in support of the migration, but also forces us to make some difficult decisions up front. The most tempting decision is to skip some steps all together and dive right in to migration activities, but that “easy” decision can doom a cloud move to failure. For us, this step was of paramount importance.

• In this stage, we look into factors like dependencies between applications we are migrating and the rest of the applications, its services, identify migration objectives, exact workloads that can be moved to cloud
• In this stage, we prioritized the business and IT requirements to ensure what part of the workload of the application should be moved to the cloud-first.
• At the end of the feasibility check, we have determined the degree of difficulty in on-premise to AWS migration. This also includes enlisting the scope, and effort required, estimating costs, benefits, and agree on the success criteria in order to consider the migration successful.

Perform the Proof of Concept

Once we have closed our feasibility check, and designed our target architecture, one key decision was to identify proof of concept scope and after that, we have built a cloud landing zone with a minimum-viable environment required to run the POC application.

This helped our team to use the POC to run a fast and low-risk study on how best to migrate. Also, after the completion of this POC, we have improved and fine-tuned our migration run book and developed a procedure for the migration.

We did the PoC for almost 6 weeks, during which have done 4 trial runs and iterations, we have tested all interfaces and tested performance.

This is the time to spot & report on anything that can fail during a real migration. Take notes and collect data. It will become your lessons learned in the future.

Plan. Cutover. Operate.

Cutover

Once we’ve done all the previous steps, it was the time to plan and prepare our cutover with detailed runbook and decided to take a downtime of 8 hours. Obviously this was tested and validated in all our POC iterations. Below is a glimpse of our cutover key milestones with clear responsibility assigned for each migration team member:

• Disable all existing jobs
• Complete Oracle database migration — Export and import into AWS RDS
• Verify data post import in RDS — Verify DB links, number of objects and compile the database objects.
• Code Deploy — Deploy the latest code on the AWS environment
• Functional test — Perform Regression test on the major parts of the applications
• Switch DNS — Switch DNS to the new environment
• Post migration test — Perform regression on the post migration application to confirm end of migration
• Enable Database Jobs — Enable pull and push jobs

Before that we have notified business units and the impacted users and provided them with a complete communication plan and post migration business runbook.

Additionally, we have prepared a rollback plan and define the criteria when to roll back. We have decided that if any of the rollback criteria is met within a window of 36 hours post-migration, then a rollback plan should be triggered. In summary our rollback plan looked like this:

• Shutdown the migrated applications — Ensure the applications are shutdown and there is no traffic on the new servers
• Complete database reverse migration — Reverse database migration as export/import from cloud to the old infrastructure.
• Verify database — Verify DB links, number of objects and compile the database objects.
• Switch DNS- Switch DNS back to point to the old environment.

Operate

Migration is only the beginning. You need to plan how to operate your new cloud environment after the migration. Our plan included not only how to monitor and troubleshoot and backup it, but also how we will improve performance and optimize cost.

With the tools and future that AWS provides, we are realizing the benefits of this migration to the cloud. We are able to use cloudwatch to monitor everything which is giving us a lot of metrics.

In Conclusion

Moving to the cloud has brought a number of immediate benefits. It was challenging, but we have the right team to make the move.

Now we have a much more scalable solution, we rely on AWS for all of our scalable computing and storage needs. AWS cloud also allowed us to significantly increase our service availability and performance. Although, cost reduction was not the main reason we decided to move the core business applications to the cloud. However, after one month we can already estimate how our cloud costs will be clearly lower of those in the data center — a welcome side-benefit.