Why do my Dynamics 365 CRM and ERP show different data?

Dual-write replicates rows synchronously between Dataverse and Finance & Operations. If a sync stalls or fails — a common, sometimes silent state — writes stop propagating and the two systems drift until someone clears the queue. They can stay out of step for days, not seconds.

What is the dual-write 10-lookup limit?

Per Microsoft's troubleshooting guidance, an initial synchronization fails when an entity map contains more than ten lookups. The workaround is to remove lookups, sync in tranches, then add them back and re-enable live sync — extra effort for any richly related customer or sales-order entity.

Are virtual entities a replacement for dual-write?

Partly. Virtual entities proxy F&O data live via OData, avoiding duplicate storage and drift, and Microsoft pitches them as a lighter alternative. But they can't join standard Dataverse tables, so native CE features still need replicated data. Use them for read-only lookups, not everywhere.

Dynamics dual-write: when CRM and ERP disagree for 10 days

Because dual-write is not an integration in the usual sense — it is a synchronous, two-master replication between Dataverse and Finance & Operations, governed by hard structural limits. Put more than ten lookups in a map, exceed 500,000 rows, or trip a five-minute export, and the initial sync fails. Worse, when a live sync stalls there is often no error, no stop button and no self-service recovery — so your CRM and ERP quietly drift apart until someone intervenes.

What is dual-write actually promising?

Dynamics 365 splits the customer-facing world — Sales and Customer Service, the Dataverse side your reps call "the CRM" — from the financial and supply core in Finance & Operations, the ERP that has to invoice what those reps sell. Dual-write is Microsoft's bidirectional, near-real-time bridge that keeps a shared customer, product or order row identical on both sides. For a route-to-market operation it sits on the most sensitive seam there is: the one between the order a field rep captures and the ledger that must bill it. The promise is that the two systems always agree. The mechanism is a row-by-row write across two independent databases — which is exactly where the trouble starts.

Why does the initial sync break before you even go live?

Before any live traffic, both systems have to be seeded — the initial synchronization. Microsoft's own documentation lists the constraints, and they are not edge cases (all figures as documented as of November 2025):

Documented limit	Value	What it means
Lookups per entity map	10 maximum	Initial sync fails outright above ten
Rows per run	500,000	Bigger entities must be migrated by hand, sync skipped
F&O export window	5 minutes	Times out on unindexed or virtual-column tables
Dataverse-to-F&O import result	24 hours	Long runs time out and must be restarted

Two of those numbers do the quiet damage: the 500,000-row cap forces you to migrate large tables outside dual-write entirely, and the five-minute export window is easy to blow on any table with virtual columns or a missing index. The ten-lookup ceiling is the one that catches teams off guard, though. A customer or sales-order map with more than ten related-record references simply will not complete, and Microsoft's guidance for a rich entity is to strip lookups out, sync the map, add a few back, sync again, and repeat until every reference is in — then reassemble the full map and re-enable it in live mode. That is a multi-pass ritual for an entity you were told would just sync.

What happens when a sync gets stuck?

Limits you can plan around. The failure mode that costs sleep is the silent stall. One documented community case describes an initial sync stuck in exactly that state — in the reporter's own words:

running for like 10 days in the dev box … No error information … Cannot stop or re run or trouble shoot

The sync was cleared only when a Microsoft developer reached in and reset it by hand. Read that back as an operations owner: a core link between your CRM and your ERP entered a state its own team could not observe, cancel or recover, and the exit path was a support escalation to the vendor. It is the same specialist-dependency trap we describe when a trade-promo module can only be touched by consultants — except here it is the plumbing between two systems of record, and for those ten days the two systems simply disagreed.

Why is dual-write's coupling the real problem?

The individual limits are symptoms. The underlying issue is architectural: dual-write fuses two independent transactional systems into one distributed write. When the F&O side is slow, blocked by a plugin or mid-upgrade, the CE side's writes queue or fail, and the reverse holds too. There is no durable, replayable log sitting between them that either side can catch up from on its own schedule — the sync is the integration and the buffer at once, so a wobble on one side becomes a stall on both. Consultants who do this for a living say so directly. CloudFronts, writing up their field experience, judge dual-write's intent sound but the delivery otherwise:

the execution of this vision has not been reliable

This is why "eventually consistent" is the wrong comfort here. Eventual consistency assumes an asynchronous, replayable channel that converges on its own; dual-write behaves more like a two-phase commit that occasionally forgets to finish, and leaves you holding two authoritative-looking copies that no longer match. Operating it well means keeping people fluent in both stacks on hand just to watch the seam — the same standing cost we flag for platforms that need a permanent engineering team just to stay live.

What does Microsoft's own pivot tell you?

The most honest signal comes from the vendor. Microsoft now positions virtual entities — a Dataverse proxy that queries F&O's OData API on demand instead of copying rows — as a lightweight alternative to dual-write. A Capgemini analysis frames the trade cleanly: because a virtual entity reads straight from the source, there is never a discrepancy to reconcile and you avoid paying to store the same data twice. When a platform owner ships a lightweight alternative to its own flagship sync, that is a quiet admission that the flagship is heavy and fragile.

The catch is real. Virtual entities cannot join to standard Dataverse tables, so anything that leans on native CE features — Sales, Field Service, the App for Outlook — still needs replicated data underneath it. Reading your records live from another system's store carries its own tax, the same lesson we drew from paying by the seat to query data you already own.

The pragmatic move is to stop treating the CRM-to-ERP seam as a single synchronous write. Put the integration on a durable event stream you control — one event bus where each system publishes and consumes at its own pace, replays from the log after an outage, and never blocks the other. Use virtual entities for read-only lookups where live F&O data is enough, and reserve genuine replication for the narrow set of records that truly must live on both sides.

Each release will nudge the dual-write limits a little higher, and each stuck-sync incident will keep being cleared by whoever holds the support contract. Neither trend touches the structural bet underneath — that two systems of record can be kept identical by writing to both at the same instant. The teams who stay calm about CRM-ERP consistency into 2026 are the ones who decide, on purpose, which records must match, and put a log rather than a live write between everything else.