Lift and shift vs modernizing your data warehouse
If you are migrating a data warehouse, there is a question worth asking before you start: should you recreate the existing solution on the new platform, or use the move to make it better? This applies whether you are moving from an on-premises Netezza system to Microsoft Fabric or from Azure Synapse Analytics to Fabric. My preference is to modernize during the migration when the business case and timeline support it. Even a conservative migration takes substantial work, so it is worth considering which additional improvements would make that investment more valuable for years to come.
First agree on what you are moving
Lift and shift usually means moving a solution with as few changes as possible. In its strictest form, that is rehosting, such as moving a database server to a cloud virtual machine while keeping the same database engine and application design. With warehouses, people also use the phrase to mean preserving the existing data model and processing logic while changing platforms. A Netezza-to-Fabric migration falls into that broader conversation, but it is not the equivalent of moving a virtual machine. Keeping the design does not eliminate the work of making it run on a different technology.
Replatforming is the middle ground: change the underlying platform and make targeted adjustments while preserving much of the solution. Modernization can go further, through refactoring code or re-engineering the architecture, such as simplifying data pipelines, consolidating business logic, or redesigning how data is organized and consumed. These are choices along a spectrum, and a single migration can combine them. A phased approach determines when you make the changes and can incorporate any of these strategies. Microsoft’s migration framework distinguishes these approaches, which is useful when agreeing on scope with your team. Before approving a project called “lift and shift,” make sure everyone understands what that label actually includes.
The pros and cons
| Approach | Pros | Cons |
|---|---|---|
| Lift and shift | Often faster, with lower initial engineering costs; less redesign; preserves familiar business behavior; helps meet a deadline. | Still requires migration and testing; an unchanged design may fit the destination poorly, retain avoidable costs, and require later rework. |
| Replatforming | Delivers selected improvements; can reduce infrastructure work; limits the scope of change. | Compatibility work remains; some technical debt survives; requires clear boundaries to control scope. |
| Re-engineering and modernization | Can simplify operations, improve performance, and make future changes easier; addresses underlying problems. | More initial effort, skills, and business involvement; greater delivery risk; potential for overengineering. |
| Phased modernization | Delivers improvements in manageable increments; allows learning and adjustment; can accommodate deadlines. | Temporary overlap between systems; additional coordination and reconciliation; later phases need committed funding. |
Even lift and shift takes time
A warehouse is much more than its tables. You have data ingestion, transformation logic, scheduled jobs, security, reporting connections, and business definitions that may be scattered across several tools. Consider a hypothetical sales warehouse where a stored procedure calculates revenue, a pipeline applies currency conversions, and a report contains another adjustment that finance depends on. Copying just the tables would leave much of that solution behind. Before moving it, you need to discover those dependencies, understand their purpose, and decide how they will work in the destination. This is also an opportunity to identify and eliminate anything that is no longer used or needed, such as obsolete tables, unused reports, outdated jobs, and redundant transformation logic. There is little value in spending time and money migrating something that serves no purpose. That investigation takes time, even when your goal is to preserve the existing behavior, but it can also simplify the solution and reduce migration effort.
Then you have to prove the migrated solution works. I would want validation that goes beyond matching row counts: do revenue totals reconcile, do historical reports produce the expected results, and do updates and deletes flow through correctly? Test performance under representative usage, verify access permissions, and rehearse the cutover and recovery plan. Migration tools can help with tasks such as schema conversion and data movement, but successful copying does not establish that every business rule remains correct. The business needs confidence in the reports it will use after the move, and building that confidence is part of the migration.
Why I lean toward modernization
Once you understand the system, have the right people involved, and are already testing its behavior, you have a useful opportunity to improve it. Why recreate an unnecessarily complicated loading process if you can simplify it during the move? Why preserve three implementations of the same business rule when one governed definition would be easier to maintain? These are decisions to evaluate while the relevant knowledge is available. The argument is about the additional value of doing selected improvements now, compared with organizing a separate project later and continuing to live with the problems in the meantime.
The goal should be a solution that is easier to operate and change over its remaining useful life. That might mean reusable pipelines, documented definitions, automated deployments, better data quality checks, or clearer ownership when something fails. Define outcomes you can measure, such as more reliable refreshes, less manual intervention, or less time to add a new data source. A new platform does not guarantee lower costs or better performance, so validate those expectations with representative workloads. No architecture lasts forever, but making the solution understandable and adaptable gives the next change a much better starting point.
That does not mean modernization is just a small extension to every migration. Replacing a mature data model, changing ingestion patterns, and rebuilding reports can introduce substantial extra work, require new skills, and expose business rules nobody fully understands. Adopting too many services can also create new dependencies and make operations more complicated. I would test the proposed design with a representative workload before committing to a large rollout, and involve the business in approving intentional changes to its definitions. Spending more makes sense when the expected improvement justifies the effort and risk; how much you have already spent is not enough of a reason.
What this looks like in practice
Imagine a company moving its Netezza warehouse to Fabric. The conservative approach would preserve its dimensional model and business outputs while adapting the implementation for the destination. A modernization approach might keep that same useful model but consolidate duplicated transformations, improve incremental loading, and remove obsolete intermediate datasets after checking their dependencies. The first step would be assessing source-specific SQL, procedures, data types, and integrations against the chosen Fabric workload. The important question is which changes solve an actual problem. A sound star schema does not become outdated simply because you are moving to a newer platform.
Now consider moving an Azure Synapse Analytics dedicated SQL pool to Fabric Warehouse. You are already in the cloud, but you are still changing technologies, and shared SQL terminology does not guarantee identical behavior. Microsoft’s Synapse-to-Fabric planning guidance identifies differences in SQL syntax, data types, and physical design that need assessment. You could preserve a well-designed model while improving the processes around it. This is a good example of why modernization should be selective: retain the parts that serve the business well and spend your effort on the parts that create unnecessary work or limit future requirements.
When the deadline makes the decision harder
I understand why a company facing an end-of-support date might prioritize getting onto a supported platform quickly. Suppose a hypothetical warehouse must leave its current environment within six months, while the proposed redesign cannot be delivered safely in that window. A smaller initial migration can be a sensible decision, provided it actually addresses the deadline and support requirements. Moving unsupported database software to a cloud virtual machine, by itself, does not change the software version or its support status. Confirm whether the deadline concerns hardware, database software, a hosting contract, or the entire environment before selecting the fastest viable path.
The part I would challenge is “we will modernize later” without a concrete commitment. Once the migration is finished, new priorities can compete for the same people and budget, and the temporary design may remain longer than anyone intended. If modernization is phase two, give it an owner, funding, scheduled milestones, and measurable outcomes before phase one begins. Record which problems you are deliberately carrying forward and what their ongoing cost will be. A second phase also needs its own testing and coordination, so compare the total effort of both phases with the effort of making selected improvements during the initial move.
A practical middle ground
You do not have to choose one strategy for the entire warehouse. I would start with a manageable business area, such as sales reporting, and move enough of its ingestion, transformation, and reporting processes to test the complete flow. Keep stable components where they fit, replatform where targeted changes help, and redesign the parts with a clear business benefit. Use what you learn to plan the next area, while accounting for shared dimensions and dependencies. During the transition, make it clear which system is authoritative for each dataset or report, and retire the old components once their replacements are accepted.
Keep the modernization scope disciplined, too. A migration does not have to include a new modeling methodology, a different programming language, and every feature available on the destination platform. Estimate the additional work for each proposed improvement and weigh it against the expected benefit, the deadline, and the team’s ability to maintain it. Include engineering, running both environments during the transition, training, ongoing operating costs, and delayed benefits in the comparison. The same principle applies to transactional databases, although their target must support the application’s transaction and operational requirements. Microsoft’s Fabric data store decision guide distinguishes transactional databases from analytical warehouses; choose the service that fits the workload rather than assuming one destination serves every database.
Make the migration worth the effort
My recommendation is to evaluate modernization before you settle on lift and shift. You may discover that a targeted set of improvements is worth the additional effort, especially for a warehouse the business expects to rely on for many years. You may also find that a stable solution approaching retirement deserves only the changes needed to keep it running. When a hard deadline requires moving first, make the follow-up work an explicit part of the plan. Ask what will be better for the people using and maintaining the solution after the migration, and make those improvements part of how you define success.
More info: