As a Director of Consulting for Sunrise Technologies, Jason Wolf has over 15 years of experience implementing Dynamics ERP solutions for apparel, footwear, retail, and consumer goods companies.

 

ERP implementations are tough

Over the years, implementation partners have created methodologies, project management and planning tools to account for every aspect of an ERP implementation. Yet it’s still common to see data migration get left behind during project planning. We believe this is backwards, since without the data, your new ERP system can’t go live. Data migration should be considered at the beginning of an ERP project, while other important design decisions are being made. By taking the time upfront to plan your migration strategy, you can avoid unexpected delays during your project.

Why migration planning is so important
Data migration strategies
Data cleansing
Validation and testing
Frequently asked questions

 

Data migration can make or break your implementation

Migration planning should happen early in the project. Getting a jumpstart on the challenges for each data structure can save tons of time, and safeguard against unexpected hiccups during the project. It also gives the project team a better idea on timelines and resources needed to get from the old system to the new one. The bigger the change to a data structure (especially master data structures like product, customer, vendor, etc.,) the more challenging it will be to move to the new system. Without a plan in place, budgets can run over, timelines run long, or an issue stalls the process late in the project.

Selecting a strategy for data migration

The key to a smooth migration is picking the right strategy. One size does NOT fit all, which is why it’s important to spend time early in the project deciding on the best method. Some examples are:

  • Bill of Materials data might be complex, with significant changes to the data structure. However, the volume might be small enough that it’s easier to enter it manually. For very complex data structures, it doesn’t make sense to write a migration script that you’ll only use once, when in the same amount of time you could just enter the data.
  • Sales orders (or other types of transactional data), might be thousands or even hundreds of thousands of lines long. In that case, it might be better to create an automated script to move and map the data.

 

Cleaning the data

One of the unsung benefits of an implementation is getting a fresh start with clean, well-organized data. You can’t realize all the benefits of a new ERP system if your data is riddled with errors. Take this opportunity to remove redundancies, append missing information, fix typos and errors, and archive what you won’t need going forward. The key is to clean the data before migrating to the new system. Source data should be audited, issues resolved quickly, and controls set up for maintaining data quality and governance in the new ERP system. Much of this data cleansing work is manual, but it’s worth it to get the full value out of your implementation.

Data validation

The only way to know for sure that the data migrated successfully is to check. The basic process is to start with a small amount of data, load it into the new ERP system, test, add more, and repeat. Once the migration is complete, you can validate it by checking against the source system. For example, say you want to check your open sales orders. You could check the line counts, quantity, and amount against the original source and if the numbers match, you’re good to go.

Frequently asked questions