DCF Research

Legacy Data Warehouse Modernization: Step-by-Step Strategy

By DCF ResearchEdited by Peter KorpakPublished · Updated

Modernize a legacy warehouse in waves. Take an inventory, choose a strategy for each workload (the same engine in the cloud, a move to a cloud warehouse, or a redesign), convert code with automated tools, and prove the new system matches the old before switching users. The risk sits in code conversion, validation, parallel running and BI repointing more than in moving the data.

This guide is part of our platform modernization research and covers Teradata, Netezza, Oracle and SQL Server warehouses.

Which strategy fits: lift and shift, replatform or re-architect?

Lift and shift keeps the database engine and moves it to the cloud. Replatform moves the workload to a different engine and converts the code. Re-architect also redesigns the data model and pipelines. Choose per workload: AWS's guidance for large migrations recommends rehosting or replatforming first and modernizing afterward, because refactoring during the move is the hardest option to manage.

StrategyWhat changesFits whenMain risk
Lift and shift (same engine in the cloud)Hosting moves; SQL, schemas and ETL stay largely as they areA hard deadline such as hardware retirement or a data center exit; code too risky to convert; a few well-designed warehousesYou keep the legacy design debt, licensing model and skills
ReplatformThe workload moves to a cloud warehouse or lakehouse; SQL, procedures and loaders are converted; the data model mostly staysYou want cloud elasticity without redesigning every model, and can run the program in wavesConversion edge cases, performance tuning, proving parity
Re-architectNew data model, ELT patterns, ownership by domain, possibly streaming or a lakehouse (see our lakehouse guide)The warehouse is poorly structured or full of unused objects; new AI or real-time needsLongest path; scope creep; business-rule disputes surface

Same-engine cloud options exist for the main legacy platforms. Teradata says it runs on AWS, Azure and Google Cloud. Oracle offers Exadata Database Service in OCI and in AWS, Azure and Google Cloud data centers. IBM sells Netezza Performance Server as a managed service on AWS and Azure. Microsoft's Synapse-to-Fabric guidance offers a practical test for lift and shift: a small number of warehouses, data already in a well-designed star or snowflake schema, and time or cost pressure.

Deadlines can force the choice. Microsoft's lifecycle page lists the end of extended support for SQL Server 2016 in July 2026, with paid Extended Security Updates for up to three years after.

Whatever the strategy, check usage logs for tables, jobs and reports that nobody queries, and retire them before converting anything.

How should you sequence a warehouse migration?

Migrate in waves by use case. Start with one small end-to-end workload that proves the method, and keep the old system as the reference until each use case is accepted. Google's and Microsoft's warehouse migration guides both describe iterative waves with a pilot first.

  1. Inventory and assess. List tables, views, procedures, ETL jobs, schedules, reports and their consumers, with usage data and dependencies.
  2. Choose a strategy per workload and the target platform. Our cloud data platform migration guide covers the target decision.
  3. Build the foundation: accounts or subscriptions, identity, network, roles and masking rules, cost tags, deployment pipelines.
  4. Pilot one end-to-end use case: convert code, load data, validate, repoint the reports. Microsoft describes a first workload of 1 to 10 TB as typical. Record effort per object to calibrate the rest of the plan.
  5. Define "done" before each use case starts. Google's checklist is integrated, tested and documented; add sign-off by the business owner.
  6. Run waves by business domain, each with its own validation and parallel-run period.
  7. Cut over, keep the old system read-only as a fallback for an agreed period, then decommission it and end the contracts.
  8. Tune cost and performance once the new platform carries production. The data platform TCO guide shows the cost lines to track.

Which vendor tools convert your code?

Each platform vendor publishes a conversion tool and lists the sources it supports. Check your source before assuming automation. A dash means the source is not listed on the page we checked, not that it is unsupported.

SourceSnowflake SnowConvert AIBigQuery Migration ServiceAWS Schema Conversion Tool (to Redshift)Databricks LakebridgeFabric Migration Assistant
TeradataTables, views, procedures, functions, BTEQ, MultiLoad, TPumpListedVersion 13 and higher, plus BTEQ, FastLoad and MultiLoad scriptsListedMetadata, preview
NetezzaTables and viewsListedVersion 7.0.3 and higherListed-
OracleTables, views, procedures, functions, packagesListed, including ExadataVersion 10.1 and higherListed-
SQL ServerTables, views, procedures, functions-Version 2008 and higherListedListed

Tools convert syntax and flag the rest. SnowConvert AI reports differences as errors, warnings and issues for manual or AI-assisted fixes, and AWS says schema it cannot convert automatically comes with guidance instead. Microsoft states that Fabric Data Warehouse does not have full T-SQL compatibility with its sources.

What are the main risks, and how do you control them?

The main risks are converting code, proving the data matches, running two systems in parallel, and repointing reports. Each has a known control.

RiskWhy it happensControls
Code conversionProcedural code, scripts and vendor-specific SQL do not map one to one; tools convert part and flag the restRun the assessment tool on the whole codebase; measure the conversion rate on a sample of your own code; budget manual rework per object; test each converted object against source results
Data validationType differences, rounding, time zones and NULL handling cause silent mismatchesAutomate row counts, column aggregates, schema checks and row-level comparisons after every load. Google's open-source Data Validation Tool, AWS DMS validation and Lakebridge's reconcile component are examples; agree tolerances in writing
Parallel runTwo systems cost money, and short runs miss period-end behaviorSet exit criteria first. We recommend covering at least one full close for the reports finance relies on. An AWS write-up of a 270 TB Netezza-to-Redshift program says business validation took around three months
BI repointingReports embed legacy SQL, custom connections and cached extractsInventory reports and their SQL; compare report output before and after (one partner case study describes automated comparison of 1,500 MicroStrategy reports); train users before cutover
ETL and schedulingInformatica, DataStage or SSIS jobs and schedulers must be converted or repointed in step with the dataConvert pipelines by wave with their targets; AWS's tool lists SSIS-to-Glue and Teradata script conversions, or keep the ETL tool and repoint its targets first
Program slippageScope, dependencies and team availability moveIn McKinsey's 2020 to 2021 survey of cloud migrations of all kinds, the average company spent 14% more than planned each year and 38% of companies saw delays of more than one quarter; hold contingency and track progress by object

