Data Migration 103: Systems modifications?in Dynamics 365 ERP technology

Before reading this blog post, I recommend reading my previous blog posts:

• Data Migration 101: Working in the Cloud with Dynamics 365 ERP technology
• Data Migration 102: Data Entities?in Dynamics 365 ERP technology

A wise colleague of mine once called a modification in ERP “the gift that keeps on taking”. While a bit cynical, he has a point. Done properly, System modifications are flawless at go-live but become a time sink post-go-live. On the cloud, Microsoft makes system updates routinely, so our modifications must be tested with each update, ensuring the customization remains functional. Additionally, core updates will occasionally break an existing modification, so additional time is required to fix whatever it is that broke.

Customization maintenance doesn’t get enough attention during go-live activities. The focus is on conquering gaps and issues that only a customization can deliver. Dynamics 365 is designed with flexibility in mind, and to be clear, modifications WILL be needed on every project. What I am drawing attention to is a reminder. A modification is YOUR solution. It is an organic bolt-on to the system that you must maintain to ensure it functions with each system update.

So why are we discussing this with regards to data migration? In my experience, every ERP project requires custom add-ons to the database. It comes in two forms:

• Single Field add-ons to existing tables
• Completely new tables added to the database

For instance, I worked for a manufacturing company that made copper wire. We added a single field to the released product table, which was a Boolean named “Has Copper”. We also required fully custom tables that stored data such as copper weights per finished good, copper value per quarter, etc.

The single field add-ons are simple in Dynamics 365. Adding a field to a data entity is simple, and at most, a developer may need to add said field to the existing entity. This doesn’t take long in terms of development. An hour at most, and then you’ll have to wait for a code promotion.

The subject which is far more difficult is completely new tables. When introducing a custom table, this now means we need to decide if we’re introducing a custom data entity. We don’t necessarily need an entity for every custom table, and find the best rule to follow is this:

• Will the number of records in the table be in the 10’s, 100’s, or 1000’s or higher?
• Will the records be relatively simple or complex? (i.e.: 5 columns vs 50 columns on the table)

Anything which will hit 100+ records automatically should have a data entity. That quantity of data shouldn’t be typed in, and a custom data entity will be worth the effort. Anything less than 100 records is best done manually, but if the records are especially complex, consider adding a data entity on a case by case basis. If a single record has 50+ touchpoints of data, keystrokes should be avoided for migration.

An estimate needs to be done early in the project to determine the value of custom data entities. Each custom entity takes a few hours to develop, but we weigh this against typing the records manually each time compounded by the number of times we migrate. Some tables I’ve worked with are so small that I keyed them in with each migration, but about 90% of the time, I’ve gone through the effort to have a custom entity developed, and it’s worth it. Yes, the custom entity needs to be tested on occasion with system updates to ensure it remains functional, but the effort is well worth it considering the hours of keystrokes a custom entity can save.

Stay tuned for the next post in this Data Migration series:?Nomenclature!