DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog How to move a relational database to the cloud without a hitch

How to move a relational database to the cloud without a hitch

Many things can go wrong when migrating a relational database to the cloud. But upfront planning and preparation will help things go right.

A few weeks ago, I wrote about five questions to ask about a database before migrating it to the cloud. Here, we look at what comes next: developing and implementing a database migration strategy. We’re focusing on relational databases, but the same principles apply to other types too.

What’s so hard about migrating a relational database?

It’s not that relational databases are more difficult to migrate than other workloads. Just there’s a tendency to underestimate their complexity and assume they’ll integrate with the new environment without much effort. This is rarely the case and the consequences of a poorly executed migration range from performance glitches to full-blown outages. Hosting costs can also spiral up if a relational database hasn’t been optimised for the cloud. We’ve known of cases where companies’ monthly bills were twice as high as expected.  

So, how can this be resolved? Acknowledging that the migration requires dedicated attention is a good place to start. From here, you can make purposeful decisions based on individual circumstances. Based on our experience handling relational database migrations, there are three core areas to think about:

  1. Homogeneous or heterogeneous migration (more on this below)
  2. The migration pathway – rehost, re-platform or rearchitect (‘migrate and modernise’ versus ‘migrate then modernise’)
  3. Online or offline migration.

Weighing up the pros and cons of different approaches, then making informed decisions, leads to a more streamlined migration. Potential problems are identified upfront, and if they can’t be avoided altogether, they can at least be planned for and mitigated.

Homogeneous or heterogeneous migration

First off, think about whether the target database will involve the same technology as the source database (homogeneous migration) or whether it would be better to use a different database technology (heterogeneous migration).

For instance, in a homogenous migration, an on-premises SQL database might move to Azure SQL Managed Instance or Amazon RDS for SQL Server. The database engines are the same, and the transition is relatively straightforward.

However, it may be better to switch to a cloud-native technology, such as Amazon Aurora or Azure SQL. Heterogeneous migrations like these are more complex, but the benefits can outweigh the risks.

There’s no single right answer here. Every situation is different, and many factors need to be accounted for, from wider organisational objectives and scalability requirements to budgets and timescales. The decision requires careful consideration as it will shape the rest of the migration strategy and have a significant bearing on future activity in the cloud.

The migration strategy

A while back my colleague Rael Winters covered the various migratory pathways in a blog about simplifying your options for cloud migration. Many of his points hold true when it comes to migrating a relational database.

To some extent, the strategy will be dictated by the decision to go for a homogeneous or heterogeneous migration.

When sticking with the same database technology, a simple rehost – or lift and shift – is one option. If timings are tight, sometimes this is the only feasible route. The database can be moved as-is, so it’s certainly the quickest way to get to the cloud. However, it’s important to recognise that aspects of the database will need to be modernised after the migration to avoid future problems.

Homogeneous migrations can also take a re-platforming approach. Infrastructure-level optimisation primes the database to leverage cloud capabilities from day one. For example, time spent managing database instances can be reduced by taking advantage of a database offering that is fully managed by the cloud provider.   

With a heterogeneous migration, organisations switching from an on-premises to a cloud-native database need to undergo a complete rearchitect, restructure and rewrite. This is no mean feat; the process is complex and resource-intensive. However, if time and budget permit, it is the best way to avoid expensive licences and vendor lock-in. It also enables long term cost savings and allows closer alignment with AWS and Azure best practices.

Before making a final decision, look at any tooling and documentation offered by the cloud provider to support the various migratory paths. This will indicate how difficult the process is likely to be, and what support is available. Bear in mind that some tools offer easy data migration but require specialist skills for the database itself. It may be worth considering a phased approach, for instance addressing core database functionality then integrating additional cloud services with the target environment before any refactoring happens.

Online or offline

If the application supported by the database can afford planned downtime, an offline migration is simplest. The source database will be unavailable throughout the process, so for a certain window of time no new connections or changes can be made to the data it holds. Once the migration is complete, validation and verification checks are made to ensure the data is consistent, then the cutover is performed, and the target database is brought online.

Online migrations for applications that cannot tolerate downtime involve a series of steps. Firstly, data from the source database is copied to the target while the source is still running. From this point, any changes to the source need to be propagated to the target, then cutover can happen once the two are in sync. During cutover, the application switches its connection to the target database, and the connection with the source is terminated.

The latter requires far more planning and preparation, but if downtime will have an impact on SLAs it may be the only viable approach. It’s best to conduct a test run ahead of the actual migration to identify any issues that may arise. We also advise creating a proof of concept to reveal any problems that might require strategic change before too much time and effort has been invested.

Treat a database as technology in its own right

There are many ways to migrate a relational database. The secret is to find the best approach for your circumstances, and not to assume it will be easy.

Here at DevOpsGroup, we hold dedicated workshops ahead of database migrations, just as we do for application workloads. We find this is the best way to ensure all necessary information is gathered so we can develop a migration blueprint that delivers the desired outcome. With any migration, our goal is to get things right first time. And we’ve developed a seamless process that gets relational databases off to a flying start in the cloud.

Our cloud migration services for AWS and Azure include database discovery sessions. Find out more.

Leave a Reply

Your email address will not be published. Required fields are marked *