How long does a data warehouse migration take?

Public case studies report 3 to 10 months for scoped programs. Elapsed time depends more on how many code objects need manual work and how long validation runs than on data volume. As an estimate, plan 6 to 12 months from kickoff to decommissioning for a mid-sized warehouse.

Source and targetScope as publishedDuration as publishedPublisher (year)
Teradata to Snowflake on AWS3 data marts, nearly 500 TB, 300 to 400 tables3 monthsBlazeclan (2023)
Netezza to SnowflakeTerabytes of data; thousands of DataStage workflows repointed3 monthsAimpoint Digital
Netezza and ETL to SnowflakeMore than 600,000 lines of code; thousands of ETL pipelines6 months (24-week engagement)Next Pathway
Teradata to Snowflake2 PB across 12 databases; 700+ queries8-month engagementHakkoda (2024)
Teradata to Azure SQL Data WarehouseNot stated9 monthsHexaware (2020)
Teradata to Snowflake50+ TB10 monthsLTM (2025)

Each row is the delivering firm's own account, and DCF Research has not verified any of them. They are selected success stories, so read them as best cases.

The effort that drives elapsed time can be estimated from your inventory. Estimate: suppose 3,000 code objects and an automated conversion that leaves 30% needing manual work (an assumption; results vary with source dialect and coding style). That is 900 objects. At 6 hours each (assumption) the manual work is 5,400 hours. A team of 6 engineers at 120 productive hours a month each (assumption) delivers 720 hours a month, so conversion takes 7.5 months. At 10% manual work the same arithmetic gives 300 objects, 1,800 hours and 2.5 months. Measure the real rate on your code sample before you commit to a date.

The 6 to 12 month range is a DCF Research estimate. Its basis is the 3 to 10 months published above, which mostly describe the migration program and may exclude assessment and a fallback period, plus the three-month validation phase in AWS's Netezza write-up. Estates with tens of thousands of objects or many source systems will run longer; plan them as several waves or programs.

What should you require from a migration partner?

Require a written assessment of your own codebase, a conversion rate measured on a sample of your code, a validation plan with evidence for each wave, a named team, and commercial terms tied to acceptance. Then check credentials in the vendors' own directories.

  1. Assessment first. An object inventory, dependency map, usage data, proposed waves and a risk list before a fixed price.
  2. Measured automation. Ask what "automated" means and for the rate on your sample. Published claims range from 60% automation in LTM's Teradata case study to 100% translation in Next Pathway's Netezza case study, and the definitions differ.
  3. Validation evidence per wave: row counts, aggregates, row-level comparisons, report output comparisons and signed-off exceptions.
  4. Parallel run and rollback: duration tied to business cycles, written exit criteria, a rollback plan.
  5. BI scope: who rewrites custom SQL and who tests with business users.
  6. Named team and continuity: who leads, team size and location, key-person and subcontractor terms.
  7. Commercials: fixed fee or capped time and materials by wave, acceptance tied to validation evidence, change control, knowledge transfer, ownership of accelerators.
  8. References: two customers with a similar source, target and size whom you can call. Published case studies are firm-reported.

Our RFP template turns these into questions.

Vendor directories show program status. Snowflake's partner directory shows Select, Premier and Elite badges. AWS's Migration and Modernization Competency is open only to Advanced and Premier tier services partners. Microsoft's Data Warehouse Migration to Microsoft Azure specialization requires a third-party audit. Google Cloud's partner program shows Select, Premier and Diamond tiers plus competencies. Databricks' directory tags consulting partners with regions and solution areas rather than Select, Premier or Elite badges.

As examples of what the directories show (checked October 2026): Snowflake's directory lists Slalom, Cognizant and Infosys with an Elite badge and HCLTech with a Premier badge. Databricks' directory tags Accenture, Capgemini, Slalom, Tredence and Wipro, among others, with a Data Warehouse Migrations solution area. A badge or tag says nothing about results on a warehouse like yours, and DCF Research has not audited client projects.

Frequently asked questions

Which legacy warehouse is hardest to migrate?

There is no reliable ranking by vendor. Difficulty follows the amount of procedural code, vendor-specific scripts and ETL you have, and how well your target's tools cover them. Coverage differs: SnowConvert AI's documentation lists Teradata scripts and Oracle packages, but lists Netezza conversion for tables and views only. Run an assessment on your own code before comparing.

How do we budget the project?

Build it bottom-up from the inventory: objects by complexity times effort per object, plus validation, parallel running, BI rework and the old platform's running cost during the overlap. Get at least two partner estimates built from the same inventory so they can be compared.

What if we cannot finish before the legacy contract ends?

Ask the vendor for a short extension or a month-to-month term early, and sequence the waves so the objects with the longest validation run first. A same-engine move to the cloud can serve as a bridge when the deadline is fixed.

Sources

More in Platform Modernization

← Back to Insights