42. Microsoft Dynamics 365 in carve-outs and PMIs • EL BANTLI

The carve-out team had a clean thesis: move the business from the seller’s aging ERP stack onto Microsoft Dynamics 365, connect finance, supply chain, CRM, and Power Platform, and exit the TSA inside 12 months.

The logic was attractive. The target already used Microsoft 365. The buyer had a preferred Dynamics partner. Finance wanted a modern chart of accounts. Sales wanted better pipeline visibility. Operations wanted less spreadsheet work.

Six months after close, the program was still arguing about tenants, data ownership, and licensing. The seller would not allow full historical extracts without redaction. The buyer’s Microsoft tenant had security policies that blocked several integration patterns. The CRM design assumed customer master cleanup that the business had not staffed. Finance could configure a minimum viable ledger, but supply chain needed more time because item, warehouse, and pricing data were not ready.

Dynamics was not the wrong platform. It was the wrong Day-1 promise.

That is the primary decision for deal teams:

When should Dynamics 365 be the carve-out or PMI platform now, when should it be deferred, and which tenant, data, and licensing constraints must be underwritten before the investment case counts the benefits?

The answer is not “Microsoft versus SAP” or “cloud versus legacy.” The answer is whether Dynamics can meet the deal clock without turning a platform choice into a separation bottleneck.

Where Dynamics helps the deal

Dynamics 365 can be a good deal platform when the business needs a clean operating backbone and the current ERP environment is too entangled, too old, or too costly to keep.

The value case usually sits in five places.

TSA exit: a new Dynamics tenant and ERP environment can break dependency on the seller’s shared ERP, shared reporting, and shared support team.
Finance control: a clean chart of accounts, legal entity setup, close calendar, and approval model can give the buyer better control than inheriting the seller’s old design.
Commercial integration: Dynamics 365 Sales, customer master, pricing workflows, and reporting can support PMI revenue motions faster than forcing the acquired business into a legacy buyer CRM.
Operating scalability: Business Central or Finance and Supply Chain Management can give a mid-market carve-out enough process discipline without a multi-year SAP-style program.
Platform adjacency: Microsoft 365, Entra ID, Power BI, Power Platform, Fabric, and Azure integration can reduce tool sprawl if the buyer already has Microsoft skills and governance.

Those benefits are real, but they only convert to value if the program is sequenced around the deal requirement. Dynamics can move fast for a business with clean scope, limited manufacturing complexity, and good master data. It can slow down badly when tenant separation, regulated data, custom processes, or licensing assumptions are unresolved.

The first choice: Business Central or Finance and Supply Chain

Deal teams often say “Dynamics” as if it is one ERP decision. It is not.

For many carve-outs, the first fork is between Dynamics 365 Business Central and Dynamics 365 Finance and Supply Chain Management.

Business Central is often the better answer for a smaller, simpler carve-out: finance-led, distribution-light, fewer legal entities, limited production complexity, and a need to stand up fast. It can support a pragmatic minimum viable ERP when the buyer needs independence more than deep process redesign.

Finance and Supply Chain Management is usually the better answer when the business has more complex legal entity structures, inventory, warehousing, procurement, production, advanced pricing, or multi-country operating requirements. It also brings more design, data, testing, and program load.

The mistake is choosing the product based on the buyer’s enterprise preference rather than the carved business’s operating requirement.

Use the deal clock as the test:

If the business has fewer than five legal entities, one primary geography, light manufacturing or no manufacturing, and a TSA longer than nine months, Business Central may be enough.
If the business has multi-site manufacturing, regulated inventory, advanced warehouse flows, complex intercompany, or country-specific tax needs, assume Finance and Supply Chain Management unless the scope is explicitly narrowed.
If the TSA is shorter than six months and supply chain complexity is material, do not make full Dynamics transformation the TSA exit path. Use a bridged design or negotiated TSA extension.
If the value plan depends on procurement, inventory, or margin reporting within the first two quarters, test whether the data and process design can be ready before counting the benefit.

This is not a feature checklist. It is a funding and timing decision.

Tenant architecture can become the hidden critical path

Dynamics decisions in deals often fail before ERP design starts because nobody has made the tenant decision.

