AWS launched Amazon Database Migration Accelerator (Amazon DMA) to accelerate your journey to AWS Databases and Analytics services and achieve cloud adoption benefits such as cost savings and performance improvements. In this post, we share how the Amazon DMA team helped a-tune accelerate their migrations to AWS Databases and Analytics services.
a-tune offers data and compliance management solutions through their flagship product tick@lab for research-driven organizations across academia, pharmaceutical, biotechnology, and public and government research organizations. tick@lab is used by over 140 research institutions in 23 countries. a-tune wanted to explore options for alternative databases and understand the pros and cons of feasible future state architectures, migration scope, challenges, and effort required to move to the chosen future state architecture. The Amazon DMA team offered complementary advisory services to address a-tune’s requirements and created a migration strategy and implementation plans to accelerate their AWS migration journey.
“Our tick@lab application supports many, partially complex business processes,” says Andreas Staubi, CEO of a-tune. “In consequence, there is a significant number of different modules providing a lot of functionality. The database structure is quite extensive and includes some complexity. The Amazon DMA team did an amazing job digging into our architecture, application, and code. Within weeks, they not only understood but analyzed it to the very bottom of the stack. Communication about issues and solutions were great, and the very comprehensive report is a great basis for our future planning. Thanks to the Amazon DMA team for this great support!”
In this post, we discuss the approach used by the Amazon DMA team to create the migration strategy and implementation plans for a-tune’s migration.
Migration strategy and implementation plan assessment
The Amazon DMA team used a five-phase approach to create the migration strategy and implementation plans. This included analyzing tick@lab’s current state architecture, creating a future state architecture to meet a-tune’s requirements and goals, analyzing the migration scope and conducting a migration effort estimation, creating a migration design and implementation plan, and creating a production deployment plan. The team conducted multiple information gathering sessions with a-tune to understand their requirements, goals, the workload’s current architecture and characteristics, domain-specific knowledge from existing technical plans and artifacts, and more.
They asked the following questions, among others, about the current state architecture:
Business – What business are you in?
Workload – What is the name of the workload that’s planned to be migrated?
Goal – What are you aiming to accomplish by migrating your workload to AWS?
Architecture – What is the workload’s current architecture?
Dependencies – Does the workload use ETL (extract, transform, and load), reports, and scripts that need to be migrated?
Database – What database technologies and database layer does the workload use?
Application – What technologies does the application layer use?
COTS – Does the workload use any commercial-off-the-shelf (COTS) software?
Database licensing – Are there any existing database license renewals to be considered?
Third-party software – Does the workload use any database platform-specific third-party software?
Tenant – Does the workload use a single-tenant or multi-tenant architecture?
Performance – Are there any key performance metrics that need to be considered in the migrated workload?
Workload size – What is the approximate size of the workload (source code and database)?
Schema – How many database schemas need to be migrated?
Complexity – Are there any known complexities that need to be considered while migrating the workload?
Environment – What environments (dev, test, production) need to be created on AWS after the workload has been migrated?
Sponsorship – Does the planned migration have executive-level sponsorship?
The following are some of the questions asked about the future state architecture:
Vision – What is your vision for migrating their workload to AWS?
Technology preference – Are there any preferred AWS technologies to be considered in the future state architecture?
Infrastructure – Are there specific new or improved business requirements that need to be addressed by the future state architecture?
Acceptance criteria – What metrics are required to measure the acceptance or success of the migrated workload?
Other AWS services – Are there any other AWS services besides the database platform that need to be considered?
DevOps – What DevOps infrastructure do you require to manage the migrated workload?
Migration timelines – When do you plan to migrate the workload?
Migration plan – Do you have an existing migration plan?
The following are examples of questions regarding migration scope and effort estimation:
AWS spend – What is the projected spend on AWS Databases and Analytics services?
Multi-tenant – If the workload uses a multi-tenant architecture, how are the multiple tenants hosted?
Dependencies – Are there any dependencies that need to be migrated?
Instances – How many instances of the workload are expected to be deployed?
Implementation – Who would implement the migration?
The following are questions regarding the migration design and implementation plan:
Testing plan – How do you plan to test the migrated workload?
PII – Does the workload have any personally identifiable information (PII)?
Deployment – How are you planning to deploy the workload (application and database)?
End customer migration – How will your end customers be migrated?
High availability and disaster recovery – What are the workload’s high availability (HA) and disaster recovery (DR) requirements?
The following are questions about the production deployment plan:
Pilot deployment – Are there reasons to conduct limited deployments before deploying the workload at scale?
Testing implementation – What infrastructure and resources do you have to test the migrated workload?
Cutover and fallback plan – How will the system fall back in case of a failed cutover?
Cloud adoption – What is your current level of cloud adoption (low, medium, high)?
Training – How do you plan to train your in-house team (development, operations)?
Migration options
The workload used VB.Net and C# for the application layer and commercial relational databases for the database needs. Amazon DMA conducted a deep dive analysis of the tick@lab workload’s current state architecture and recommended that a-tune refactor the workload’s database layer to migrate away from commercial databases and adopt PostgreSQL. The team created three feasible options with varying levels of high availability, scalability, and multi-Region capabilities.
Migrate to Amazon Relational Database Service (Amazon RDS) for PostgreSQL
In this option, Amazon DMA presented how a-tune can achieve their existing on-premises architecture using Amazon Relational Database Service (Amazon RDS) for PostgreSQL. In addition, this architecture provides the following:
Encryption at rest and in transit
Automated backups with retention up to 35 days
Manual backups don’t have any retention limit
Up to 15 read replicas for offloading your reporting queries
A Recovery Time Objective (RTO) of 5 minutes, and the ability to restore from your backup in a different Availably Zone
The following diagram illustrates this architecture.
Migrate to Amazon RDS Proxy
The second option was to migrate to Amazon RDS Proxy. This option offers the feasibility to achieve everything that is discussed in option 1 (migrating to Amazon RDS for PostgreSQL), and also offers additional database instances to achieve high availability using RDS Multi-AZ. Every transaction committed on the primary database would be synchronously committed on the secondary instance, so the Recovery Point Objective (RPO) is zero. In other words, in the unlikely event of a disaster in the Availability Zone hosting the primary database instance, the secondary database instance will automatically be promoted to the primary database instance in a matter of seconds, and it will have all the data committed from the previous primary database instance. The following diagram illustrates this architecture.
Migrate to Amazon Aurora PostgreSQL-Compatible Edition
Amazon DMA showed that a-tune can achieve the following if they migrate to Amazon Aurora PostgreSQL-Compatible Edition:
A resilient solution that keeps six copies of your data across three Availability Zones.
The option to use a serverless infrastructure that can scale instantly.
Fast cloning, and zero downtime patching.
Increased availability by using RDS Proxy for both writer and reader endpoints, if needed. The RPO is zero and the RTO is measured in seconds.
The following diagram illustrates this architecture.
Amazon DMA explained the pros and cons of the three options and helped a-tune align on a future state architecture that met their business needs.
Migration effort estimation
To estimate the migration effort, Amazon DMA conducted the following activities:
Extracted the embedded SQL statements in the application layer to understand the percentage of SQL statements that would require manual conversion and the effort required to refactor them
Analyzed the workload’s database layer and observed the need to refactor the database configurations, database queries, procedures and functions, specific data types, schema, tables, triggers, views, and scheduler jobs
Created a detailed migration effort estimate across the following steps involved in refactoring and deploying the workload to production on AWS:
Future state architecture
Database schema conversion
Application conversion
Scripts, ETL, and reports conversion
Integration with third-party applications
Data migration mechanism
Testing and bug fixing
Performance tuning
Integration and deployment
Documentation and knowledge transfer
Project management and version control
Post-production support
Amazon DMA estimated that it would take approximately 20% of the effort to refactor the application layer, 61% to refactor the database layer, and the remaining 19% to conduct testing, production deployment, and post-production deployment support activities.
Migration process
Amazon DMA recommended using two environments to conduct migration.
Refactoring Environment: In this environment, the application and database code would be refactored using DMS Schema Conversion, and conduct CI/CD using AWS CodeCommit, AWS CodeDeploy.
Data Migration & Validation Environment: This environment would be used to migrate data and to test the converted objects. For data migration, we recommended AWS Database Migration Service, and to validate the migrated objected, we recommend using comparison scripts.
Amazon DMA assisted a-tune in accelerating their AWS migrations by 3 months.
Conclusion
In this post, we shared how Amazon DMA helped a-tune to accelerate their migrations to AWS Databases and Analytics services.
Amazon DMA offers complementary advisory services to create migration strategy and implementation plans, and enables your in-house migration team (or Amazon Professional Services or APN Partner, if involved) to conduct migration implementation. If you are planning to migrate your workloads to AWS Databases and Analytics services, email [email protected] to engage the Amazon DMA team.
About the authors
Venkat Sunil Pathi is a Global Principal Solution Architect at Amazon Web Services (AWS) with focus on accelerating global and strategic enterprise migrations to AWS Database and Analytics services.
Sharath Gopalappa is a Sr. Product Manager Technical at Amazon Web Services (AWS) with focus on helping organizations modernize their technology investments with AWS Databases & Analytics services.
Read MoreAWS Database Blog
