4-step database migration methodology
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, our recommendation to customers is to take a step-by-step approach to migration. That way, you will feel more comfortable knowing that data is getting from one platform to another in a secure and efficient fashion. Cloudreach is now offering Database Migration services from any origin to Amazon RDS for Oracle or Amazon RDS for SQL Server. The outcome? You will see benefits from lower cost of migration, optimization/modernization, lower administrative burden to operate the core of your databases, and confidence in the approach and technologies used to execute the most stressful part of an infrastructure change.
From a high level, the 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. You might have an on-prem Oracle or SQL Server database and want to rehost them in the cloud. As a matter of fact, Cloudreach can migrate your database from any origin to Amazon EC2 or Amazon RDS as long as the DB engine version is supported. Your organization can further reap the benefits by conducting a heterogeneous migration to Amazon Aurora by re-factoring your platform using Amazon Schema Conversion Tool (SCT). Amazon Aurora will be discussed in a separate blog.
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. Most importantly the database size, licensing agreement, IOPS requirements, dependencies, version support, downtime tolerance, custom features, in-house DBA expertise, TCO analysis, etc. The list goes on.
Cloudreach uses Cloudamize, an agentless software to collect and discover on-prem 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 DB 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 you want to further tap into a more cloud native environment like Amazon Aurora, our AI/ML based discovery tool Sunstone is designed exactly for this. It analyses where efficiency 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.
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 start working to modernize your application. This strategy can help you exit out of your current data centers quickly, 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 cloud, thus a ramp-up period is needed before becoming fully cloud native.
Relocate (hypervisor-level lift and shift) – Move infrastructure to the cloud without purchasing new hardware, rewriting applications, or modifying your 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. VMware on Cloud is becoming prevalent in the market.
Replatform (lift and reshape) – 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 Amazon RDS Custom for Oracle in the AWS Cloud.
Refactor (re-architect) – 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 might 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 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 that the migration effort required is significant; therefore, you might want to choose another option, such as rehost or replatform to complete the migration within an acceptable timeframe.
AWS WQF Categories
Your 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/optimization or deployment orchestration. All 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 DB configuration as needed.
Transforming from on-prem database to fully managed Amazon RDS
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, DR, 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. Our delivery method is battle-tested, with 12+ years of experience and hundreds of migration projects. Once the migration is complete, our 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 DB schema from source to target database for heterogeneous migrations. We also use AWS Data Migration Services (DMS) to migrate the data. With AWS DMS you can keep the source database up and running while the data is being replicated. 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 AWS DMS documentation.
Once the migration is complete, Cloudreach will make necessary updates to make sure the application is running on the latest compatible version of the software. We will further test and fine tune the DB 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
Why Cloudreach?
Cloudreach has been an AWS Premier 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. We have a proven track record and mature expertise to handle complex projects. On top of that, Cloudreach has signed a number of strategic agreements with AWS to jointly support the endeavor of helping organizations adopt cloud innovation. Most notably:.
- 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. Our 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), recommends optimized licensing scenarios for the most cost-effective cloud solution and comparison. It is aligned with AWS best practices, in collaboration with the AWS MAP team. Specifically, it assesses databases on configuration and proprietary features. The outcome could be instance right-sizing, license consolidation and/or flexible licensing options.
For more information about our 4-step database migration solution, please reach out to the team through our contact us form.
Author: Kyle Chang, Sr. Product Manager Cloudreach
