Select Page

Data Analytics Platform Migration

By Claudia Imhoff, Ph.D
| August 18, 2022
data and analytics

GUEST BLOG POST – Claudia Imhoff, Ph.D.

A thought leader, visionary, and practitioner, Claudia Imhoff, Ph.D., is an internationally recognized expert on analytics, business intelligence, and the architectures to support these initiatives. Dr. Imhoff has co-authored five books on these subjects and writes articles (totaling more than 150) for technical and business magazines.

Migrating to a New Analytics Platform? Here are Some Things to Think About

Many enterprises are considering a move to a new analytics platform, particularly a cloud-based one. Why? Well, there are many reasons – reducing IT costs, reducing data storage costs, improved performance from newer technologies, and many others. But migrating to a new platform is more than just forklifting your legacy data warehouse or data lake into the new environment. 

Doing that is a big mistake and a missed opportunity. Aging analytics environments come with several problems such as workarounds that were created to mask problems, production of inefficient code, or projects that valued expediency over good design techniques. Migrating is a great time to blow the dust off the old designs, fix nagging problems, improve overall efficiency of data management processes, remove unused or forgotten data and analytical processes, rationalize all the tools and technologies being used for analysis, and tighten up governance procedures.

ETL

One area that has great potential for improvement is the data transformation or ETL processes. It is this area upon which the remainder of this blog post will focus. 

So with this in mind, let’s discuss the technology behind data transformation. ETL or ELT has been around for decades now and yes, you still need mature transformation technology. But for a migration initiative, you need more than just good technology. You need technology that has been created explicitly to ease the migration effort. Ask yourself the following set of questions before embarking on your migration:

  • Is your data transformation technology configured to work specifically with whatever cloud platform or platforms you have chosen? Often, enterprises do not settle on a single cloud vendor or a single instance. Make sure your choice of data transformation technology works with and across all the major cloud platforms.
  • Does it use the latest cloud platform functionalities and capabilities? Cloud platforms have their own ways of loading and unloading data, as well as other features that must work with the data transformation technology.
  • Does it have the proper connectivity for all major sources? Aging analytics environments often have multiple “satellite” sets of analyses occurring outside of the main data warehouse. Migration activities could be used to consolidate some of these disparate environments back into the “mother ship”. These connectors are also used to profile and detect quality problems in the aging environment, as well as browse and discover redundant, unused, or undocumented sets of data.
  • What about modern standards for modeling and data transformation procedures? Now would be a good time to enforce standards across the new environment through your data transformation (and other) technologies. 
  • Does it integrate easily with the other technologies (design, quality, catalog, analysis, etc.) used in an analytics environment? Just enforcing standards from the data model stage through data transformation on to the creation of analytical assets would be a great improvement in many enterprises.
  • Does the data management technology have pre-built templates and configurations for different data model types (3NF, Star Schemas, or Data Vault) for all major platforms? It is always faster and better to start from a template than to have to create everything from scratch. Check to make sure your data transformation technology contains patterns as well for specific data modeling styles. Not only are templates and patterns good for standardization but they are terrific productivity tools.
  • Can repetitive ETL processes (e.g., dates, times, codes, etc.) be used to relieve some of the tedious programming for the IT staff? These are also great productivity and standardization functions.
  • Can you use automation of the data transformation processes to ensure accuracy, timeliness, and up-to-the-minute accuracy of metadata behind these processes? Automation is the key to guaranteeing a successful migration. It is your certification of “goodness” in the final analytical environment.

Cloud Data Migration

Finally, ensure that your data management technology vendor has the data engineers to assist your data architects and data designers in this migration. These resources must be fully capable of delivering and provisioning your new environment on any data platform, for any major cloud configuration. Use these engineers to not only help migrate to the new environment but to fully train your own staff to ultimately replace them.

Once the newly remodeled, redesigned, retransformed analytical environment is up and running, enjoy the benefits of lowered costs, reduced redundancy in data and analytical assets, increased efficiency in data transformations, and improved access to ALL data by the ultimate consumers.

Data Automation

Do you want to know how Data Automation can support your migration to a new analytics platform? Contact WhereScape to find out more.

Data Lineage: Why Modern Data Teams Need It More Than Ever

Ask almost any data team where a number came from, and you will usually get one of two answers. Either someone knows immediately, or everyone starts digging through SQL, pipeline logic, wikis, and old messages to reconstruct the story after the fact. That gap is...

SQL Server Integration Services, Without the Slow Build Cycles

For so many SQL Server teams, SQL Server Integration Services (SSIS) still sits at the very heart of data movement, transformation and scheduled load processes. Microsoft’s own documentation still defines SSIS as a platform for enterprise-grade data integration and...

Modernizing SQL Server: Without Breaking What Already Works

For a lot of organizations, SQL Server performance is not just a technical concern; it’s a business continuity concern. When reporting runs long, overnight loads miss their windows or the team becomes afraid to touch a fragile stored procedure because nobody even...

Building and Automating SQL Server Data Warehouses: A Practical Guide

Key takeaways: SQL Server warehouses aren't legacy; they're production environments that need faster build processes Manual builds scale poorly: 200 tables can equal 400+ SSIS packages, inconsistent SCD logic across developers Metadata-driven automation can cut...

Should You Use Data Vault on Snowflake? Complete Decision Guide

TL;DR Data Vault on Snowflake works well for: Integrating 20+ data sources with frequent schema changes Meeting strict compliance requirements with complete audit trails Supporting multiple teams developing data pipelines in parallel Building enterprise systems that...

Related Content

Data Lineage: Why Modern Data Teams Need It More Than Ever

Data Lineage: Why Modern Data Teams Need It More Than Ever

Ask almost any data team where a number came from, and you will usually get one of two answers. Either someone knows immediately, or everyone starts digging through SQL, pipeline logic, wikis, and old messages to reconstruct the story after the fact. That gap is...

SQL Server Integration Services, Without the Slow Build Cycles

SQL Server Integration Services, Without the Slow Build Cycles

For so many SQL Server teams, SQL Server Integration Services (SSIS) still sits at the very heart of data movement, transformation and scheduled load processes. Microsoft’s own documentation still defines SSIS as a platform for enterprise-grade data integration and...

Modernizing SQL Server: Without Breaking What Already Works

Modernizing SQL Server: Without Breaking What Already Works

For a lot of organizations, SQL Server performance is not just a technical concern; it’s a business continuity concern. When reporting runs long, overnight loads miss their windows or the team becomes afraid to touch a fragile stored procedure because nobody even...