Sorry, but the responsibility for the state of your data lies firmly on your shoulders. The less care, attention, and preparation you provide, the more likely you are to encounter (or create) problems. It’s also up to you to decide what data needs to be migrated – expecting your partner to guess is unadvisable.
We’ve helped our customers realise some significant business benefits by moving them to Microsoft Dynamics 365. And smooth and efficient data migration is a critical part of the move. But if your partner isn’t knowledgeable, or you’ve decided to handle the migration task in-house, it’s as easy to end up in hot water. So, what can go wrong, and why? And based on our hands-on experience, how do we recommend you avoid these six potential problems?
Peril 1. Seeing data migration as a purely technical problem
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 meet your business requirements both technically and functionally to preserve and enhance the data you value.
Top tip: It’s essential 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.
Peril 2. Starting too late
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 usually considered a fluid task, and there isn't a dependency on the project's 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 can ripple throughout the entire business. To minimise the risk of ‘unknown unknowns’, it is critical to start your data readiness and migration activities as soon as possible to get early exposure to the users and reduce the feedback loop. 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!)
Peril 3. Not ensuring requirements are measurable/testable (or making certain data quality requirements aren't left to the last minute)
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 making your data migration test-driven to provide clearer direction to the data migration technical resources (whether partner or in-house). By allowing test cases to be trialled during the build of the data migration process - prior to acceptance testing - you’ll reduce the potential amount of rework time.
Peril 4. Not performing multiple trial cutovers data migrations and measuring the duration
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. Based on our experience, we can tell you that it usually takes multiple iterations before it becomes somewhat seamless.
Top tip: We suggest testing 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 include a list of procedures for the team to follow in the event of an unrecoverable fault during cutover.
Peril 5. Migrating data you’re not going to need
Default templates for importing data into Finance and Operations often include every available field in the data entity. 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: When using data import templates, take the time to remove any field mappings you don’t plan to populate. This will keep the generated worksheets concise and aligned with your business data needs – reducing noise and minimising the risk of unintentionally overwriting system defaults with a blank or inserting inaccurate values.
Peril 6. Oversimplifying the contextual differences between FinOps and your legacy system
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, not separate primary home and primary mobile numbers.
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.
What appears to be a straightforward data move can quickly become a complex transformation, with some data sets being pulled apart and put back together again.
Top tip: We suggest engaging business users early to manually test samples of real legacy data in the Finance & Operations environment. This will help define how legacy data should be restructured, validate what transformed data should look like and identify those contextual differences between the systems. From here, you can map the key data and identify the sequencing of data entities.
Takeaway:
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 significant problems without the right planning and expertise. If you’re struggling or just not prepared to risk ‘getting it wrong’, give us a call.
We’ll see you right.
In this article
FAQs
Who is responsible for the quality of my data when it comes to migration time?
Should we leave getting our data until last?
No. Project deadline slippage is frequently caused by a lack of data prep. While it may seem like a task you can slot in between others, it can, in reality, hold everything up. Paying early attention to the task highlights issues and gives you time to remediate them before migration day.
Should we test-run migrating our data?
Absolutely. Then, if issues arise, you can resolve them early on and save a considerable amount of rework later.
Is it better to move all of our data, then discard what’s not needed later?
No – that’s like moving from your home of 20 years without sorting out what you're taking with you to your brand-new modern apartment. Moving solutions is the perfect time to evaluate and prepare what data you need going forward. This includes ensuring the field mapping is correct as you migrate from the old to the new system – this prevents overwriting system defaults with blank values or inserting inaccurate ones.
Hello, you’re speaking with Bernie!
×