Moving an organization to the cloud takes time, just like most organizational transformations. This requires careful planning.
Ideally, some businesses pick just one project to test out with a cloud provider: either an active project that offers a good test case or a fresh project free of legacy procedures.
Nearly all businesses that switch to the cloud first migrate a non-critical database as a proof-of-concept. You can apply what you’ve learned to other databases across your organization once you’ve successfully moved a small project that benefits from using the cloud or take advantage of the low-hanging fruit.
This post will explore how you can plan the successful migration of your databases to the cloud.
Planning the cloud database migration
Planning involves the following steps: requirements gathering, determining capabilities to address the requirements, assessing which databases to move and what changes might be required to the database or the applications using it, and establishing success criteria and rollback criteria (fail-safes).
Thorough planning helps an organization assess the current environment (applications, databases, and critical workloads), estimate how the applications or workload will run in the cloud environment, and how the migration will help meet business objectives and adjust the cost.
You must deal with physical, software, and organizational issues when you want to move a database running on-premises to a managed service in the cloud. It requires attention to several levels of change:
- Physical data movement: You must get the data into the cloud. Data transfer for large databases can be both time-consuming and costly, but there are migration services to help.
- Infrastructure compatibility: Check every aspect of the cloud service against your legacy on-premises systems. A case study on the AWS blog offers an interesting example of snags that might occur during a test migration by unexpected software incompatibilities and minor errors. This migration was held up for some time because of differences in SSL implementations by the on-premises systems and the cloud provider.
- Database compatibility: The cloud database is likely to differ from your on-premises database in some features that affect migration. Subtleties such as database character sets and permissions on stored procedures can trip you up. A homogeneous migration (such as from one Oracle database to another Oracle database) will probably go more smoothly than a heterogeneous migration (such as from an Oracle database to a PostgreSQL database or one of the proprietary cloud vendors’ databases). Checking for incompatibilities reduces friction between databases.
- Organizational changes: People from several teams, especially DBAs and application developers, will need to devote time to learning the cloud tools and managing the new instances while keeping the legacy systems on-premises until you are ready to move everything to the cloud. You might choose to spend months or even years doing a full migration. You might also permanently keep some of the data (or a copy) on-premises.
Readiness Assessment
A readiness assessment helps you to estimate the costs, the architecture of the cloud database, migration plans, and the impact of the move to the cloud on compliance regulations. Following are the key steps during a cloud readiness assessment.
- Stakeholder interviews: Talking to application developers, business users, and others concerned with the use of data within your organization team will help you to determine requirements about performance, high availability, and the features and capabilities of the cloud-based databases.
- Analysis of current on-premises databases: Go back over your current databases to determine growth patterns of data, backup and recovery strategies, ongoing data exports and imports, and so on. Understanding the current database usage patterns will help you when it’s time to decide what databases to use in the cloud and whether you’ll need a particular database offering to get the capabilities you need.
- Prioritization of the databases to move: Pick the databases you’d like to move to the cloud first.
- Migration cost analysis: Perform a thorough analysis of the costs of migrating to the cloud versus staying in the on-premises datacenters to fully understand the TCO and ROI of the cloud migration. Lowering costs using a cloud database service might be one of your key goals. But a poor choice of cloud services will defeat this purpose.
- Security and compliance: Sometimes, you need special regions or AZs to comply with standards such as Service Organization Control 2 (SOC 2), PCI DSS, or the US HIPAA. Fortunately, cloud providers often match particular regions and AZs to these legal requirements. In addition, there are specialized regions, such as AWS’s GovCloud (US), which is an isolated AWS region subject to FedRAMP High and Moderate baselines. Finally, you must check whether you can meet your organization’s service-level agreements (SLAs) in your chosen cloud setting. These SLAs typically include metrics for planned maintenance, backups, recovery point objectives (RPOs), and recovery time objectives (RTOs).
