The perils of migrating your data to Dynamics 365, and how to avoid them!

Although data migration involves many technical solutions, these solutions only answer a business need. The challenge is to ensure that the migration solutions you choose to use meet your business requirements to preserve and enhance the data you value.

Top tip: It’s important to be aware that your partner (or internal resource) is dependent on you to deliver a successful migration outcome. So, it’s important that you take ownership of the quality of your data, provide guidance, and identify the value of the data you need to move forward with. It will make all the difference.

Running late for a very important (go-live) date? Often the data migration process simply starts too late in the project or runs well over time. That’s because it’s often considered a fluid task, and there isn't a dependency on the project critical path until UAT. Then all of a sudden, you’re up against the wall, the timeframe for completion is tight and there’s no wriggle room to deal with unknown unknowns!

Note: Data migration can be like a duck on the water. On top, at the conceptual design, it can appear to be simplistic and calm, but underneath the water, there’s a lot going on to keep it afloat. These processes need to be reviewed at both logical and physical levels. 

Top tip: We know from experience that project slippage is very real (for a multitude of reasons), and the knock-on effect of missing deadlines ripples the whole way through the business. To minimise the risk of unknown unknowns, it’s critical to start your migration activities as soon as possible to get early exposure to the users and reduce the feedback loop as much as possible. With early exposure you’ll catch any edge cases. (Note: An edge case is a problem or situation that occurs only at an extreme - maximum or minimum - operating parameter. Right when you don’t need another problem to deal with!)

Too often it’s tempting to jump straight into solutioning without clearly defining the non-functional requirements. This leaves the definition of what data quality is and the required metrics for acceptance up in the air. However, these ‘to be resolved’ requirements can shape how the solution is designed and if not identified early, can create a large amount of rework later on.

Top tip: We recommend that you make your data migration test-driven in order to give clearer direction to the data migration technical resources (be they partner or in-house). By allowing the test cases to be trialled during the build of the data migration process - prior to acceptance testing - you’ll reduce the potential amount of time required for reworking.

Your project time can become compressed in the rush up to go-live, and the time available for performing a number of trial cutovers may become limited. Typically, you use the first trial cutover to ensure everything is working end-to-end and to enable you to identify those unknown unknown issues. We can tell you based on our experience, that it usually takes multiple iterations before it becomes seamless.

Top tip: We suggest you make sure you test the non-functional requirements of trial cutovers. During the trial, take special note of the task duration and dependencies to ensure the timeline of the activities is known so you can take them into consideration for cutover planning and scheduling.

We also recommend that you keep disaster recovery planning in mind while planning your cutover. Note: As with cutover plans, disaster recovery plans also need to be tested – they’re zero use if they don’t work. The plan should contain a list of procedures for the team to follow if there’s an unrecoverable fault during cutover.

When generating default templates for importing data into Finance and Operations via data entities, all the fields will be included. However, if you carry the data over as is, it can result in default values being overridden and populated instead with the blank values in your worksheet. Oops. 

Top tip: Try this: When creating your data projects templates in Finance & Operations Data Management, take the time to remove any field mappings that you don’t intend to populate data with. This will keep the generated worksheets concise and only showing relevant fields to your business requirements. And if there are any system defaults, the default value won’t be overwritten with a blank value.

Although you may have two systems containing customer data, the details in them may have contextual differences. For example, in Dynamics 365 Finance & Operations, you can only have one primary phone number, which is inclusive of landline and mobile phone numbers. Whereas in other systems you can have a primary home and a primary mobile phone number.

Similarly, when it comes to addresses. Although Finance & Operations allows multiple business purposes to be defined on the address (invoice, delivery, etc) only one address can be marked as the primary address. However, in other systems you may be able to define a primary invoice and a primary delivery address.

Top tip: We suggest that you leverage modelling to create visual representations of the data models in both legacy and Finance & Operations. This could be an entity relationship diagram, for example. The diagram will highlight the entities, primary and foreign keys and other constraints between the entities. From here you can visually connect the key data and identify the sequencing.

Also, it’s highly important to get early exposure to the application with real business data. You can simply take a sample of existing legacy data and attempt to manually enter all details within Finance & Operations.

Yes, it’s easy to be wise after the event.

But we’ve done enough Dynamics 365 migrations to feel confident about passing on our advice. It’s been hard won, and we now apply it as best practice.

These are just 6 of the most common issues we see businesses encounter – and they can cause big problems. If you’re struggling, or just no prepared to risk ‘getting it wrong’, give us a call.   

We’ll see you right.