In a carve-out, there are usually three options.

1) Build in the buyer’s existing Microsoft tenant

This is attractive when the buyer wants standard identity, security policy, reporting, and license management. It may also speed user provisioning and integration with Microsoft 365.

But it can create problems if the acquired business needs different data residency, security boundaries, or operating policies. It can also pull the acquired business into the buyer’s governance model before the operating model is stable.

Use this path when the target will be integrated into the buyer’s operating model quickly and the buyer’s tenant policies can support the acquired workflows without months of exception handling.

2) Build a dedicated tenant for the carved business

This is often the cleaner carve-out answer. It gives the new company its own identity boundary, licensing structure, security policy, and future-sale optionality. PE buyers often prefer it when the asset may be sold again during the hold period.

The cost is extra setup and integration work. Cross-tenant reporting, identity, collaboration, and support processes need explicit design. If the buyer expects shared services from day one, a dedicated tenant can add friction.

Use this path when legal separation, data boundaries, future exit, or standalone operating discipline matter more than immediate platform consolidation.

3) Stay temporarily on the seller or target tenant

This is a bridge, not a strategy. It can reduce Day-1 risk when the seller’s Microsoft environment is deeply tied to ERP, reporting, workflows, and file stores.

The risk is dependency. Every month on the seller’s tenant keeps identity, access, data extraction, and support in the seller’s hands. If the TSA has weak service levels or high project charges, the bridge can get expensive fast.

Use this path only when the exit criteria are written down: named data extracts, access windows, support rights, tenant-to-tenant migration steps, and the date when the buyer controls the critical data.

The data issue is not migration. It is ownership.

Dynamics programs are often scoped as data migration projects: extract, transform, load, reconcile. That misses the deal problem.

In carve-outs and PMIs, the hardest question is who owns each data decision when old definitions do not fit the future business.

Customer master is a good example. The seller may group customers by parent account for global reporting. The buyer may need account hierarchies that match sales coverage. Finance may need legal-bill-to structure. Operations may need ship-to and tax logic. Dynamics can support the model, but it cannot decide which model wins.

The same pattern applies to:

vendor master and bank details
item master, product hierarchy, units of measure, and pricing
chart of accounts, cost centers, departments, and legal entities
warehouse locations, inventory statuses, and lot or serial tracking
open orders, open POs, open AR/AP, and historical transactions
security roles, approval limits, and segregation of duties

If these decisions are not made early, the program will load bad data into a new platform and call it go-live.

The strongest teams treat data ownership as a business design topic, not an IT task. They name data owners for finance, commercial, procurement, and operations. They decide which history moves, which history stays accessible under TSA, and which fields must be clean before cutover.

Licensing can change the economics

Dynamics economics look straightforward until the deal team tests the actual user population and feature scope.

The model may assume a single ERP license estimate. The real design may include Finance users, Supply Chain users, Team Members, Sales licenses, Customer Service licenses, Power BI capacity, Power Apps usage, Dataverse storage, integration tooling, security tooling, sandbox environments, and partner support.

Three issues matter in deals.

First, user counts are often wrong. The seller’s named users may include shared service teams that will not transfer. The buyer may need more users because work previously done by the seller becomes standalone work. Contractors and outsourced providers may need access during migration and support.

Second, license rights may not transfer cleanly. Enterprise agreements, partner discounts, bundled rights, and seller-owned subscriptions can create a true-up at close or at TSA exit. If the buyer assumes it can inherit the seller’s economics, the model may understate run cost.

Third, Power Platform can create shadow cost and control risk. Low-code workflows are useful in a carve-out, but unmanaged apps, premium connectors, and unclear data access can create audit and support exposure.

The underwriting question is simple: what is the run-rate cost of the Dynamics operating model the buyer will actually own, not the seller’s current cost or the partner’s first estimate?

Decision triggers

Use these triggers to decide whether to move now, defer, or bridge.

Move now if the current ERP blocks independence and scope is narrow enough

Move to Dynamics as part of separation when the seller’s ERP is shared, TSA fees are high, and the carved business can run on a minimum viable design.

Good conditions:

