Post-Merger Technology Integration for a Logistics Group

Mergers are announced in press releases. They’re completed in operating systems. When two mid-sized logistics companies merged — combining a road freight operator on Oracle and AWS with a last-mile delivery business on SAP and Azure — the board gave IT eighteen months to make them function as one company. Nematix was engaged to lead the technology integration from day one.

The result: a single technology stack operational in sixteen months, twenty-three percent fewer software licensing costs, and thirty-one of forty-seven overlapping systems retired.

The Situation

Company A was a regional road freight operator with 1,200 employees, 400 vehicles, and an Oracle ERP that had been the operational backbone for eight years. Their infrastructure ran on AWS. Company B was a last-mile delivery specialist with 800 employees, a gig-economy driver network, and SAP S/4HANA implemented two years earlier. Their infrastructure was on Azure.

The merger closed. The CEO announced a single brand to market. Customers — many of whom used both companies without knowing it — were promised a seamless combined service within a year. Behind that announcement, IT had a 47-system overlap, two incompatible ERP instances, two cloud estates with different tooling conventions, and two engineering cultures that each believed their stack was the right one.

There was no integration playbook. There was a deadline.

The Challenge

The complexity was technical, organisational, and political simultaneously.

On the technical side:

• Oracle and SAP used fundamentally different data models for the same concepts — a “shipment” in Oracle was not the same record structure as a “shipment” in SAP, and neither mapped cleanly to the other without transformation
• AWS and Azure required different tooling, different security models, and different cost management approaches; running both indefinitely was expensive and operationally complex
• Forty-seven systems overlapped in function — two fleet management platforms, two customer portals, three monitoring tools, four communication platforms — each with its own data and user base
• Neither ERP had clean APIs; both required significant integration work to build a unified data layer

On the organisational side:

• Company B’s engineering team had implemented their SAP instance recently and had strong ownership of it; they were resistant to a decision that appeared to be made on seniority rather than merit
• Both companies had customers mid-contract who expected service continuity; any system migration that caused a delivery failure would have immediate commercial consequences
• The board’s 18-month deadline was publicly committed; slipping it would generate press coverage

Our Approach

Nematix started not with a solution but with a full inventory. In the first six weeks, we mapped every system in both estates — its function, its user base, its data dependencies, its contract terms, and its migration complexity. This produced the input for a “keep, migrate, retire” framework applied to all ninety-three distinct systems across both companies.

ERP decision (weeks 4–8)

The ERP choice was the most consequential decision in the programme. We ran a structured evaluation: SAP S/4HANA was newer (2-year-old implementation versus 8-year-old Oracle), had a larger combined user base, and had stronger native integration with last-mile logistics capabilities. More practically, SAP’s partnership with Azure made the infrastructure consolidation cleaner. The recommendation — SAP on Azure as the target state — was presented to both leadership teams with the full analysis. Company A’s leadership accepted it after seeing the data.

Unified data layer first (months 2–7)

Before migrating anyone to anything, we built a unified data warehouse on Azure Synapse that both ERPs wrote to. This gave management a single view of operations across both companies immediately — without waiting for full migration. Finance could see consolidated P&L. Operations could see combined fleet utilisation. Customer service could see the full order history regardless of which company had originated the shipment.

This layer also served as the integration test bed: by validating that both systems could produce consistent, reconcilable data, we confirmed the migration mappings before committing to a cutover.

System rationalisation (months 3–12)

Concurrently, we worked through the 47 overlapping systems. The principle was: pick the better tool, migrate the users, retire the other. Where neither tool was superior, we evaluated replacing both with a best-of-breed alternative. Thirty-one systems were retired. Nine were consolidated to one instance. Seven required active migrations with data portability work.

ERP migration (months 8–16)

Oracle was migrated into SAP using a phased cutover by business unit: finance first, then fleet management, then customer operations. Each phase ran a four-week parallel operation period before the Oracle module was switched off. The migration included re-mapping eight years of Oracle transaction history into SAP’s data model — 340 million records.

Infrastructure consolidation (months 6–16)

AWS workloads were assessed for Azure compatibility and migrated progressively. Thirty percent of AWS-hosted workloads were retired outright as part of the system rationalisation. The remainder migrated to Azure, completing two months before the ERP cutover.

Outcome

The merged entity began operating on a single ERP and single cloud provider two months ahead of the board’s deadline. Customers experienced no service disruptions attributable to the technology integration.

Key Takeaways

Build the unified view before the unified system. The data warehouse gave management visibility and built confidence in the migration data mappings before anyone was asked to switch systems. The integration felt less risky because the data reconciliation had already been validated.

Let data drive the ERP decision. The choice between Oracle and SAP was politically charged. Framing it as a structured evaluation with published criteria — and presenting the analysis transparently to both leadership teams — made the decision defensible and reduced resistance significantly.

System rationalisation is a merger dividend. Forty-seven overlapping systems represent real cost and complexity. The discipline of retiring them — even when it required user migrations — produced savings that paid for a meaningful portion of the integration programme itself.

This engagement draws on our Strategy & Transformation services. Contact us if you’re navigating a post-merger technology consolidation.