Two Cores. One Company. One Close.

A European industrial group already ran S/4HANA as its global template. Then it acquired a North American and UK business that ran Dynamics 365 Finance and Supply Chain. Eighteen months of middleware later, they still could not close as one company. We, at Futluz, moved the acquired entities onto the group S/4HANA template—and retired Dynamics 365—because two cores were failing the operating model, not because Dynamics 365 was a bad product.

TL;DR

Problem: Group on S/4HANA; acquired division on Dynamics 365 F&SCM. Dual charts, dual ATP, dual costing, and a 12-day consolidated close held together by 90-plus interfaces.

Approach: Greenfield onto the existing group S/4HANA 2023 template—not a second SAP design. Fit-gap against what the group already ran. Master data first. Open documents and balances from Dynamics 365; history archived, not converted.

Scale & results: 8 company codes, 6 plants, 38,000 SKUs, 24,000 business partners. Group close from 12 days to 6. Intercompany stock-in-transit and profit-in-inventory moved into the system of record. Dynamics 365 decommissioned after 90 days of read-only hypercare.

Why it worked: The steering case was organisational, not religious. Stay-on-Dynamics, reverse-the-group, and two-tier ERP were all evaluated and rejected with numbers. Scope was the group template plus the few process deltas the plants actually needed.

The client challenge

The parent is a European industrial group: roughly €4.8 billion in revenue, 22 legal entities, 14 plants. Finance, controlling, MRP, intercompany, and statutory reporting already ran on one S/4HANA instance across Germany, the Netherlands, India and China.

The acquisition was a North American and UK manufacturer of roughly $1.1 billion: six plants, eight company codes, USD, GBP and CAD, make-to-order with a discrete overlay. Its ERP was Dynamics 365 Finance and Supply Chain Management on Azure, live, supported, and familiar to the people who ran it.

The deal closed. The operating model did not. Group plants supplied the acquired plants with components. Each ERP posted its own goods movements, markup and stock in transit. Profit in inventory lived in spreadsheets. Transfer-price adjustments arrived after the books were already “closed.” Sales promised dates from Dynamics 365 ATP while capacity and shortage lived in S/4 MRP. Expedites and dual inventory were the workaround. SKU margin across the combined portfolio was not a number anyone would sign, because Dynamics 365 used standard cost with a different overhead model and the SAP plants used actual costing through the Material Ledger.

Shared-services finance could not run one close calendar. The IFRS pack and the management pack never landed on the same day. The integration estate—Azure Service Bus, Logic Apps, IDocs, files—had become the strategy: ninety-plus flows keeping two masters of customer, vendor, material and BOM in approximate sync. Every process change had to be built twice.

Why not stay on Dynamics

Dynamics 365 was viable as a standalone company. It was not viable as a division of an S/4HANA group that needed one intercompany model, one close, one ATP check and one costing standard. That is the whole case. We put the other options on paper so the steering committee could reject them in public.

1. Keep Dynamics 365 and integrate harder: Already tried for eighteen months. Spend was high and still did not produce one set of numbers. Integration was masking the dual-core problem, not solving it.
2. Move the group onto Dynamics 365: Fourteen plants, Material Ledger, variant configuration and statutory templates were already on S/4HANA. Reversing the group standard was the larger programme, with more statutory risk, not less.
3. Two-tier ERP: Attractive if the acquired plants had been lightweight commercial subsidiaries. They were not. They make and ship into the same network. A corporate S/4 with Dynamics 365 in the plants would have left ATP, costing and intercompany exactly where they were.
4. Migrate the acquired entities onto the group S/4HANA template: Selected. One core, one master-data model, Dynamics 365 retired after hypercare. Process improvement inside the acquired plants was sequenced as a second wave, so go-live had one variable: get onto the template.

Our solution

1. Fit-gap against the group template, not a blank S/4
   • We did not design a second SAP. We walked the acquired plants against the configuration, master-data groupings and roles the group already used.
   • Process deltas survived only where the plants had a real constraint—configure-to-order and customer-owned tooling. Everything else was adopted. That decision removed months of “our Dynamics way versus their SAP way” workshops.
