{"id":1818,"date":"2019-01-07T00:00:00","date_gmt":"2019-01-07T00:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/blog\/teradata-to-azure-sql-data-warehouse-migration-guide"},"modified":"2025-06-09T05:06:10","modified_gmt":"2025-06-09T12:06:10","slug":"teradata-to-azure-sql-data-warehouse-migration-guide","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/teradata-to-azure-sql-data-warehouse-migration-guide\/","title":{"rendered":"Teradata to Azure SQL Data Warehouse migration guide"},"content":{"rendered":"\n

With the increasing benefits of cloud-based data warehouses, there has been a surge in the number of customers migrating from their traditional on-premises data warehouses to the cloud. Microsoft Azure SQL Data Warehouse (SQL DW) offers the best price to performance when compared to its cloud-based data warehouse competitors. You can either migrate Teradata stacks to Azure via Azure Marketplace<\/a> and with Intellicloud on Azure <\/a>or migrate to Azure Datawarehouse.<\/p>\n\n\n\n

The Teradata to SQL DW migrations involve multiple steps. These steps include analyzing the existing workload, generating the relevant schema models, and performing the ETL operation. The intent of this discussed whitepaper is to provide guidance for these aforesaid migrations with emphasis on the migration workflow, the architecture, technical design considerations, and best practices.<\/p>\n\n\n\n

Migration Phases<\/h2>\n\n\n\n
\"Migration<\/figure>\n\n\n\n

The Teradata migration should pivot on the following six areas. Though recommended, proof of concept is an alternative step. With the benefit of Azure, you can quickly provision Azure SQL Data Warehouses for your development team to start business object migration before the data is migrated and speed up the migration process.<\/p>\n\n\n\n

Phase one \u2013 Fact finding<\/h3>\n\n\n\n

Through a question and answers session you can define what your inputs and outputs are for the migration project.<\/p>\n\n\n\n

Phase two \u2013 Defining success criteria for proof of concept (POC)<\/h3>\n\n\n\n

Taking the answers from phase one, you identify a workload for running a POC to validate the outputs required and run the following phases as a POC.<\/p>\n\n\n\n

Phase three: Data layer mapping options<\/h3>\n\n\n\n

This phase is about mapping the data you have in Teradata to the data layout you will create in Azure SQL Data Warehouse. Some of the common scenarios are data type mapping, date and time format, and more.<\/p>\n\n\n\n

Phase four \u2013 Data modeling<\/h3>\n\n\n\n

Once you\u2019ve defined the data mappings, phase four concentrates on how to tune Azure SQL Data Warehouse. This provides the best performance for the data you will be landing into it.<\/p>\n\n\n\n

Phase five: Identify migration paths<\/h3>\n\n\n\n

What is the path of least resistance? What is the quickest path given your cloud maturity? Phase five helps describe the options open to you and then for you to decide on the path you wish to take.<\/p>\n\n\n\n

Phase six: Execution of migration<\/h3>\n\n\n\n

Migrating your Teradata data to SQL Data Warehouse involves a series of steps. These steps are executed in three logical stages, preparation, metadata migration, and data migration.<\/p>\n\n\n\n

Migration solution<\/h2>\n\n\n\n

To ingest data, you need a basic cloud data warehouse setup for moving data from your on-premise solution to Azure SQL Data Warehouse, and to enable the development team to build Azure Analysis Cubes once the majority of the data is loaded.<\/p>\n\n\n\n

\"Migration<\/figure>\n\n\n\n