Are you looking to migrate content from Teradata to Azure SQL on the cloud? In today’s post I’ll share what you need to know to make your migration project successful.
Before any migration project, there are certain steps that organizations should do first. Like any other SDLC project, you should start with requirements gathering, fact finding and identifying your business rules. These are all important to ensure successful migration to your destination repository.
In some cases, it may make sense to apply a proof of concept or prototype to ensure that the migration at a large scale will go smoothly. Given the bandwidth and capability this is a highly suggested exercise.
The next step would be to identify the data layer and data model and be sure it is designed optimally for your organization and to meet organization’s performance expectations. Once the data modeling has been designed, it’s now time to identify the migration path itself.
Think about how you’re going to migrate this content from one data source to another. For example, if you have an on prem Teradata implementation and you want to use the Microsoft Gateway to migrate that content over – whichever route you go with make sure that’s in place.
Lastly, identify the execution of the migration itself, ensuring that any type of system testing is done at the end to make certain of data quality and integrity. Thus, users can count on the information they are getting to be accurate and meaningful to use in their day to day activities.
Now, how do you go about performing this migration? There are several ways you can do it. A couple that come to mind include leveraging some of the Microsoft tools out there, like Data Factory and SSIS, which can help with the migration itself by identifying the source and migrating that content into the destination. There are also some third-party tools you can use. Datometry’s Hyper-Q is another tool that can help facilitate migration from Teradata to Azure SQL.
What if you don’t have any of those things? Can you just create flat files from Teradata and migrate those over into Azure SQL? Absolutely, although this is not the recommended approach, in some cases it may make sense to go this traditional route if budget constraints or security restrictions on software installed on your computer for instance hinder migrating the ways I’ve mentioned.
But if you go this route, you must make sure that any views that were created or indexing hierarchies, things of that nature that may have been applied to your Teradata environment, are carried over and implemented in parallel in the Microsoft Azure SQL environment.
Need further help? Our expert team and solution offerings can help your business with any Azure product or service, including Managed Services offerings. Contact us at 888-8AZURE or [email protected].