2. Master data first
   • Material, business partner, BOM, routing and pricing were mapped to group standards before a single open document was converted. Dynamics 365 financial dimensions were not one-to-one with S/4HANA cost objects; that mapping was the programme, not a load file.
   • 38,000 SKUs and 24,000 business partners were cleansed, duplicated and re-numbered onto group ranges. Local identifiers were retained as alternative numbers so plant paperwork and EDI partners did not break on Monday morning.
3. Migration from Dynamics 365, not a history dump
   • Open purchase orders, production orders, sales orders, batch and serial stock, and GL balances moved through the migration cockpit plus a controlled extract from Dynamics 365. Each company code reconciled to the Dynamics 365 trial balance before sign-off.
   • Five years of line-item history stayed in an archive. Converting it would have lengthened the programme for auditors who did not need it in the live ledger.
4. Finance on the group model from day one
   • Group chart of accounts, group ledgers, New Asset Accounting, and Material Ledger live at go-live—not as a later finance project. Without actual costing in the former Dynamics plants, SKU margin would have remained incomparable.
   • Intercompany was redesigned as a process: one stock-in-transit treatment, one profit-in-inventory posting, no spreadsheet bridge. Transfer pricing sat in the template, not in a quarterly adjustment file.
5. Rewrite the interfaces; do not reuse the dual-ERP ones
   • Dynamics-centric Azure integrations were replaced with the group’s SAP Integration Suite and MES patterns. Dual-running EDI for eight weeks covered the trading partners who could not cut on the same weekend.
   • Dynamics 365 Sales and Customer Service were left in place. CRM was not on the critical path, and pulling it into the same cutover would have added a change programme the plants did not need in order to ship.
6. Rehearse the cutover until the runbook is boring
   • Four dress rehearsals on production-sized copies. Mock 2 failed on batch-stock reconciliation at 02:40. The team recovered, root-caused the unit-of-measure conversion, and re-ran the following weekend. That failure is why go-live held.
   • Cutover window: Friday 18:00 group time to Monday 06:00 first plant start. Dynamics 365 frozen read-only for 90 days, then decommissioned.

Eighteen months, one template

Peak team of thirty-six, held together for the duration: business analysts who had already lived through the group’s own S/4 programme, a finance and controlling core, supply-chain and manufacturing analysts on the plant floors in Ohio, Ontario and the Midlands, developers for the extract and interface rewrite, QA, and a Basis and security cell working with the group’s existing AMS.

The analysts did the work that does not show in a tool log. They sat with plant controllers until the Material Ledger numbers were numbers the controllers could explain. They walked warehouse leads through batch and serial handling that Dynamics 365 had allowed to drift plant by plant. They refused to invent a local SAP for “how we used to do it in D365.”

QA simulated the group close three times in a converted copy before go-live, because the first close after an acquisition migration is where an unmapped dimension becomes a restatement. Two of those simulations found something. Both were fixed before the weekend that counted.

Programme management held the same line as our ECC conversions: no scope after the fit-gap freeze. CRM, warehouse redesign, and “while we are in there” Fiori catalogues went to wave two. The acquired plants had already absorbed an ownership change. They were not going to absorb a process revolution on the same weekend as an ERP cutover.

What changed for the people using it

Plant controllers in the acquired business close on the group calendar instead of sending a pack for someone in Europe to re-key. Planners see capacity in the same network they promise against. Buyers stop maintaining two vendor masters for the same supplier. None of this required Dynamics 365 to have failed. It required the company to stop running as two companies.

Business impact

Risk: Off a dual-core operating model that could not produce a number the board would sign, onto the platform the rest of the group already used to plan, cost, ship and close.

Cost: Dual licence, dual master data, and the standing integration team came out after hypercare. The twelve-day close stopped consuming a finance shared-service month.

Speed: Promises, shortages and margins visible in one system, in time to act in the same week.

A Dynamics 365 to S/4HANA move is not a verdict on Microsoft. It is a judgement that one global manufacturer cannot keep two systems of record after an acquisition and still close, promise and cost as one. We bring the SAP template discipline and the programme restraint; the reason has to be the operating model, or the programme should not start.