Post-acquisition D365 onboarding: interim connectors first

A familiar scenario in M&A-active industries: an enterprise running D365 Finance acquires a new business unit that comes with its own ERP, its own processes, and its own timelines. The new unit needs to start reporting to headquarters soon - consolidated P&L, consolidated balance sheet, intercompany visibility - without disrupting the existing D365 environment.

Two tempting options surface in planning meetings. Both carry more risk than the middle path.

Two wrong extremes

"Rebuild the unit's processes in D365 immediately, retire the legacy ERP now." The appeal is speed and clean integration. The risk is disrupting the acquired unit's operations during the most sensitive post-acquisition window. Employees are already anxious about the acquisition; adding "your ERP changes on Monday" on top accelerates attrition. Six months later, the acquired unit has burned goodwill and the D365 team has a checklist of processes that weren't captured during the rushed migration.

"Maintain separate systems indefinitely and treat them independently." The appeal is stability - don't fix what isn't broken. The cost is permanent: no consolidated reporting until someone builds it, no intercompany automation, no master data alignment. Finance teams end up rebuilding everything manually for quarterly reports.

The third option - importing monthly financial summaries into D365 from Excel - isn't even a serious answer. It's a stall.

The pattern that fits

Interim data connectors for the 3-5 essential processes now, phased migration of the acquired unit into D365 over 12-24 months.

Short-term integration covers only what the business actually needs:

• Monthly or weekly trial balance from acquired-unit ERP to D365's consolidation framework
• Customer master sync (so both companies know which customer is shared)
• Vendor master sync (so procurement sees the combined spend picture)
• Intercompany invoicing flow for transactions between parent and unit
• Possibly: shared employee master if HR is moving fast

Long-term plan is a full migration of the acquired unit into D365, scheduled over 12-24 months based on business readiness.

Why interim connectors first

The split approach buys the right things:

• Business continuity for the acquired unit. They keep running their ERP, their processes, their systems during the integration window.
• Financial visibility for the parent. Consolidated reporting works from day 1 through the interim connector.
• Learning time for the integration team. During the 12-24 month window, the team can actually understand the acquired unit's business before forcing it into D365 shapes.
• Migration planning data. The interim connectors surface data quality issues, process differences, and integration surfaces that a rushed migration would miss.

By the time full migration happens, the parent team knows the acquired unit's data inside-out.

Interim connector architecture

Options for the short-term integration:

Dataverse + dual-write. If the acquired unit can integrate into Dataverse (most modern ERPs can, via their own API), dual-write then syncs to F&O. Clean, low-latency, and doesn't need retiring when the migration happens.

Azure Logic Apps or Data Factory. For legacy systems that can't talk cleanly to Dataverse, Azure middleware pulls from source via custom APIs or database connections and writes to D365 via data entities. Retires when migration completes.

DMF recurring integration. For lower-frequency needs like monthly trial balance, recurring DMF projects with Azure Storage as the handoff point work well. Scheduled, resumable, auditable.

Power Automate for workflow-scale. Low-volume process integration (e.g., notify parent procurement when acquired unit places a big PO) fits Power Automate without over-engineering.

Pick the option that matches the volume and latency of each process. Not every integration needs to be real-time.

Consolidation during the interim

Standard D365 consolidation supports manual import of trial balance from non-Dynamics sources. The acquired unit's month-end close produces a trial balance; DMF (or a direct integration) imports it into the consolidation. From there, the consolidated financial reports carry the acquired unit alongside D365-native entities.

This is standard functionality - no custom build required.

Migration planning in parallel

While interim connectors keep the business running, the migration team can:

• Map the acquired unit's chart of accounts to parent's framework
• Profile master data for quality and duplication
• Document process differences (approval hierarchies, closing procedures, fiscal calendar)
• Plan the legal entity structure (does the acquired unit get its own LE or fold into existing?)
• Schedule the cutover in waves (HR first, finance second, supply chain last - or whatever fits)

The migration plan ships 12-18 months into the acquisition, when everyone actually knows what they're migrating.

When to skip the interim path

There are scenarios where immediate full migration is the right call:

• Acquired unit has dying infrastructure (end-of-life ERP, no support contract)
• Acquired unit is tiny relative to parent (absorbing 20 people is different from absorbing 2,000)
• Business model overlap is so complete that running two ERPs creates confusion
• Regulatory timeline forces a unified system

Even in these cases, the migration gets planned as a phased cutover, not a weekend switch.

What ships with the interim architecture

A working post-acquisition integration has: the 3-5 essential process integrations live, consolidation configured to accept manual trial-balance input from the acquired unit, master data sync discipline between systems, a documented migration roadmap with dates by function, and governance for decisions about what moves when.

The design is deliberately boring for the interim period. The point is to not break anything while the real migration plan takes shape. That's architect judgment: sometimes the right answer is "do less now so the larger project works later".