On-Prem to Azure Migration Journey

Overview: This is a short writeup on the approach taken to migrate a Java-based application into Azure PaaS services. I’d like to share some insights into this journey with some useful tips on how to go about the migration journey.

Migration Phases: As is the normal practice the below diagram outlines the main phases in any cloud migration journey. The Assessment and discovery phase would be the starting point of your journey.

Migration Strategy: Once you have performed your assessment of the client’s existing landscape. You would need to prepare your proposals with the right option for this migration based on the data you collected. Largely your application’s migration will fit into one of the below categories based on various reasons: business/technical/financial. As an architect it is important to perform a full assessment of the existing application on-prem including the costing/infrastructure/usage/security etc.… before proposing the ideal options to the client.

Scenario: Now that we understand the first two phases of the migration journey, let’s deep dive into the actual migration of the client’s application. In my use case, the large retail client was already on a transformation journey from on-prem to cloud for the past couple of years and Azure was the target cloud environment. This application was built on java spring and was not yet upgraded to spring boot, it had a web app and a JMS component and used an Oracle Database. At the time the skills “Java +Azure” was quite limited as AWS was a more popular choice and I found there were little or limited resources to help the Java developers on this journey.

Client Use Case: Regardless, we began our migration activities on the Java Spring application hosted on the two on-prem servers (Oracle DB and web server). The JMS component was created to interface with the in-house message queue system which was on-prem. The message queue system had its road map to the cloud, independent of our migration journey where it would eventually be replaced with Azure Service Bus, which meant our migrated code had to be robust enough to switch over to ASB shortly.

With all these findings and our initial assessments from the requirement-gathering discussions, the below options were proposed to the client.

The client chose Option-2 since they opted to go completely on PaaS services to avoid maintenance and optimize costs while having as little impact on the existing application setup. The overall architecture is outlined below.

Our Assumptions:

1. A POC needs to be performed for ICC message queue connectivity to Azure from On-Prem
2. Active Directory had been already extended at an organizational level and was reachable from the Cloud environment.
3. Communication with the on-premises environment would be done via ExpressRoute which was already existing.
4. Maintenance standards are well-defined for Azure (patching, monitoring, backups, AV, etc.)
5. PaaS services would use private endpoints for communication wherever possible with no public exposure.

Our Impact Analysis & Heat Map:

Challenges we Encountered:

1. DB Migration to SQL PaaS: This was easily accomplished with the SSMA (SQL Server Migration Assistant) tool, however, the Java code base had minor changes to existing queries and connection logic which required some careful testing and validations so that all scenarios were covered, and DB migration plan updated to prepare for DB switch over to Azure PaaS. Understanding the breadth of impact of the DB migration from Oracle to SQL Paas is crucial because some of Oracle’s features might not be supported so analyze it beforehand.
2. Lack of skills on “Java + Azure PaaS”: Since there were minor upgrades to the existing code base, this proved to be a major blocker at times due to the issues the team faced while troubleshooting Java on Azure and getting the code cloud ready. Removing all secrets in the config files and moving them to Azure Key Vault. Developers need to be familiar with essential features like integrating with Key Vault, Azure AD, and connecting to the SQL PaaS Database. In our case, this part of the modernization process took quite some time due to the lack of skills.
3. CICD using Azure DevOps: Introducing the development team to CICD with Azure DevOps also proved to be a bit challenging, as developers had to learn to work with YAML files to configure some of the attributes to the app service dynamically via the pipelines.
4. On-Prem Connectivity Testing: This was more of a logistical issue than a technical one as it involved a lot of collaboration with different teams like cloud operations, networking, and on-prem services. So having a good integration & performance test plan with all concerned teams is crucial to finalizing the GOLIVE dates.
5. Cloud Operations & Maintenance: This was a new area for the team to get familiarized as now some of the operational responsibilities fell upon the development team. So, understanding the app insights metrics and setting up the right alerts to cost and performance required some time to adjust. Code scan alerts were integrated with teams giving more visibility to the development teams on issues and vulnerabilities in their code. Refining the alerts and monitoring dashboards is an ongoing process over some time the team would learn to use and monitor relevant metrics.
6. Cutover planning & GOLIVE: The preparations leading up to D-Day was as important as the entire migration efforts. It involved several teams collaborating and performing the cutover seamlessly with zero impact on end users.

The Outcome:

1. The total time taken for this migration was about 3 months.
2. DB Migration from “Oracle on-prem” to “Azure SQL PaaS” was done seamlessly with the help of SSMA.
3. Java Web applications were upgraded and deployed into Azure App Service.
4. All Azure Resources were pre-remediated as per Client defined security standards.
5. Achieved cost efficiency by optimizing PaaS and also regulated usage of lower environments.
6. Introduced automated deployments using Azure CI/CD Pipelines and IaC using Terraform.
7. Used Azure App Service’s Blue/Green deployment feature for zero downtime during releases.
8. Set up monitoring dashboards and alerts both at the application level and infrastructure level.
9. Access was restricted to intranet users using single sign-on integrated with Azure AD and connectivity was restricted using networking and whitelisting of company zScaler IP addresses preventing any unauthorized access to the apps since private endpoint connectivity with on-prem was not fully enabled within the company at the time.

Lessons Learnt

1. The developers need to have strong technical skills in their respective tech stack even though their cloud knowledge is limited.
2. Developers should be able to easily adapt to new processes like DevOps, logging, monitoring, etc.…
3. Cloud learning and certifications helped upgrade the skills of developers when they are new to this.
4. Teams need to be collaborative and well-connected during the journey to spot showstoppers early on and be able to mitigate them in time.
5. Extensive testing is required to ensure that migrated code is working as expected and avoid last-minute surprises.
6. A good documentation process will help newer resources to catch up sooner.

Finally last but not least I would like to add that in this current era of cloud computing as a developer you no longer have the luxury of being a specialist in your respective technologies alone, but you also need to have the knowledge and hands-on exposure to DevOps and the basics of cloud infrastructure. So, if you are a developer and have not yet gotten a chance to work on cloud technologies, then I strongly suggest you start with the foundational courses & certifications on cloud and DevOps.

For Azure learning do check out Microsoft Learn: Build Skills that open doors in your career.

About Me

I am a Sr Azure Cloud Architect with an experience of over 18 years in IT. I have performed various roles. I started my career as an ASP/C# developer. I have worked as a technical lead/manager, scrum master, solution architect, DevOps engineer, and Architect.

Connect with me @ https://www.linkedin.com/in/elmasimons