TSA exit required within 9-15 months
one primary ERP boundary to replace
limited custom manufacturing or warehouse complexity
named finance, commercial, and operations data owners
buyer or partner has proven Dynamics delivery capacity
first release can run core finance, procure-to-pay, order-to-cash, and reporting without heavy customization

What it changes:

Fund the Dynamics build as mandatory separation cash. Do not bury it inside general transformation. Tie spend to TSA exit, first close, control readiness, and the first value gate.

Defer if the business is operationally complex and Day-1 stability is at risk

Defer the Dynamics transformation when the business has multi-site manufacturing, complex inventory, heavy EDI, regulated quality, advanced pricing, or deep shop-floor integration and the TSA clock is short.

Warning signs:

more than 30 critical interfaces to rebuild
more than three plants or warehouses with local process variation
month-end close above eight business days with manual reconciliations
no clean item, customer, or vendor master owner
seller will only provide partial historical data extracts
the same business leads are needed for separation, audit, and ERP design

What it changes:

Keep the current ERP bridge or seller service where needed. Stand up reporting, controls, and data extraction first. Move Dynamics into a post-stabilization wave with explicit value gates.

Bridge if tenant or data constraints are unresolved

Bridge when Dynamics is likely the right end-state but the team cannot answer tenant, data, or licensing questions before close.

Bridge conditions:

tenant strategy not approved by security and legal
data residency or privacy review incomplete
seller data rights unclear
license transfer or true-up unknown
chart of accounts and legal entity model not final
TSA allows extracts and project support at workable rates

What it changes:

Negotiate TSA terms around the bridge. Buy time deliberately. Do not let “we will move to Dynamics” become a vague placeholder for unresolved deal terms.

Evidence asks

The fastest way to test the decision is to ask for artifacts that expose constraints.

Tenant and identity evidence

Ask for the target’s Microsoft tenant map, Entra ID setup, domains, conditional access policies, privileged accounts, guest access, device management, service accounts, and identity dependencies with ERP, CRM, reporting, and integration tools.

Why it matters:

Tenant design affects user access, data boundary, security policy, migration timing, and support. If identity is unclear, ERP cutover planning is fiction.

Dynamics and Microsoft licensing evidence

Ask for Microsoft enterprise agreements, subscription details, license assignment exports, renewal dates, discount terms, partner agreements, Power Platform usage, Dataverse storage, and any seller-held rights.

Why it matters:

License cost can move from a clean estimate to a run-rate surprise. Renewal timing can also force decisions before the operating model is ready.

Data extract and ownership evidence

Ask for data dictionaries, master data owners, data quality reports, open transaction volumes, retention requirements, seller data restrictions, and sample extracts for customers, vendors, items, chart of accounts, AR, AP, orders, inventory, and historical financials.

Why it matters:

The program cannot migrate what the seller cannot provide or what the business cannot define. Data scope drives timing more than configuration effort.

Process and integration evidence

Ask for process maps across quote-to-cash, procure-to-pay, record-to-report, plan-to-produce, and warehouse flows. Ask for interface inventory, EDI maps, batch schedules, API ownership, failure logs, and reporting feeds.

Why it matters:

Dynamics programs fail when teams configure the happy path and discover late that tax, EDI, pricing, warehouse, or close exceptions run the business.

Delivery capacity evidence

Ask for named business owners, the buyer’s Dynamics architects, partner delivery team, open programs, test environment plan, data migration factory, cutover lead, and post-go-live support model.

Why it matters:

The issue is rarely whether Dynamics can do the job. The issue is whether this team can make the design decisions, load clean data, test the process, and support the business on the required clock.

What goes wrong

The most common failure is a platform answer before a deal answer.

The buyer announces Dynamics as the destination. The seller agrees to provide data “as available.” The partner sizes the build from a thin process scope. Finance assumes the new chart of accounts will be ready for first close. Sales assumes CRM data will be clean enough for cross-sell reporting. Security assumes the new tenant will follow buyer standards. Procurement assumes supplier data can be cleaned after go-live.

Each assumption is manageable alone. Together, they move the critical path.

Then the late-stage trade-offs arrive:

