Overview

When we think about a data migration strategy, we always have the following in mind, among others:

• Data preparation
• Approach
• Roles and responsibilities
• Validation
• Defect triage, fix and re-execute
• Tools

Is it then different when dual-write is involved? The short answer is “No”, dual-write is just another integration pattern that you need to consider in your overall architecture landscape. It is the out-of-box infrastructure that provides near-real-time interaction between customer engagement apps and finance and operations apps. And because it provides a tightly coupled, bidirectional data exchange between them, it might be easy to consider that it also answers the questions we have when defining a data migration strategy.

In reality, several approaches to migrate the data subject to dual-write can be taken into account, each with its own considerations, as follows:

Initial synchronization

The initial synchronization lets you copy existing data from one app to another bidirectionally before activating dual-write on a table.

Considerations

• Data must be loaded in one app first.
• Initial sync is leveraged to bring that data into the other app.
• The correct sequence needs to be defined and applied to the Initial sync strategy.
• Intended mostly for configuration data or low volume master data (see guidance matrix Considerations for initial synchronization - Finance & Operations | Dynamics 365 | Microsoft Learn) 
• It can only happen after the data has been loaded in one app, which means longer duration in total (it cannot be parallel)
• Initial sync only copies data which is applicable to both apps (fields/ columns included in the table maps); data specific to only one app must be initialized with a dedicated data flow
• Limitation on legal entities number: 40 is the current limit (it will be removed in the upcoming releases)

Data migration in parallel

Enterprise customers usually deal with very large volumes of data, beyond the limits of initial synchronization. In this situation, migrating data in the individual apps is the best approach.

Considerations

• Recommended for high volumes of data.
• Requires data migration in both apps, as such data migration tasks are applicable to both (separate tools, data migration optimizations specific to each app, etc.)
• Pay attention to the sequence of data, consider dependencies.
• The team needs to ensure the data alignment.
• Initial synchronization needs to be skipped.

Data migration with dual-write maps enabled

As we seen, the initial synchronization is a two-steps process, taking overall more time (initial load + synchronization). With small volumes, it might be possible for the project teams to do the initial load with the dual-write maps enabled, which basically means loading the data in the other app at the same time.

Considerations

• Similar considerations as Initial sync (applicability, starting app, etc)​.
• Has performance implications​.
• Roadmap: Async processing mode included in the upcoming releases.

Hybrid approach

In implementation projects, team will eventually take a hybrid approach, for example:

• Data migration with dual-write maps enabled for configuration data.
• Initial synchronization for low-volume master data.
• Data migration in parallel for high-volume data.

Considerations

• It is the approach that can probably adhere the best to the requirements of large-scale enterprise projects.
• It leverages the advantages of the individual approaches.

Conclusion

There is no easy answer to the question: “how do I migrate my data when dual-write is in scope?”. As we have seen, multiple approaches can be taken, but before deciding on one pattern or the other:

• Do not consider initial synch as the default mechanism to meet your data migration needs. It is a tool which must be evaluated, similar to other tools available for data migration.
• Think about your Dynamics 365 apps as one solution. Your data migration strategy needs to reflect that.
• Before deciding for one pattern or the other, ensure enough information is available to take an informed decision (volumes, type of data, optimization paths, etc.)
• Consider the design of the standard framework and that some entities must be populated through dual-write (they are blocked from direct input). One example is mdm_company.
• Keep up with the roadmap, as significant changes are coming to the dual-write space. Join this Yammer group: (346) Yammer : Dynamics 365 and Power Platform Preview Programs : Dual-Write : New Conversations
• Do not implement complex customizations to replace dual-write or to do data migration without evaluating the out of the box capabilities and the roadmap.

For more information, check out this episode in the FastTrack Architecture Insights with Andreea Bunduc, Vince Angeloni and Ajay Jaiswal!