3 Approaches to Migrating Databases Every IT Leader Needs to Know – ToolBox

Database migrations are brutal but necessary” claimed John Foley in a recent edition of his cloud database report. The necessity is undisputed. However, the question is whether they really must be brutal? One thing is certain, database migrations can quickly turn into either career boosters — or career killers. 

Across the entire industry, IT leaders are currently looking at their on-premises systems and are trying to figure out how to make these workloads cloud-native. The business asks for IT to adopt innovative solutions and deep integration in a broader cloud ecosystem. And so, it feels IT leaders’ careers have never been on the line like this before. 

Given the importance of databases for the entire enterprise and the impact a cloud migration can have, it is critical to understand the options when driving such a modernization. In this article we look at the three major approaches to migrate databases, their pros and cons, and when to apply them. 

Rewriting workloads that currently run on an on-premises database to make them work on a cloud database appears to be the most intuitive and straightforward approach. Unfortunately, migrations based on rewrites have become notorious for their horrendous failure rates: Some migrations drag on for over a decade with costs reaching eye-watering levels and, as per Gartner, the majority of migrations fail to accomplish their objectives. 

Why do many of these projects fail? One reason is simply the choice of the destination system. For example, trying to replace a Teradata appliance with vanilla Hadoop is not likely to succeed because of the limited functionality and throughput of the latter. Ensuring that the destination is on par with the original system in terms of scale and performance is therefore paramount. 

The other killer of rewrite projects is the sheer scope of it: rewriting millions of lines of SQL and application code is an enormous undertaking. On top of it, the 80/20 nature of the problem means the majority of effort and cost occurs in the last 20% of the project. In other words, when rewriting SQL, good progress in the first months, or even years, may not mean the finish line is any closer. Continue Reading

About Mike Waas, CEO Datometry

Mike Waas founded Datometry with the vision of redefining enterprise data management. In the past, Mike held key engineering positions at Microsoft, Amazon, Greenplum, EMC, and Pivotal. He earned an M.S. in Computer Science from the University of Passau, Germany, and a Ph.D. in Computer Science from the University of Amsterdam, The Netherlands. Mike has co-authored over 35 peer-reviewed publications and has 20+ patents on data management to his name.