This article was originally published in Integration Developer News.
It’s no secret that enterprises are looking to replace their existing data warehouse with modern technology in the public cloud.
IT leaders have a difficult decision to make – what is the best way to transition? They can either virtualize the existing data warehouse onto the cloud or go for manual migration.
Manual migrations where many, if not all, applications need to be rewritten are often regarded as a clean-slate approach. “Out with the old, in with the new” appeals to decision makers.
However, manual migrations often seem to spiral out of control. They run into the millions and take several years. On top of that, they may damage an IT leader’s career and tarnish the team.
In response to this challenge, a few vendors started offering software tools that aim at accelerating this process. They promise to automatically translate SQL code — as best they can. To use these tools, extract SQL from the application, run the converter, and then re-insert the translated code into the application. It seems like a helpful approach at first. However, at close inspection, several significant deficiencies become apparent.
Let’s examine the areas where SQL code conversion is applicable — and where it fails to live up to its promise.
Code Converters Save Less Than 20% of Cost
First off, for quite a number of cases, code conversion for SQL does work. These are typically the “easy” cases. Every workload has them. However, few workloads if any consist only of these easy cases. Rather, the difficult cases are everywhere and cannot be separated from the easy ones.
By their own admission, code converters can confidently translate about 60-70% of a workload. This limitation is due to the fact that for each statement they need equivalent language in the destination data warehouse. Read the full article here.
