Considerations for Teradata Transformation - A First Look

So you've decided you need to modernize/transform your Teradata implementation by moving to the cloud?

What do you need to know before you start?

First question is why of course. But I'm assuming you have an answer given you're contemplating the move. Many companies make the decision based on the cost of maintaining and upgrading legacy systems or for additional tools and flexibility, the reason is less important than the target state. It's critical you know where you want to go - Teradata cloud, Teradata on another cloud or to a new data technology like Google Big Query. This is the critical first decision.

Once you have your end state defined, we can establish a strategy for further steps and plans. A number of important questions begin to emerge, below is our initial list in any project:

• What do we know about the data - data model, dictionary, meta data?

• What is the size of the dataset?

• What is the expected schedule?

• Can the data be cleaned up prior to the move?

• How is data quality maintained?

• What is the governance operating model and tool set?

This is all about the current state, without knowing that the migration cannot be planned and predicted. Undertaking a transformation of a data estate without knowing all about that estate predicts a sub par experience and increases the risk of failure. Our team has experienced this first hand and rescued projects that did not do the above due diligence. It costs much more to rescue and recover than to research and plan - in terms of money, time, risk and quality.

For purposes of this post, assume we decide our strategy is to keep our data model. The implication of this strategy is we cannot move to Big Query, Teradata hosted on a cloud provider is our only option. The data can be moved physically however the data model doesn't translate in an as-is state, there is a fundamental difference.

This sounds simple enough, move your Teradata estate from on premise legacy to the latest and greatest version on Google Cloud or AWS or Azure (these are the leading hyperscalers supporting Teradata Cloud instances). In actuality it's more complex than the software and hardware upgrades your team may have experienced in the past. We never advise upgrading hardware, software, networking, storage, security, governance and environmental tools all at once when on premise. A move to a cloud version involves exactly that - everything about your environment will be changed in that one move. The degree of planning and testing required is much higher and your team will need to learn to execute in an entirely new operating model.

For one of our recent clients, this specific move from Teradata on premise to a cloud version became an exercise in testing. There was no way to test all the implications without creating a robust and representative test environment. Live data could not be used given the risk profile, we had to come up with another way. The solution was to create a digital twin with purpose built test data for the various stages of testing - functional, operational, analytical. At every stage the quality of test data required is different with analytical being the most complex - you need test data that represents the same statistical profile as real data to check if the results are equal.

Want to learn more about how we can help you overcome these challenges and help define your path to successful Teradata transformation? Get in touch with us - info@cloudifyai.com