Home > Blog > Data Migration 104: Understanding nomenclature best practice in Dynamics 365 ERP
Data Migration 104: Understanding nomenclature best practice in Dynamics 365 ERP
AlfaPeople |
Dec 16, 2019

Data Migration 104: Understanding nomenclature best practice in Dynamics 365 ERP

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

Working with the DMF in Dynamics 365 is really simple once you get used to the terminology and work your way through a data project. To Microsoft’s credit, the tools at hand are easy to use for technical and functional users alike. Once we get up and running however, a new challenge emerges in the world of the cloud.

Going back to AX 2012 when DMF was referred to as DIXF, all projects I worked on had 1-2 technical end-users who governed the DIXF module entirely. With only a few people handling the actual loads of data, said experts had complete discretion to decide naming conventions for import projects and export projects on their own, but now, the DMF is likely going to have 5+ users depending on the size of the project. So why is this a new challenge?

Because Dynamics 365 does not name the projects for you. When new imports/exports are created, a project name and a project description must be provided, and it’s done manually. I have been on 2 D365 projects that ran into a common pitfall: multiple users created projects which served the same purpose but are named differently. It’s easy to have 2 projects accidentally serving the same purpose, and that’s painful to remedy if we don’t keep the DMF organized right out the gate.

Management of the DMF Nomenclature is in my opinion best managed in two regards:

  1. Individual Entity Naming Convention
  2. Template Naming Convention

Individual Entity Naming Convention

The most basic approach to data migration in the DMF is to assign each entity its own project. This is most common during early stages of the project when running the first test load of an entity or at later stages of a project where small sub-sets of data must be added that an initial load didn’t have.

I saw a project where 4 individuals were responsible for data imports, and the team initially didn’t decide a naming convention for our projects. This created situations where 4 different projects contained the exact same data entity. This is important because the system stores its import against the project, not the entity. We had our history of imports spread over 4 projects.

That’s why a naming convention is needed. As mentioned during my 101 blog post, AlfaPeople marked down EVERY entity in Dynamics 365 and assigned an ID to each one. We use that ID as a standard naming convention for our projects. This saves hours for troubleshooting by keeping import histories on a single project.

The projects we’ve been discussing so far are 1:1 relationships between project and entity. This is simple. Now what about the more complex projects which control multiple entities? That part is next.

Entity Group Template Naming Conventions

The DMF in Dynamics 365SCM and Dynamics 365F comes with an out of the box solution: Templates.

In the DMF, we have two different kinds of templates:

  1. Individual Entity Templates
  2. Entity Group Templates

The individual entity templates are the excel files discussed previously in these blog posts. As a reminder, these are empty excel spreadsheets with headers clarifying what data is to be provided against the entity.

Entity Group Templates are instead a pre-made grouping of data entities that can be used to create a data project and have the list of entities automatically populated. What Microsoft has done is created a logical order the individual entities should be loaded, and provided that list already loaded in the mentioned Entity Group Templates.

Those entity group templates are then given a standard naming convention as well to ensure the order of the Entity Templates is proper as well.

For instance, as pictured above, Microsoft Identifies:

  • 010 ? System Setup
  • 020 ? GL Shared
  • 022 ? Workflow
  • 025 ? General Ledger
  • 100 ? Bank
  • Etc.

This convention works, but now I must reveal the hard truth. This solution will only get you about 90% of the way there. Every Data Migration team must assess the Entity Group Templates and decide the following:

  1. Which entities will stay or be removed from the out of the box Entity Group Templates
  2. Do we require additional Entity Group Templates? (Most often for specific Module additions, ISV Additions, or Custom Entity Additions)

Whatever the approach will be, the team needs to agree on this and coordinate either on a project team site or DevOps to ensure all parties are on the same page.

At AlfaPeople, that’s exactly what we practice. We have built documentation to ensure all parties working in data migration are in-sync from day 1. Coordination in the team is strong, scope for migration is clear, and time is saved by avoiding any confusion deciding how migration is to be completed.

Eager to learn more? Contact me today to discuss the Data Migration options for you and your business.