Lift-and-shift migration: What it is and why it’s better

Inevitable and often intimidating: data migrations. Like moving into a new house, the process promises a better future but comes with logistical headaches and the risk of things going very wrong. In fact, more than 80% of migrations fail, often due to poor planning, lack of resources, and inadequate tooling. 

For data teams tasked with modernizing data infrastructure, whether it’s adopting cloud-based warehouses or modern transformation processes, determining the right data migration strategy can be overwhelming. Migrations aren’t just about moving data–they’re about ensuring business continuity and earning stakeholder trust. The choice of strategy can often make or break the process: should you focus on speed and simplicity or attempt re-architecting assets along the way too?

In this blog post, we’ll review one of the most common migration strategies–lift-and-shift–and its overarching costs, time, and people benefits. We’ll explore why lift-and-shift migrations are an ideal choice for many teams, breaking down their benefits, use cases, and alternatives to help you make an informed decision. 

What is a lift-and-shift migration?

In a lift-and-shift migration, assets are moved from a legacy system, like an on-premise data warehouse, to a modern system (e.g., Snowflake, Databricks) with minimal changes to the original assets. 

For example, if an organization is migrating 2000+ tables from Oracle to BigQuery in a lift-and-shift migration, those 2000+ tables will likely remain the same in structure without considerable refactoring. Some slight changes that may happen to assets during a lift-and-shift migration are changes to column data-types or naming conventions to adhere to the schema formatting in the new system. These code changes are often automated using SQL translation tools which reduce the need for manual code conversion. 

A lift-and-shift migration is one of the most common migration strategies used for larger-scale migrations. The simplicity of this strategy makes it appealing when migrating tables with many interdependencies and downstream use cases. By reducing the scope to “lifting” data as-is and “shifting” it to the new system, teams can minimize risks and maintain focus on ensuring data quality during this migration. 

But when should you consider lift-and-shift over alternatives? Let’s dig into the benefits and use cases for data teams considering undergoing one.

Lift-and-shift migration strategy alternatives

Alternatively, data teams may choose to migrate assets while refactoring and improving as they go. In a migration where refactoring is a primary focus, the underlying data transformation code may be reworked to be more efficient, completely altering tables' underlying structure and interdependencies. 

Data teams might restructure workflows, data models, and refactor SQL code to maximize performance and scalability. For example, a refactored migration might involve converting hundreds of stored procedures into dbt models to modernize workflows and improve scalability. This brings benefits including the ability to get rid of tech debt faster and quickly benefit from performance improvements in the new warehouse.

Refactoring (or rearchitecting) can be tempting as data engineers see it as a rare opportunity to fix technical debt and any inefficiencies that have accumulated over time in legacy systems. It’s hard to resist the chance to correct schema inconsistencies, improve naming conventions, and restructure pipelines to make future maintenance easier.

However, refactoring during a migration introduces significant costs and risks:

• Expanded migration timelines due to additional complexity
• Increased costs from bringing on skilled resources
• Trust issues as stakeholders may hesitate to sign-off on the migration if you can’t prove parity after rearchitecting

Another overlooked factor is the opportunity cost of time spent on a longer migration. Data team members are required to be active participants in refactored migrations since, surprise!, they know the data the best; to put it otherwise, you wouldn’t want consultants to be responsible for modifying tables that require considerable business context and knowledge. 

As a result, data teams are forced to dedicate heavy internal resources towards refactored migrations, instead of focusing on other often mission-critical data initiatives.

Lift-and-shift migration benefits 

We hinted at it already, but there is considerable cost, time, and people benefits to undergoing a lift-and-shift migration.

Decreased costs 

In many refactored migrations, both the legacy and new systems must run in parallel for months (maybe even years) as stakeholders validate data. When data teams undergo a lift-and-shift migration, they’re able to turn off (read: stop paying for) their legacy warehouse, since they’re “simply” lifting and shifting assets without major modification. 

This ultimately reduces the need to be paying for two data warehouses at the same time. For companies with on-premise systems or outdated warehouses, this means eliminating hefty licensing fees, hardware maintenance costs, and other overhead expenses. 

Reduced timelines

The timeline of data migrations is often expanded when stakeholders have a hard time “trusting” that the data in the new system is correct, especially if data is refactored in a rearchitected migration. As a result, data teams are forced to leave both legacy and new systems “on”, further increasing the financial cost of a migration. 

With lift-and-shift, data teams can prioritize speed. This is particularly critical for organizations facing tight external deadlines and pressures, such as compliance requirements or planned mergers. A faster migration also means data users can start using the new system sooner. For instance, analytics teams can start leveraging the improved performance and scalability of modern warehouses like Snowflake or Databricks almost immediately. 

Lower opportunity costs

Lastly, there are vital opportunity-cost benefits in pursuing a lift-and-shift migration; when a data team is forced to put considerable internal resources towards refactoring and improving code that requires business knowledge, they are naturally forced away from completing other innovative and important data work. 

While the opportunity-cost of a migration is often hard to quantitatively calculate, it’s an important factor to take into consideration when deciding on the appropriate migration strategy. Every hour spent on a migration is an hour not spent on innovation. With lift-and-shift, teams can minimize the trade-offs, allowing them to drive value elsewhere while still ensuring a successful transition. 

Earning stakeholder trust

Stakeholders often hesitate to approve migrations due to concerns about data accuracy and consistency. With a lift-and-shift approach, the data remains structurally similar to the legacy system, simplifying cross-database validation and reducing the risk of discrepancies. This familiarity makes it easier to build trust with stakeholders, accelerating the sign-off process and shortening migration timelines.

Lift-and-shift migration use cases

Lift-and-shift migrations are often suggested for data teams undergoing large-scale migrations, where migration resources may be limited, or there are major differences in SQL dialects.

Large migrations

When data teams have to migrate hundreds or thousands of tables, reworking the underlying and heavily interwoven code could take months or even years. With a lift-and-shift migration, tables are moved over first and then refactored for performance and scalability.

Lack of internal resources

If the data team has other pressing initiatives that need to be worked on in parallel, a lift-and-shift can be a much simpler migration strategy. With a lift-and-shift migration, the data team needs to aid in cross-database validation (which is greatly accelerated with the use of Datafold’s cross-database diffing capabilities!) instead of complex code refactoring that takes considerable time and resources.

Considerable SQL dialect differences between legacy and new systems

When there are large differences in SQL dialects between your legacy and new database, code translation in a refactored migration can take considerable time and resources. With a lift-and-shift migration, dialect nuances can be automated away with the use of a SQL translation tool; refactored migrations, on the other hand, require code to be manually written and modified, and the new SQL dialect must be understood in order to effectively write these new refactored models.

So what’s best for my team?

The paramount question for any data team undergoing or planning a data migration: to lift-and-shift, or refactor? Given the numerous costs and time-savings benefits to moving assets with slight modifications only, lift-and-shift is often a very appropriate strategy for teams undergoing large migrations. 

Furthermore, we know that in the age of AI and predictive analytics, data teams’ skills and time are constantly needed on new frontiers; with reduced focus on a data migration using the lift-and-shift methodology, the data team can expand resources on other business-critical data initiatives without sacrificing the quality of a migration.

At Datafold, we help data teams automate the most tedious parts of a migration with automated code translation and cross-database validation. If you’d like to learn more about the Datafold Migration Agent, please read more about it here.