What is Data Migration?

Data migration is the process of moving data from one system to another. This might seem like a straightforward process, but it involves moving data between two separate systems that might be quite different and incompatible.

Why a Data Migration Strategy is Important

Most often, the Customer’s goal of moving from their existing system to Adonis is to enhance performance and competitiveness. If the migration is not successful, it can result in inaccurate data that contains redundancies and unknowns. Any issues that exist in the source data can be amplified when brought into Adonis.

Having a data migration strategy will prevent a bad user experience and a move that creates more problems than it solves. Besides causing delays in the project and exceeding the budgets, an incomplete plan can cause the projects to fail altogether.

As part of the strategic data migration plan, it is important to consider these critical factors:

• Know the data ­– Before the actual migration, the Customer needs to have a full review of their source data.

• Clean the data – Any issues with the source data must be resolved before the migration.

• Maintain the data – As data undergoes degradation after a period of time, making it unreliable, there must be controls in place to maintain the data quality.

• Governance – There must be in place agreed-upon processes and tools to track and report on the data quality.

Data Migration Strategies

There are several data migration strategies that can be used, and understanding the Customer’s specific needs and requirements will help establish the correct strategy per project. However, Adonis projects normally follow one of the two strategies outlined below.

A Big Bang Migration

With a big bang migration, the full transfer is completed within a limited time window. The current systems will go down while the data goes through a final extraction, transformation, and loading.

This strategy requires running through the migration process up to 3 times before the actual event.

 Pros:

• Everything happens in a one-time event

• It requires little time to complete

Cons:

• There will be a period of time where the systems are offline

“Trickle” Migration

In contrast to the “Big Bang” migration strategy, the Trickle migration will complete the migration process in phases. During the implementation, the old system and the new are run in parallel, which eliminates downtime or operational interruptions. The processes running in real-rime can keep data continuously migrating.

Pros:

• Reduces risks

• No downtime

• All data is in real-time

• Especially for customers that take payroll in use, there is a need for at least two months of parallel run, and “Trickle” migration will reduce the effort to keep two systems up to date manually.

Cons:

• It can be fairly complex in design

• Be more time consuming

Adonis’ 6 Steps in the Data Migration Strategy

No matter which approach is chosen, the data migration plan should follow the same steps:

Analysis and Discovery

The first step requires the data team members to work with the project’s functional and technical resources to determine all of the source systems, file systems, applications, etc., which will be in scope. It will involve analyzing the source system and gather metadata. This information is crucial when choosing the overall data migration strategy, the scope of work, ensuring business rules and conversion logic have been established for all data sources, and that all data sources have been identified.

Extract and Profile

In this step, the data team members analyze and profile the data in the source systems. The examination will typically include column profiling, data quality assessment that reveals the quality, content, and source data structure. The information revealed will help the data team understand the amount of effort required to cleanse and confirm the data and aids in developing business and conversion rules.

Cleanse

Before the data is migrated, the Customer must know and understand what data they would like to bring over and how it will fit into Adonis. There might be data that is not needed to bring over, and there might be data that is just missing.

The Customer must consider:

• What data needs to migrate over

• What can be left behind

• What might be missing

Validate

Before the data is loaded into Adonis, the Customer’s functional team members and business users must validate it to ensure the data conforms to all business requirements and is complete and correct. The technical resource, functional team members, and business users will conduct review sessions and fix any mapping issues before loading.

Load

After the business has signed off on the pre-load validations, the data can be loaded into Adonis. Adonis has several methods for loading data. It can be anything from using pre-defined import tools, creating table insert statements or a tool developed specifically for the Customer in question.

Reconcile

Once the data has been loaded into the target system, various teams need to ensure the data has been loaded successfully. The functional teams will enter Adonis and execute UAT scenarios to ensure the system has been appropriately configured and that the data has been loaded correctly.

The Customer is the ultimate owner of the data and must sign-off on the post-load validations.