Choose the Right Migration Strategy

Ask any seasoned data practitioner about migration strategies, and you’ll spark a debate worthy of a superhero council. Should you lift-and-shift—moving everything as-is to the new system—or use the opportunity to rearchitect workflows and slay the technical debt villains lurking in your legacy systems?

We’ve seen firsthand how lift-and-shift can accelerate timelines, reduce risk, and deliver results faster. But we also recognize that no two migrations are alike. The "best" strategy depends on your constraints, goals, and appetite for complexity. The key is to understand the tradeoffs so you can choose the strategy that aligns with your team’s needs, whether it’s speed, simplicity, or transformation.

The case for lift-and-shift: A swift rescue mission

Lift-and-shift focuses on moving data and workflows as-is to the new system before making incremental improvements. This is straightforward; you just want the new system to produce the exact same results as your legacy one. 

This offers three clear advantages:

1. Speed

Long migrations increase risk. The longer your legacy and new systems run in parallel, the more time, resources, and confidence you burn. Lift-and-shift prioritizes speed by focusing on the essentials—moving the data—and leaves optimizations for a calmer time post-migration.

2. Simplifying validation

Lift-and-shift gives you a clear comparison point. Validation is hard enough without introducing extra complexity. When you change both the where (system) and the how (logic) simultaneously, every discrepancy becomes a riddle: was it caused by the move or the refactor? By moving workflows as-is, you ensure clean, comparable outputs and fewer headaches.‍

‍

‍

3. Reduces scope creep

A migration is a tempting window to refactor years of technical debt. But trying to "fix everything" partway through can lead to overwhelming and conflicting priorities. Focus first on delivering a working system quickly.

In general, doing multiple complex things simultaneously usually makes each thing more difficult and risky. And that’s true for data migrations.

Lift-and-shift doesn’t solve inefficiencies; you're essentially carrying forward your technical debt, and you might miss opportunities for immediate optimization. If your legacy workflows are slow or messy, those problems will carry over to the new system. Plan for a cleanup to address technical debt at some point after the migration. 

The case for architecting: A fresh start, but at a cost

The alternative approach is using your migration as an opportunity for comprehensive improvement. After all, if you’re already undertaking a big and painful project like a data migration, it’s reasonable to want to maximize what you’re going to get out of it. 

By rewriting workflows and fixing inefficiencies during the migration, you can ensure that the new system performs better and aligns with modern data practices.  It’s the superhero equivalent of upgrading your powers mid-mission.

Rearchitecting can deliver three benefits:

1. Cleaner workflows

Legacy workflows often rely on tightly coupled, brittle SQL or stored procedures designed for constrained, on-prem or legacy systems. These scripts are hard to maintain or troubleshoot. 

So it becomes essential to the migration to break complex workflows into modular, version-controlled components (e.g., dbt models), or adopt declarative pipelines and transformation layers. 

2. Performance gains

If you lift-and-shift workflows wholesale without optimizing, you might find yourself paying more for compute while seeing little-to-no performance improvement. 

Many legacy SQL queries and ETL processes were written with on-prem resource constraints in mind—batch processing overnight, serial operations, or inefficient loops were necessary tradeoffs. But these become irrelevant in the move to cloud platforms, which offer elastic scalability (scaling compute and storage independently on demand) and parallel execution (distributing workloads across clusters). 

The whole point of the migration is rendered moot if you don’t rewrite queries to leverage parallel processing natively or replace bottlenecks like stored procedures with optimized workflows. 

3. Reducing technical debt

Technical debt will always be with us. Code rot, outdated SQL logic, and poorly optimized transformations pile up over time–especially in legacy systems. Most ways of tackling technical debt are incremental: you chip away at inefficiencies one pull request at a time while balancing improvements against the demands of new features or fixes. It’s slow, deliberate work. 

A migration lets you tackle this at scale. You’re already uprooting workflows and systems, which means you can finally address inefficiencies at their root. And there’s a compelling business case to do so since cloud platforms charge based on usage. Inefficient queries and transformations that seemed "good enough" on-prem can spiral into unpredictable costs in the cloud.

Making the right choice requires making tradeoffs explicit

Choosing between lift-and-shift and rearchitecting comes down to your team’s constraints and goals. Ask yourself:

• What’s your timeline? Can you afford to slow the migration to modernize workflows, or do you need a fast cutover?
• What’s your resource capacity? Do you have the engineering bandwidth to rearchitect workflows, test changes, and resolve new issues?
• What’s the impact of carrying over technical debt? Will inefficiencies hurt the new system’s performance enough to justify fixing them now?

For most teams, lift-and-shift is the pragmatic choice. It simplifies the process, minimizes risk, and delivers results faster. By moving workflows as-is, you can focus on validation and stakeholder alignment, leaving optimization for a less pressured phase.

That said, rearchitecting can be the right choice for teams with the time, resources, and expertise to pull it off. It’s the strategy for teams who want to leave inefficiencies behind and embrace modern practices from day one.

Our advice? Align strategy to your goals

At Datafold, we advocate for lift-and-shift as the default strategy for most teams. Why? Because it simplifies the process. By moving workflows as-is, you:

• Deliver results faster
• Minimize risk during validation
• Keep stakeholders aligned and confident

It’s the pragmatic middle ground approach that allows teams to stay focused, realize the benefits of the new platform, and the option to optimize later in a less pressured environment is always there. 

Successful rearchitecting requires deep business domain knowledge, which often means heavy involvement from your most experienced team members. If these key people are needed for other strategic initiatives, lift-and-shift might be the only practical option.

But we also know that every migration is different. If you have the time, resources, and strong justification for rearchitecting mid-migration, it can be the right choice—as long as you have a plan to validate outputs and resolve discrepancies.

‍