cut over with partial historical data and reconcile manually
extend the TSA and pay higher service fees
reduce ERP scope and run workarounds in spreadsheets
customize Dynamics to mimic broken seller processes
delay synergy reporting because master data is not trusted

The program may still go live. But the deal loses value through TSA extension, duplicate support cost, delayed procurement control, slower close, working capital leakage, and exhausted business teams.

What best teams do

Best teams treat Dynamics as a deal architecture decision. They do not let it become a brand preference or partner-led implementation plan.

They write the minimum viable operating model before selecting the release scope

The first document is not a system design. It is a short operating model that says how the business will run at TSA exit:

which legal entities exist
which processes must run in Dynamics
which processes can stay bridged
who owns customer, vendor, item, and finance master data
which reports are required for management, lenders, and the board
which controls must work from the first close

This forces the platform scope to match the deal, not the other way around.

They separate Day-1 continuity from ERP transformation

If Dynamics is needed for independence, they define a minimum viable release. If it is mainly a value platform, they do not put it on the Day-1 critical path.

The rule is practical: do not combine legal separation, tenant migration, data cleanup, ERP redesign, and process standardization into one go-live unless the business is simple and the TSA gives enough time.

They make tenant and data decisions before partner mobilization

Partners can configure quickly once decisions are made. They cannot compensate for unresolved governance.

Before mobilizing the full build team, best teams force decisions on:

target tenant or buyer tenant
identity model and privileged access
data residency and retention
historical data scope
chart of accounts and legal entity design
license ownership and renewal path
reporting source of truth

This saves money because design churn is expensive. More important, it protects the cutover date.

They underwrite run cost, not implementation cost only

Implementation cash is visible. Run cost leakage is easier to miss.

Best teams build a three-year cost view:

Dynamics licenses by role
Microsoft 365, Power Platform, Power BI, Dataverse, and security tooling
partner support and managed services
integration monitoring and incident support
data storage and archival
internal ERP, finance systems, and reporting roles
parallel run and TSA overlap

Then they compare that run cost against the current state, the TSA cost, and the value plan. A Dynamics move that exits a costly TSA and improves control may be attractive even if run cost rises. A move that adds cost without opening a value gate should be deferred.

A simple decision tree

Start with the deal requirement, not the product.

If the carved business cannot exit the seller’s ERP without a new platform, and the operating scope is finance-led or moderately complex: use Dynamics as the separation platform. Choose Business Central or Finance and Supply Chain based on process complexity. Keep release one narrow.

If the buyer is integrating a smaller acquisition into a Microsoft-led operating model: use Dynamics where it speeds commercial, finance, or reporting integration. Avoid forcing the acquired business into the buyer’s tenant until security, data, and operating policies are clear.

If the asset has complex manufacturing, warehouse, EDI, quality, or regulatory requirements: test whether Dynamics is the right end-state, but do not make full transformation the TSA exit dependency unless the TSA clock and business capacity support it.

If tenant, data rights, or licensing are unresolved: bridge. Negotiate the TSA, data extracts, and license true-up before promising a Dynamics go-live date.

If the buyer expects to sell the asset again during the hold period: favor a cleaner standalone tenant and data model, even if integration with the buyer takes more work. Exit optionality has value.

What to do Monday morning

In the next two weeks, the deal lead, CIO, CFO, and integration lead should force five decisions.

Define the Dynamics role in the deal. Is it a separation platform, an integration platform, a value platform, or a later transformation? One primary role should drive the clock.
Choose the tenant posture. Buyer tenant, standalone tenant, or temporary seller bridge. Name the security and legal owner who signs off.
Build the data decision list. For customer, vendor, item, chart of accounts, open transactions, and history, name the owner, source, quality issue, and cutover rule.
Validate licensing economics. Ask Microsoft, the partner, and procurement for a role-based run-cost model, not just an implementation estimate.
Set the release-one boundary. Write what must be live for TSA exit or synergy measurement, and what waits until the second release.

Dynamics 365 can be a fast path to independence and cleaner operations. It can also become a costly holding pattern if the team treats tenant, data, and licensing as implementation details. Underwrite those constraints before close, then sequence the platform around the deal clock.