AWS Partner Network (APN) Blog
Step-By-Step AWS Database Migration Made Easy by Cloudreach
By Kyle Chang, Sr. Product Manager – Cloudreach
By Sathya Paduchuri, Sr. Partner Solutions Architect – AWS
 |
| Cloudreach |
 |
Migrating a database to a new platform is a significant event in an application’s lifecycle. The process can impact performance, availability, and reliability to a large extent.
Based on the number of migration services Cloudreach has successfully completed, one recommendation it makes to Amazon Web Services (AWS) customers is to take a step-by-step approach to migration. That way, organizations will feel more comfortable knowing data is getting from one platform to another in a secure and efficient fashion.
Cloudreach is an AWS Premier Tier Services Partner and Managed Cloud Services Provider (MSP) that offers database migration services from any origin to Amazon RDS for Oracle or Amazon RDS for SQL Server.
With Cloudreach, customers will see benefits from lower cost of migration, optimization and modernization, lower administrative burden to operate core databases, and confidence in the approach and technologies used to execute the most stressful part of an infrastructure change.
Before You Start
At a high level, the migration steps can be broken down into assessment, evaluation, planning, and execution. Cloudreach has developed a methodology that focuses on migrating and modernizing to cloud-native database infrastructure currently available on AWS.
The solution is targeted to organizations that want to improve database performance, reduce administrative churn, and optimize licensing costs. Customers may have an on-premises Oracle or SQL Server database and want to rehost them in the cloud. Cloudreach can migrate a database from any origin to Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Relational Database Service (Amazon RDS) as long as the database engine version is supported.
Organizations can further reap the benefits by conducting a heterogeneous migration to Amazon Aurora by re-factoring their platform using AWS Schema Conversion Tool (SCT), which automatically converts the source database schema and a majority of the code objects to a format compatible with the target database.
Step 1: Database Migration Assessment
The first step is to perform an analysis of your application and database workloads by understanding the complexity, compatibility, and cost of migration. This includes database size, licensing agreement, IOPS requirements, dependencies, version support, downtime tolerance, custom features, in-house database administrator (DBA) expertise, total cost of ownership (TCO) analysis, and more.
Cloudreach uses Cloudamize, an agentless software to collect and discover on-premises assets and dependencies in your estate. Once the data is collected, a report is generated to determine a number of possible paths for migration based on the source and desired target database engines, as well as a review of the database dependencies.
If you have already migrated your database (SQL Server in this case) to Amazon EC2 but want to tap into a more cloud-native environment like Amazon Aurora, Cloudreach’s artificial intelligence (AI) and machine learning (ML)-based discovery tool Sunstone is designed exactly for this.
Sunstone analyzes where efficiencies can be gained, such as licensing optimization and task automation. Based on the recommendations, the Cloudreach team can quickly map out several migration paths.
Step 2: Database Migration Evaluation
All database migration strategies involve some level of change to the applications that use those databases. These changes range from pointing to the new location of the database in the AWS Cloud to a total rewrite of the application. If it cannot be changed due to source code unavailability, or if it’s a closed-source third-party application, then alternative solutions need to be sought out.
The guiding principle should be how you can get the maximum benefit out of your migration considering the tradeoffs between time, ROI, and performance.
Figure 1 – Migration paths.
Rehost (Lift and Shift)
If you decide to first transition your databases and transform them later, you can do a “lift and shift” migration. Once you are fully in the AWS Cloud, you can start working to modernize your application. This strategy can help you exit out of your current data centers quickly, and then focus on modernization as an ongoing exercise.
“Lift then optimize” is becoming more of an acceptable use case, as most organizations lack the necessary skills to fully embrace the cloud, thus a ramp-up period is needed before becoming fully cloud native.
Relocate (Hypervisor-Level Lift and Shift)
You can move infrastructure to the cloud without purchasing new hardware, rewriting applications, or modifying existing operations. This migration scenario is specific to VMware Cloud on AWS, which supports virtual machine (VM) compatibility and workload portability between your on-premises environment and AWS.
You can use the VMware Cloud Foundation technologies from your on-premises data centers when you migrate your infrastructure to VMware Cloud on AWS. For example, relocate the hypervisor hosting your Oracle database to VMware Cloud on AWS, which is becoming prevalent in the market.
Replatform (Lift and Reshape)
You can move an application to the cloud and introduce some level of optimization to take advantage of cloud capabilities. For example, migrate your on-premises Oracle database to Amazon RDS for Oracle or the newly-introduced Amazon RDS Custom for Oracle in the AWS Cloud.
Refactor (Re-Architect)
You can move an application and modify its architecture by taking full advantage of cloud-native features to improve agility, performance, and scalability. For example, migrate your on-premises Oracle database to Amazon Aurora PostgreSQL.
This strategy can also include rewriting your application to use the purpose-built databases that AWS offers for different workflows. Or, you can choose to modernize your monolithic application by breaking it down into smaller microservices that access their own database schemas.
Retain (Revisit)
Keep applications in your source environment. These may include applications that require major refactoring and you want to postpone that work until a later time, and also legacy applications that you want to retain because there is no business justification for migrating them.
Retire
Decommission or remove applications that are no longer needed in your source environment.
Cloudreach adopts the AWS Workload Qualification Framework (AWS WQF) to qualify workloads. The WQF categorization helps you decide when you should consider a particular migration strategy. A higher WQF category means the migration effort required is significant; therefore, you may want to choose another option, such as rehost or replatform to complete the migration within an acceptable timeframe.
Figure 2 – Workload complexity and strategy.
Your database administrator (DBA) used to manage the entire infrastructure out of the data center from physical infrastructure all the way to application level performance.
With Amazon RDS, your DBA’s responsibility has significantly reduced to just app optimization tuning. Their effort can be reallocated to higher value-add activities such as schema design, query construction and optimization, or deployment orchestration. All of the heavy lifting in dealing with operational tasks has been liberated.
Cloudreach and its affiliate team can act as your DBA or work jointly with your IT team to monitor and fine tune your database configuration as needed.
Step 3: Database Migration Planning
A project without a plan is a plan to fail. A migration plan should be formed with the output metrics from the assessment and evaluation stage. At the very minimum, you should have:
- At least one migration path identified for each migrating database.
- Migration methodology.
- Architecture diagram: dependency mapping, network, security, API integrations, etc.
- Licensing impact analysis.
- Operational plan: alert, monitoring, logging, key management, backup, patching, upgrade, failover, disaster recovery, restore, runbook, emergency contact, handover procedure, etc.
- IAM role creation: least privilege access principle.
- Test plan.
- Migration cutover plan.
The planning phase is crucial in identifying potential roadblocks during the migration. If there are unforeseen challenges that set back the project, having a well thought out contingency plan will minimize the impact and guide best alternatives.
Cloudreach’s curated knowledge, automation, and proven process brings your data together in one place and promptly makes it available to users and applications in order to minimize downtime. Once the migration is complete, Cloudreach’s focus switches to monitoring, analysis, and modernization for consistent performance and risk reduction.
Step 4: Database Migration Execution
The execution phase of the solution will be customized to the migration engines being migrated from and to, and includes the end-to-end migration process.
Cloudreach uses a number of AWS-native tools to assist the migration effort:
- AWS Schema Conversion Tool (SCT) is used to convert the database schema from source to target database for heterogeneous migrations.
- AWS Database Migration Services (AWS DMS) are used to migrate the data. With AWS DMS, you can keep the source database up and running while the data is being replicated, and you can perform a one-time copy of your data or copy with continuous replication.
When the source and target databases are in sync, you can take your database offline and move your operations to the target database. AWS DMS can be used for homogeneous database migrations (for example, from an on-premises Oracle database to an Amazon RDS for Oracle database) as well as heterogeneous migrations (for example, from an on-premises Oracle database to an Amazon RDS for PostgreSQL database).
For more information about working with AWS DMS, see the documentation.
Once the migration is complete, Cloudreach will make necessary updates to make ensure the application is running on the latest compatible version of the software. Cloudreach will further test and fine tune the database performance to achieve optimal metrics.
Lastly, the cutover will take place using one of the following methods where appropriate:
- Offline migration
- Flash cutover
- Active Active
- Incremental
Conclusion
Cloudreach has been an AWS Premier Tier Services Partner for the past 12 years and has accumulated a myriad amount of experience helping customers–ranging from Fortune 100 to midsized enterprises–migrate their workloads to AWS.
Cloudreach has a proven track record and mature expertise to handle complex projects, and has signed a number of strategic agreements with AWS to jointly support the endeavor of helping organizations adopt cloud innovation:
- AWS Optimization and Licensing Assessment (OLA) – An OLA engagement is suitable for any customer unsure of their overall resource consumption and deployments and wants to gain a clearer understanding of how previous licensing investment can be transferred.
- AWS Migration Acceleration Program (MAP) – Cloudreach’s solutions are aligned with AWS best practices, in collaboration with the MAP team. This partnership with AWS allows customers access to accelerators for both funding and guidance on migration at scale
As part of the TCO analysis, Cloudamize combines market-leading discovery software delivering data and insights that identifies all licensing in your environment, regardless of platform, analyzes your actual resource consumption (ARC), and recommends optimized licensing scenarios for the most cost-effective cloud solution and comparison.
Cloudamize assesses databases on configuration and proprietary features, with the outcome being instance right-sizing, license consolidation, and/or flexible licensing options.
For more information about Cloudreach’s four-step database migration solution, reach out to the team through the contact us form.
.
.
Cloudreach – AWS Partner Spotlight
Cloudreach is an AWS Premier Tier Services Partner and MSP that offers database migration services from any origin to Amazon RDS for Oracle or Amazon RDS for SQL Server.