AWS Database Blog

Key considerations for migration estimation from Amazon Database Migration Accelerator

Migrating certain workloads (application and database) to new cloud platforms can be technically challenging. AWS launched Amazon Database Migration Accelerator (Amazon DMA) to accelerate and simplify your journey to AWS databases and analytics services. Amazon DMA has assisted thousands of customers globally to migrate their workloads.

In this post, we share Amazon DMA’s approach and key considerations to accurately estimate the effort required to refactor or modernize existing workloads while migrating them to AWS.

Workload Estimation

Amazon DMA consists of migration experts, tools, and processes that accelerate migration strategy, migration solution development, and implementation plans, and ensures your in-house migration team (or Amazon Professional Services or APN Partner, if involved) have a successful heterogeneous or cross-platform migration implementation. Amazon DMA uses three input parameters to analyze the workload, understand its dependencies and the complexity involved to move to it a cloud-native AWS managed databases or analytics service or open-source target:

  • Data Definition Language (DDL) for all database objects used by the workload
  • Application source code, including extract, transform, and load (ETL) jobs and dependent SQL reports
  • The workload’s architecture and usage patterns

First, to estimate the effort required to refactor the database, Amazon DMA uses the migration assessment reports from DMS Schema Conversion in AWS Database Migration Service (AWS DMS) to identify database storage and schema objects that can be refactored automatically to the target engine, and the ones that would require manual conversion. Amazon DMA uses estimates from DMS Schema Conversion as a baseline for the issues that require manual conversion, and dives deep to uncover areas that require additional focus, such as dynamic SQL statements or third-party vendor-specific features. Amazon DMA validates patterns seen previously and applies common solutions, including automation to optimize the effort estimate for the refactoring and modernization effort. This is combined with the effort to conduct testing and validation to arrive at the overall estimate to refactor the database.

Second, Amazon DMA estimates the effort to refactor the application code and conducts a manual code review. Amazon DMA evaluates the complexity and the number of files or classes in the code that would require modification due to the change in the underlying database engine, as well as the complexity and the number of SQL statements discovered in the application code. Then Amazon DMS uses these metrics to create an estimate to modify the affected code and rewrite the SQL statements to support the chosen target database engine.

Finally, Amazon DMA considers additional factors that might add effort or complexity to migrating the workload, such as the availability and coverage of automated tests, workload dependencies, effort required to set up the workload runtime environment, and third-party library compatibility. The following table lists the common checklist items considered by the Amazon DMA team while estimating the migration effort for the analyzed workload.

Topic Scope Considerations
Application Layer Database Interaction
  • Does the application layer use any third-party frameworks (for example, Hibernate or Microsoft Entity Framework) to access data from the database layer? If so, do any of the entity mappings need to be changed if the object names and data types are changed in the database?
  • Is there a custom in-house data access layer?
SQL Statements
  • Are any SQL statements constructed dynamically in the application layer (for example, string concatenation)?
  • Does the application layer use any dynamic SQL frameworks (for example, LINQ)?
  • Are any SQL statements stored outside the application code? For example, XML/File System, or in the database.
Database Driver Features
  • Is the application layer using any custom or proprietary driver features (for example, bulk load libraries)?
Unit Testing and Code Coverage
  • Is there a well-developed testing framework? If so, what is the code coverage level?
Third-Party Libraries
  • If third-party libraries are used, are there any version compatibility issues that we need to consider while migrating to the target engine?
Database Issues Identified in the DMS Schema Conversion Results
  • Do the Schema Conversion results include any issues with missing remediation steps?
  • Do the Schema Conversion results include any issues that are marked as “Complex”? (These are the issues that Schema Conversion considers to require the most effort to resolve.)
  • Do the Schema Conversion results include any evidence for usage on vendor-specific features or objects created by third-party products?
  • What are the most frequently occurring action items identified in the Schema Conversion results, particularly those for database code objects?

Conclusion

In this post, we shared the approach of Amazon DMA and key considerations to accurately estimate the effort required to refactor or modernize existing workloads while migrating them to AWS. In the coming weeks, we will publish additional posts on Amazon DMA migration methodology, portfolio (collection of workloads) migrations, production cutover scenarios, and more. Stay tuned!

If you’re planning to migrate your workloads to AWS databases and analytics services, email DMA-sales@amazon.com to sign up for complementary Amazon DMA advisory services.

About the authors

Michael Swafford is a Sr. Solutions Architect Manager at Amazon Web Services (AWS) managing a team of AWS database migration advisors who help customers in their migrations away from traditional commercial databases.

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.