Back

Data Migration to Snowflake: Lift ‘n’ Shift vs Re-engineering

11.01.2021

When compared to traditional legacy data warehouses, cloud computing offers many appealing advantages for analytical solutions. We already wrote about why many organizations are moving to the cloud, so this time we will focus on what you should contemplate before the data migration project, so you are not disappointed with the result.

There is no universal migration strategy. In order to select the best technology and the most appropriate migration approach, you must start at the very beginning and ask yourself, what drives you to move to the cloud? What are the main goals you are trying to achieve with the new platform? What are the important functional and non-functional requirements? You need to clearly define and prioritize all the technical and business benefits you expect, and you should also note down all the downsides of not moving to the cloud as well.

In search for your perfect match, you don’t want to miss the star of the cloud sphere: Snowflake Data Cloud allows you to build a modern data architecture and with its Platform, they tick all the boxes of what somebody would need when moving to the cloud. This unified platform enables secure and governed access to all your data and supports many workloads while its unique cloud-built architecture delivers the scale, performance, and automation for any organization to instantly and infinitely scale any number of users and workloads well beyond what’s capable with legacy architectures.

The two paths – Lift ‘n’ shift vs Re-engineering

Simplified, there are two common approaches on how to migrate your existing data warehouse to Snowflake:

• Lift ‘n’ shift
• Re-engineering

As the name suggests, with a lift ‘n’ shift approach you move your data warehouse to the cloud as-is. You are lifting it from your existing on-premise landscape and shifting it to the Snowflake environment. The logic of the code stays the same, but the code itself still needs to be adapted to fit into the new environment and that can be a challenge as well. Luckily, Snowflake supports various syntaxes which means you’ll need only minor corrections (note though that Snowflake supports functions and procedures, but not packages, so any code that was written in Oracle PL/SQL will not execute in Snowflake and will have to be rewritten). You can read more about it in our Oracle to Snowflake migration series: Migrating SQL Code.

Nevertheless, this kind of strategy makes sense if your existing on-prem infrastructure and maintenance costs are very high and you would like to reduce them immediately. Or, if you are running out of resources and you don’t want to invest in new costly hardware. Regardless, the time to implementation is a crucial factor influencing the decision. There is another pre-condition, the new system must have all the features and functions of the old system.

The lift ‘n’ shift approach can certainly open the path to IT modernization. However, there could be some limitations in leveraging cloud efficiencies. Re-engineering means that you will have to redesign your existing processes or even build them anew, but it will also better suit the cloud environment.

Re-engineering is hard to avoid if your main goal is to eliminate the limitations and bottlenecks of the existing solution or would like to fully embrace cloud-native capabilities, scalability and elasticity.

For example, using an existing on-prem data integration tool for data transformation will not exploit the potential of the cloud computing power as well as it could. Not to mention the amount of network traffic that such processing would require if the new solution would transfer each transformation step from on-prem to cloud and back.

You should also consider re-engineering if you would like to scale your data ecosystem and implement new types of data sources that could not be covered in the existing application such as real-time and streaming data or if you would like to add a new data ingestion tool, move to a new data visualization application or embrace new business opportunities of monetizing data.

When comparing both approaches it might look at first as if the lift ‘n’ shift option is less expensive. But in the long run, it may not prove to be the most cost-effective one. Re-engineering can reduce TCO because of the better cloud environment utilization and it can bring higher business outcomes because the re-architectured solution will be easily adjusted to meet new requirements because of its access to innovative features of the new platform.  

For these reasons, many companies start with lift ‘n’ shift and plan data warehouse modernization as the second phase of the project, or they break down the migration project and combine both approaches. There is also an adjusted approach with a simple “improve” step between lift and shift.

To make the best decision about the right approach, you need to do a thorough current state data warehouse assessment to understand what you’re migrating. You should list and evaluate all existing processes. If you find the process efficient and that it can be migrated with minimal effort, then it can be moved as-is. If you find it flawed, then it is a review candidate and could benefit from a redesign. If you find it outdated then a complete re-engineering would make sense sooner or later. Clear understanding of both what you currently have and what you would like to achieve is key to harnessing the cloud benefits as soon as possible. We will write more on how to approach the assessment of the current situation in our upcoming article Data Migration: A Well-made Migration Plan.

Katja Jurkovšek, Senior Consultant