Key Takeaways
A data warehouse migration to AWS means moving your data, your tables, and the code that runs your reports onto Amazon Redshift. Moving the data is the easy part. Moving the code is what decides the project.
- The main tool changed. AWS used to point you to a download called SCT. It now points you to DMS Schema Conversion, which runs in your browser and uses AI to translate old database code for you, up to 90% of it.
- Three AWS tools are being switched off, and most guides still recommend them. Snowball Edge closed to new customers on 7 November 2025, DMS Fleet Advisor ended on 20 May 2026, and Redshift stopped running Python functions after 30 June 2026.
- How long it takes depends on how much custom code you have, not how much data. A 40 TB warehouse with 200 stored procedures takes roughly 14 weeks.
- Check your numbers three ways after the move. Count the rows, check the tables, then run the same report on both systems and compare the answers. Only that last check catches code that runs without any error but returns the wrong number.
Introduction
Moving the data is the easy part. The hard part of a data warehouse migration to AWS is the business logic buried in stored procedures and whether it survives the move.
Picture a 40 TB Teradata warehouse. 600 tables, 200 stored procedures, 120 live reports, a nightly batch that keeps finishing late. This is the migration most teams are actually facing, so it is the one we will plan, start to finish.
One thing to settle first. The AWS toolchain changed over the past year, and most migration plans are still built on tools that no longer exist. Here is the project, on the current tools, in 14 weeks.
What Is Data Warehouse Migration to AWS?
A data warehouse migration to AWS moves analytical workloads, schemas, ETL pipelines, and history from a legacy platform onto AWS services, usually Amazon Redshift.
It gets confused with two other things. Cloud migration moves applications and infrastructure. Database migration moves transactional systems. A data warehouse migration to AWS moves analytical workloads and the reporting built on them.
The difference matters. Moving a transactional database is a data problem. Moving a warehouse is a logic problem: decades of business rules sit in stored procedures and old SQL, and they have to keep working afterwards.
Why Enterprises Move a Legacy Data Warehouse to Amazon Redshift
In older warehouses, storage and compute are locked together. To add storage, you buy a compute that you do not need. When query volume rises, you get timeouts and late ETL jobs, not more capacity. Licence costs climb with data volume whether or not that data earns its keep. An IDC study put three-year ROI on Amazon Redshift at 503% with a 10-month payback, though it predates current Redshift pricing.
Then there is what you cannot do at all. Real-time ingestion, ML training, and querying a data lake next to the warehouse do not bolt onto fixed capacity. Redshift Spectrum queries S3 directly, and RA3 scales compute separately from storage. Governance gets simpler too, since Redshift and Lake Formation sit in scope for SOC, PCI DSS, and ISO 27001.
The AWS Data Warehouse Migration Toolchain in 2026
This is where most guides on data warehouse migration to AWS are out of date. Five things are different now.
AWS SCT is the old path. AWS documentation points you to DMS Schema Conversion and calls the downloadable tool the legacy option. It runs in the browser, inside the DMS console, on the same engine.
Generative AI conversion changed the hardest phase. Alongside the rule-based pass, DMS now runs an AI pass at the objects rules cannot resolve, and AWS puts the ceiling at 90% for procedural code. On a 200-procedure warehouse, that is the difference between rewriting and reviewing.
Snowball Edge is closed to new customers. Since 7 November 2025 only existing accounts can order one, so any plan built around a device on a loading dock is broken. What is left is DataSync over the network, Direct Connect for dedicated bandwidth, and Data Transfer Terminal if the volume truly will not move.
DMS Fleet Advisor is going away. AWS ends support on 20 May 2026, so discovery now runs on DMS assessment reports and your own source tooling.
One more deadline catches teams out. Redshift ends Python UDF support after 30 June 2026, and new ones cannot be created. Converted BTEQ and macro logic often lands in Python UDFs, so plan for Lambda UDFs instead.
Everything else holds. Redshift is the target, Glue rebuilds ETL, and DMS Serverless removes replication-instance sizing from the critical path.
Which AWS Migration Strategy Fits a Legacy Warehouse
AWS frames cloud moves through the 7 Rs, and for a data warehouse migration to AWS five are dead ends. Retire and Retain mean no migration. Relocate and Repurchase have no warehouse equivalent. Rehost is the tempting one and the wrong one, because a Teradata schema dropped onto Redshift carries design choices Redshift handles badly, so you pay cloud prices for on-premises speed. That leaves Replatform and Refactor.
Underneath that, every data warehouse migration to AWS picks an execution pattern:
- One-step works for small warehouses that can take downtime. Extract, load, validate, switch.
- Two-step adds change data capture, so the old warehouse stays live while you migrate. The default at production scale.
- Wave-based splits a large warehouse into subject areas migrated in sequence. Less risk, more elapsed time.
Our 40 TB warehouse gets two-step with waves. CDC keeps Teradata authoritative until the end, and subject areas move one at a time.
Planning a warehouse move you cannot afford to get wrong?
Our AWS migration services team runs the schema conversion, validation, and cutover so the migration is not the thing that slips.
The 14-Week Data Warehouse Migration to AWS Plan, Phase by Phase
Fourteen weeks, four phases, and a gate at the end of every one. Treat the weeks as a shape, not a schedule. Fewer stored procedures and the middle phases clear quicker. The order is what you cannot rearrange. Every gate you wave through is a defect you meet again at cutover.
Weeks 1 to 3: Discovery, Assessment, and Redshift Sizing
Every data warehouse migration to AWS starts here. Catalogue the table sizes, stored procedures, BTEQ scripts, ETL dependencies, the reports people open, and the queries people run. Pull that last one from source logs, not docs.
Then decide what not to migrate. In a 600-table warehouse, much of it is dead or duplicated. Every table you drop is one you never convert, move, validate, or pay for.
Run a DMS assessment report to score the conversion, then size Redshift against concurrency.
Exit criteria: inventory signed off, wave order agreed, RA3 node type chosen.
Weeks 4 to 7: Schema Conversion with DMS and Gen-AI Assistance
This phase decides the data warehouse migration to AWS. Run DMS Schema Conversion across the source schema. The rule-based pass clears the straightforward objects. The AI pass then takes on the stored procedures, macros, and BTEQ logic that rules cannot handle.
Some things still need a person:
- Teradata data types with no Redshift equivalent: PERIOD, INTERVAL, BYTE
- SET tables and multi-column primary indexes, remapped to distribution and sort keys
- Macros, BTEQ, and exception handling, since a Redshift procedure allows one exception block
- Hard-coded schema references across the reporting layer
Coming from Oracle or SQL Server instead? Same phases, different pain. Oracle gives you PL/SQL packages. SQL Server gives you T-SQL and identity columns. Conversion rates run higher than Teradata, but the validation work does not.
Now design the target properly. Distribution keys follow real join patterns, sort keys follow real filters, WLM queues follow real priorities. Teams skip this and pay for it in week 13. Clean the data before you move it, too: deduplicating 40 TB once 120 reports are live costs far more.
Exit criteria: schema applied, conversion items closed, distribution and sort keys signed off.
Weeks 8 to 11: Data Transfer, CDC, and ETL Pipeline Rebuild
A data warehouse migration to AWS sets up the target first: IAM roles, VPC, encryption, Secrets Manager. Then the two-step. DMS does a full load into an S3 staging bucket and issues COPY commands into Redshift. Once that lands, CDC streams changes so Teradata stays the source of truth until cutover.
In a 2026 data warehouse migration to AWS, the transfer goes online, over DataSync or Direct Connect. That is not a preference: the offline device route most guides recommend is closed to new AWS customers.
Meanwhile, rebuild ETL on AWS Glue and register governance in Lake Formation. Do not port the old orchestration across. It was built for the system you are leaving.
Exit criteria: full load complete, CDC lag stable, Glue pipelines running on real schedules.
Weeks 12 to 14: Data Validation, Cutover, and Rollback
Validation on a data warehouse migration to AWS has three layers. Most teams stop at the first:
- Row counts, source against target
- Checksums on every migrated table
- Query-result diffing: run the same business query against Teradata and Redshift, then compare the answers
The third layer saves you. A converted stored procedure can run perfectly and still return a different number. Only comparison catches it.
Then run UAT against the real 120 reports, benchmark against the old SLAs, and cut over in a planned window with snapshot rollback ready.
Exit criteria: all three layers passed, UAT signed off by report owners, rollback tested rather than assumed.
Where Data Warehouse Migrations to AWS Actually Slip
Four things reliably slip in a data warehouse migration to AWS. Schema conversion gets under-budgeted, because even at 90% automated conversion the last 10% of a 200-procedure warehouse is 20 procedures of dense, undocumented logic. Budget weeks for it.
Discovery gets run off documentation. Documentation describes the warehouse someone designed, while query logs describe the one people use. The two differ, and the gap shows up in UAT.
UAT gets treated as a formality. Report owners are the only people who can tell you a number is wrong. Give them real reports and real time.
Costs land higher than the model. Badly chosen distribution keys move data on every join, and the bill arrives before the tuning.
If nobody has sized an RA3 cluster or tuned WLM queues before, fix that early. Amazon Redshift developers who have done it cost less in week 6 than a diagnosis in week 14.
Conclusion
Moving the data is the easy part, and DMS handles it. The project lives or dies on whether thirty years of business logic still returns the same numbers.
What breaks a data warehouse migration to AWS is rarely difficult. It is starting the next phase before the last one finishes.
So plan against the 2026 tools. Budget schema conversion honestly. Validate in three layers. And if your team is carrying this on top of a full delivery load, data warehouse services exist so the migration is not the thing that slips.
Frequently Asked Questions (FAQs)
A mid-sized data warehouse migration to AWS usually takes 12 to 16 weeks. A 40 TB warehouse with 600 tables and 200 stored procedures runs about 14 weeks: 3 weeks discovery, 4 schema conversion, 4 data transfer, 3 validation and cutover. Timelines scale with stored-procedure complexity, not data volume.
No. AWS now recommends DMS Schema Conversion, a managed browser-based feature inside AWS DMS, and calls the downloadable AWS Schema Conversion Tool the legacy option. It uses the same engine and adds generative AI conversion, which handles up to 90% of complex objects including stored procedures and triggers.
Only as an existing customer. AWS closed Snowball Edge to new accounts on 7 November 2025. A data warehouse migration to AWS now moves data over the network with AWS DataSync, across dedicated bandwidth with AWS Direct Connect, or physically through an AWS Data Transfer Terminal.
Only two of them. Retire and Retain mean no migration happens, while Relocate and Repurchase have no warehouse equivalent. Rehosting a legacy schema onto Amazon Redshift preserves assumptions Redshift does not share, which raises costs and slows queries. Replatform and Refactor are the strategies that pay back.
Six do the work. Amazon Redshift receives the warehouse. DMS Schema Conversion translates schemas and procedural code, DMS moves the data and runs change data capture, DataSync or Direct Connect carries it across the wire, AWS Glue rebuilds the ETL, and Lake Formation governs the lake around it.
