Nick Walter, Principal Architect
In my role with House of Brick, I have the opportunity to assist many of our clients with migrating their business-critical databases to the public cloud. While every client (and every migration plan) is unique, I’ve observed a trend of common mistakes, or misconceptions, about the process of migrating to the cloud that occur again and again amongst my clients. Lately I’ve taken to reviewing these common pitfalls right at the beginning of migration planning, which has been successful in preventing my clients from experiencing issues that slow down or derail cloud migration plans. I thought it would be negligent not to share all these issues with readers of our House of Brick blog. Today I share the first part of my series on common database cloud migration pitfalls, which focuses on using the proper tools.
Often the first, and most easily preventable, mistake that I see made in cloud migration planning is not utilizing the proper tooling for migrating relational databases. Typically, this happens because organizations moving to the cloud are, well, new to the cloud. Some aren’t aware of the possibilities, so they think they won’t need special tooling at all. This type of enterprise just plans for cold offline copies to be used for migration and warns their users of a lot of impending downtime. Others go for the dreaded one-tool-to-rule-them-all approach and try to use a tool designed for general application server or VM migration to handle a migration of a complex relational database with high uptime requirements. Neither approach leads to a good outcome.
The right approach, tooling wise, depends on the needs of the database. Production relational databases often have strict uptime and performance requirements, whereas databases from test or development environments can usually take a weekend down without anyone complaining. Finding the right approach for each database helps to enable a smooth migration experience, and can take much of the sting out of a cloud migration project.
At a conceptual level, available tools fall into a few categories, so instead of describing each tool in detail, I’ll address each category.
Server Migration Tools
Server migration tools endeavor to simply take an existing on-premises system image and automatically convert it to a cloud instance in AWS or Azure. Historically, these tools have been an extremely poor fit for relational database workloads. Examples of these kind of tools are: AWS VM Import/Export; Azure Site Recovery; AWS CloudEndure; and a variety of vendor- specific storage technologies. While these tools can certainly copy an existing on-premises relational database to a cloud environment, and get a working copy, they typically use rough-and-ready rules for converting an existing system image to the available cloud instance shapes available. This leads to two immediate problems for the migrated database. The first is performance, as often the storage or compute is not laid out in an optimized manner that suits the workload. The second is licensing, since licensing rules for on-premises databases and licensing rules for database in the public cloud often differ. Generally, I advise all of my clients to steer clear of server migration tools as the convenience they offer is more than offset by the back-end headaches of trying to operate a relational database platform in a cloud environment, which is not configured in a performant or license-compliant manner.
Backup/Recovery Tools
The second category of tools is perhaps the simplest, which I’ll collectively refer to as Backup/Recovery tools. These tools are useful for migrating relational databases to the public cloud as part of a replatforming effort. The strategy for using these tools in a public cloud migration is as simple as you might imagine. A new, and empty, database is created in the cloud, with proper care taken that the system is configured in a performant and license compliant manner. Then the data is simply backup up from the on-premises platform and restored to the cloud platform. This approach is very suitable for relational databases with low uptime requirements and loose service level agreements. For non-production systems, the use of backup/recovery tools can be a very productive way to approach migrations, since the tools are well tested, and reliable as well as tools with which most DBAs are very familiar.
Data Mirroring Tools
The last category is one that I choose to term Data Mirroring tools and, as the name implies, consists of tools that will mirror relational database data to another platform. Examples of these tools include AWS Database Migration Service, Azure Database Migration Service, Oracle GoldenGate, and SymmetricDS. These types of tools have long been popular for mirroring database contents to disaster recovery data centers, and thus represent a stable and mature technology. The strong advantage of using these kinds of tools is that they can mirror database data to the cloud while the on-premises database remains in normal production status. Then when the mirroring is complete, and the cloud copy has been confirmed as fully synchronized, service can be switched over to the cloud almost instantly. This extremely short downtime for migrating service to the cloud is very attractive for production relational databases with tight service level agreements and business-critical functions. The downside of these tools is that they often represent additional costs, require a learning curve for the DBA staff employing them, and constitute an additional maintenance item that will require a DBA’s attention.
I urge everyone planning a relational database migration to review their tooling choices carefully, with a focus on their specific migration needs. In addition to considering the downtime requirements and tooling costs, be sure to take into account the final-state performance and licensing compliance of the migrated platform.
