Dual-write to Dataverse: the initial sync and cutover runbook

Dual-write creates bi-directional near-real-time sync between F&O tables and Dataverse tables. Turning it on feels like a toggle. The setup tutorial at learn.microsoft.com reads in fifteen minutes.

In practice, manufacturing and distribution organizations flipping dual-write on for the first time routinely hit the same cluster of issues: duplicate customer records piling up in Dataverse, conflict resolution rules that don't match how the business actually operates, and a "weekend cutover" that stretches into a week of cleanup. Here's the runbook experienced teams follow.

What dual-write actually does

The sync is based on alternate keys. F&O's CustTable.AccountNum maps to Dataverse's account.accountnumber when configured. When a record writes on one side, a plugin or integration event pushes to the other side. Conflict rules govern who wins when both sides write simultaneously.

Simple in principle. Each piece - map design, initial sync, conflict rules, error handling - has its own failure modes.

Step 1: decide what syncs, not what's available

The default table maps cover 60+ entities. Enabling all is the classic beginner trap. A better starting point:

• Bi-directional: Customer (master on F&O), Contact (master on Dataverse), Product (master on F&O)
• One-way F&O → Dataverse: Invoice headers (for case-handling visibility), Payment terms (for quote-to-cash)
• One-way Dataverse → F&O: Opportunity-to-quote (lead becomes quote in F&O)
• Don't sync at all: Employee, Vendor, Financial dimensions (each owned by one side)

Half the table maps in the default set aren't needed. Each one skipped is an outage surface you don't have.

Step 2: the initial sync strategy

Default dual-write sync is trigger-based - records sync when created or updated after enablement. For existing F&O environments with millions of customers, this is a problem. You need to populate Dataverse with the existing data before enabling dual-write for steady-state operation.

Three documented strategies:

1. Initial sync via dual-write - enable the table map with "Initial sync" on. F&O pushes current data to Dataverse in bulk. Works for modest volumes (under ~100k records per table). Slow for larger datasets, and can fail mid-run leaving inconsistent state.
2. Data entities + DMF + dual-write delta - export from F&O using data entities, import to Dataverse via DMF or Dataflows, then enable dual-write for delta-only. Faster and resumable for larger volumes.
3. Snapshot + reconcile - take a point-in-time snapshot, import to Dataverse, enable dual-write with delta-only, reconcile any deltas from snapshot time to enable time.

For enterprise-scale migrations, option 2 is the default recommendation.

Step 3: conflict rules

When a record updates on both sides in the same sync window, dual-write needs to know who wins. Rules are per-map and per-field:

• F&O wins - typical for master-on-F&O tables
• Dataverse wins - typical for sales-cycle tables
• Last write wins - dangerous; prefer explicit rules

Default is "F&O wins" for ERP-centric data. Overrides per-field are supported - a common pattern is the Customer record master on F&O but the "preferred contact method" field master on Dataverse because sales teams manage it directly.

Document every conflict rule decision in the project wiki. The next person to touch the map needs to know why, and "the docs didn't explain it" is the excuse that turns a rollback into an incident.

Step 4: error handling and the error queue

Dual-write failures land in the Dual-write error queue in the Power Platform admin center. Silent failures (no queue entry) happen when a plugin throws; validation errors create queue entries.

Common error modes:

• Missing field-mapping - a F&O field has no Dataverse target, and the sync blocks.
• Invalid value conversion - string-to-enum mismatch, especially with custom enums.
• Dependency order - customer record tries to sync before its required contact.
• Plugin throw - Dataverse plugin on the target fails, dual-write retries, then gives up.

Automate a daily sweep of the error queue via Power Automate that posts a Teams summary. During and after initial sync, the queue is the first place to look when numbers don't reconcile.

Step 5: the cutover weekend

When you flip from "soft launch" to production dual-write:

Friday 18:00: Freeze writes on both sides. Take final snapshot. Run one last reconciliation.

Saturday morning: Deploy final table maps to production. Run initial sync. Verify counts match on both sides.

Saturday afternoon: Enable delta sync. Write test records on each side, watch them appear on the other.

Sunday: Monitor error queue with team on call.

Monday 08:00: Unfreeze. Business operations resume.

Plan a 48-hour freeze. Don't plan 24 and hope - the hope-based plan is where projects acquire their worst memories.

Step 6: post-launch monitoring

Monitoring that catches slow drift before it becomes "the data's been wrong for three months":

• Error queue dashboard in Power BI
• Alert in Azure Monitor on error count > 10 per hour
• Daily reconciliation script sampling 100 random records from each side
• Weekly admin review of error trends

Dual-write works. Done carelessly, it fails in ways that take months to surface. The runbook above is what separates "it just worked" from "why is our data wrong".

What good dual-write looks like

Sales sees real-time customer credit limits without leaving their CRM view. ERP sees the opportunity pipeline without leaving the financials. Two systems feel like one without becoming one. That's the payoff - and it's only achievable with the disciplined setup, not the toggle-and-go approach.