This blog comprises of 4 parts:

1. Part 1 – Choosing the cloud provider
2. Part 2 – (This entry) The Challenges
3. Part 3 – Roadmap to migration
4. Part 4 – Learnings

We hope you find this blog useful as you plan migrations to cloud from in-premise and vice-versa. Do reach out to us at [email protected] to help with your migration needs.

Part 2 – The challenges

In part 1 of this blog series, we talked about the reasons to move the enterprise application to AWS. Moving an enterprise application being actively used by hundreds of users poses significant challenges. In this installment we will explore the challenges we faced.

Database

The Primary challenge was the database. The application is built on top of IBM DB2 and since the application is a centralized data mart, the database operations are significant. Given that the application relied on stored procedures for significant features, we ruled out migrating the database from DB2 and confined the project to the overall lift and shift of other services to AWS for Phase 1. 

DB2 community edition was used for our lower environments (Dev and QA) and a third party (Midvision) provisioned DB2 image in AWS marketplace for the production environment.

ETL

Another challenge was ETL. The application used a proprietary solution to achieve data transformation from on-premise systems to the cloud. 

Data was being received at various time intervals – every 5 minutes, hourly, daily from various integrated equipment in the field. The upload mechanism used a combination of kafka streams and proprietary tools to transform data to finally insert it in staging tables for further transformations.

We had to identify a new portable mechanism for this process by replacing the proprietary ETL tools for the new AWS solution.  

External API clients

The application was live with a production environment that served scores of clients that called into the API. Since the application already had clients, the testing and movement of these APIs had to be coordinated with the external clients. This was not without its challenges. The use of proprietary domain names for api endpoints mandated the need to communicate with the callers of the APIs in order to make changes to the URLs. This was a tricky issue that had to be dealt with carefully. 

Additionally, we needed a way to provision a self-service portal for the external clients where they could be invited to manage their API Keys and get a preview of the published API catalog of the product.

The rest of the application was planned to be a lift and shift exercise. We looked for more optimizations like moving the UI deployment to an S3 bucket and setting up CI/CD to bring more agility to the development process. 

The above issues made up for the core of the challenges that we faced while moving an enterprise application to AWS. In the next installment, we will explore the solution we implemented to make the move to AWS.