More organizations are turning to database-as-a-service platforms in search of faster, more scalable deployments and lower costs. With a plethora of DBaaS products and tools available today, the case for starting a cloud database migration has become even more compelling.
However, there's a common set of misconceptions and overlooked areas that continue to cause problems for IT teams during migrations to DBaaS platforms. They mostly affect organizations that are new to cloud database migrations, but companies that have migrated a number of on-premises databases to the cloud aren't immune to them either.
When you identify and address issues early in the cloud database migration lifecycle, you can minimize their impact and have fewer surprises when you flip the switch on your new DBaaS system. Here's a breakdown of the top 10 missteps IT teams make when undergoing a cloud database migration.
1. Underestimating cloud database migration and support costs
DBaaS platforms aren't new products. They are new architectures. Like all new architectures, they will have a wide-ranging impact that changes the way your shop builds, accesses, administers, monitors and secures its systems. You also need to factor in costs for training, documentation and organizational changes. We'll learn more about budget implications throughout this article.
2. Underestimating the organizational and procedural changes
Existing staff will have new responsibilities, and your organization may need to create new positions to support the DBaaS platform. Because DBaaS differs greatly from on-premises databases, you will have to update your change management processes and support documentation. How long that takes depends on how stringent your change management processes, documentation and auditing requirements are.
3. Not providing internal personnel with sufficient training
Administrators will need to learn how to provision, administer, tune, secure, monitor and recover the DBaaS platform. It's the same basic principles of good administration that apply to all database management system environments, but your database administrators will be using different tools, utilities and commands to perform those support operations.
4. Not understanding the vendor's cost models
You won't be purchasing your DBaaS system. You'll be renting it. Those rental fees will vary based on vendor, product, instance configuration and workloads. Each vendor has different ways of charging the customer. In addition, some of the vendors' pricing models can be complex. To accurately estimate your rental fees, you must understand the metrics the provider uses to calculate costs.
5. Incorrectly sizing the DBaaS instance
Before starting a cloud database migration, your administrators will need to measure the on-premises database's resource consumption to configure the DBaaS instance's performance tiers and estimate monthly rental fees. Key resource consumption metrics usually include CPU, memory, disk storage, I/O and data transfers into and out of the environment.
6. Not accounting for cloud/on-premises database feature mismatch
There can be significant differences between on-premises database features and their DBaaS counterparts. DBaaS vendors will often provide an on-premises/cloud database feature compatibility matrix. The matrix identifies the differences between the two products and includes workarounds or a description of the cloud database's "like" functionality. Some of these feature mismatches can be complex to resolve.
7. Not verifying that your preferred tool sets will still work with the DBaaS system
Your shop's favorite in-house and third-party tools may need to be modified to access the DBaaS platform. In some cases, finding a replacement product that inherently works with the cloud system may be more financially attractive than the costs associated with modifying an existing tool.
8. Making a database into an island
A common mistake is not identifying how the database interacts with other systems. How much data do you need to transfer back and forth to the cloud platform during daily operations? Does the database contain links to on-premises databases? Getting a lot of data into and out of a cloud architecture can be challenging, especially if there are tight time constraints.
9. Drafting inadequate testing and migration plans
As we learned, there are many areas that require evaluation throughout the cloud database migration lifecycle. Like any new architecture migration, your conversion checklist will need to be well thought out and detailed. This is not an architecture that you should enter into without extensive analysis and planning.
10. Failing audits after the production cutover
DBaaS platforms don't expose their underlying architecture to users. As a result, organizations that adhere to regulatory compliances often find that their DBaaS platform is unable to provide the supporting evidence their auditors need to verify the system meets audit control objectives. Part of your project plan should be to meet with auditing teams to discuss the evidence they need to demonstrate compliance.