A Look at Data Migration – Volume 2: Master Data vs. Static Data

This article was co-authored by Anthony Imanlihen Jr. and Lynsie Grover.

It’s Just Like Building a House…

Before starting any data migration activity, it is important to understand the impact of data loads within the system. Just like building a house, there is an order of operations which must be followed to migrate data successfully. Where a house begins with its foundation, the Microsoft D365 environment starts with configurations. A strong foundation in both scenarios, allows for a stable build. The configurations in Dynamics 365 determine where information will fall within the system. The next step is where the structure is added, which is also known as the master data within a D365 environment. Finally, static data is included which completes the interior of the home. Static data usually houses realistic information about the client business.

All of this construction brings us to the end result of being able to live in our home and decorate it how we see fit – similar to how users are able to work in their own system to utilize the design to cater the needs of the business. Just as we would hire a professional contractor for our build, data migration process overall heavily relies on the IT team, but the maintenance is on the homeowner, or system users within the case of an ERP system.

Clear decisions must be made on what credentials would qualify what information will be brought over to the new environment. Cross functional support is required to ensure that all data is accounted for. The proposed data should be validated for errors and the relevance prior to being loaded. Once the information is available to test, users should then be able to confirm whether the information is presented in the way which works for the business.

Master Data

Master data, being the structure of our ERP, is the first set of data to be loaded in regard to the entire data migration process as it is a requirement to facilitate the loading of static data. Master data involves a majority of the business information such as the main accounts in the General Ledger, locations in a Warehouse, user setup in System Administration, and workers within HR. What this process looks like may vary slightly from one company to the next.

The data is usually uploaded using a data import but can often be completed through manual entry. Prior to adding the master data, it is important to understand the impact the records will have on the system. There may be a case where data is being imported to a globally shared table, while other tables are legal entity specific within the system. Configurations need to be setup so the system accepts the data information, while it may be changed after the migration process is complete to suit the needs of the business.

Through-out the build process, the master data will initially be loaded into a test environment for validation. Once the data is scrubbed and tested, it will be loaded into a prestigious environment and later be copied to subsequent environments for analysis and training before eventually being used for production. There is usually little change to master data once it has been tested, though it can still be altered prior to any transactions taking place in the system. If there are any alterations to the master data, users should first understand the implications of the change by utilizing a test environment. Once testing is successful and the business are comfortable with the changes, only then is the prestigious environment updated with the same configurations.

Static Data

Once the master data has been uploaded and validated, the static data will be added to the environment. Static data is transactional in nature. What is being brought over is dependent on the modules being implemented and what is outlined in the cutover plan. Static data may include various information and amounts for items such as previous year balances for general ledger accounts, outstanding invoices for accounts payable, open accounts receivable invoices, un-reconciled items in the bank, budget amounts, open purchase and sales orders, as well as price lists or trade agreements for sales and purchasing. Not all past data should be brought over – clear attributes must be considered across all function to determine what qualifies data to be moved maintained within the new environment.

Within the testing cycle, once the master data is loaded, iterations of testing for the static data should be performed to ensure that the data has been cleansed and formatted to specification and works to fit the needs of the business. We recommend run the initial iterations with a small subset of data to facilitate all testing scenarios and ensure the desired result is attained. After users are able to confirm that data is behaving and presented in the way the business anticipates, a larger set can be brought over through each iteration until the entire data loaded has been tested. This process should be documented so that users can understand the changes required for each data set prior to it being loaded in a given environment.

Transversely to master data, static data is expected to change through-out testing cycles and prior to the go-live stage of an ERP implementation. Clear cutoff dates must be defined in order to facilitate that all required from the legacy system is included as it is will differ at any given period of time. Testing is vital to understand all scenarios are accounted for prior to migrating and using the data in an active business environment once the production system is turned on for use.

What to Expect Next

Facilitating the volume of data being loaded within a new ERP environment can be a challenge. Data entities within D365 can be utilized during the data migration process in order ease the effort required. Understand all about how data entities work in our upcoming edition, A Look at Data Migration – Volume 3: Understanding Data Entities.