Moving an acquired business onto one operating platform can reduce duplicated work and improve visibility, but only if the migration preserves the processes, relationships and controls that make the acquired operation valuable. The decision is not simply whether to consolidate systems. Managers must determine what to standardize, what to migrate with redesign and which exceptions deserve to survive.
Freight technology company sennder provides a useful reported case, not proof that one platform is always best. C.H. Robinson’s regulatory filing says the sale of its European Surface Transportation operations to sennder closed on 1 February 2025. Sennder subsequently completed the integration and says it now runs the combined business on its sennOS platform. EU-Startups reports that the company moves more than 150,000 shipments a month through over 40,000 vetted carriers and is targeting €1 billion in annual revenue in 2026.
Sennder also reports a 45% year-over-year increase in gross profit per operator, which CEO David Nothacker attributes partly to scale and the single platform. This is a company-reported result, not independent evidence that platform consolidation caused the improvement. Scale, pricing, shipment mix, workforce changes and sennder’s stated emphasis on revenue quality over volume could all affect the measure.
The broader lesson is that consolidation should be managed as an operating-model change with explicit baselines, controlled cutovers and evidence-based review.
Begin with operating processes, not an application inventory
A software inventory shows where duplication exists, but it does not reveal how work gets done. Before selecting a target platform, map the main operational flows from the initial request through delivery, resolution and financial settlement. In freight, for example, that could cover order intake, pricing, carrier selection, dispatch, tracking, exception handling, proof of delivery, invoicing and claims.
For every process, record:
- the accountable owner and teams performing the work;
- the systems, interfaces and data used at each step;
- manual decisions and local workarounds;
- customer or supplier commitments attached to the process;
- financial, regulatory and approval controls;
- failure modes, escalation routes and recovery requirements.
This exposes an important distinction. Some differences are accidental duplication; others support a particular customer segment, country, contract or supplier relationship. Removing the first can create value. Removing the second without an adequate replacement can damage service or control.
Classify each capability: standardize, migrate or retain
Standardize
Use one platform and one common process where variation provides little customer value and creates avoidable cost or risk. Candidates may include shared data definitions, access administration, routine reporting, approval thresholds and basic transaction status codes.
Before standardizing, confirm that the common process covers the required transaction types, control evidence and service commitments. Similar labels do not necessarily mean that two processes perform the same function.
Migrate with redesign
Some capabilities belong on the target platform but cannot be copied across unchanged. Historical data may use incompatible definitions, interfaces may need rebuilding, or the acquired process may depend on knowledge absent from the new workflow. These areas require redesigned roles, controls and exception paths rather than a technical transfer alone.
Retain as a governed exception
Keep a legacy capability temporarily—or, in limited cases, permanently—when it supports a material contractual obligation, supplier channel, local requirement or demonstrably stronger process that the target platform cannot reproduce. Every retained exception should have an owner, documented rationale, operating cost, risk assessment and review date. Otherwise, a temporary system can become an unmanaged second architecture.
The target platform should win on operational suitability, not corporate ownership. If the acquired business has the stronger capability in a particular area, adopting it more widely may be better than forcing it onto the acquirer’s system.
Establish baselines before claiming integration gains
Post-acquisition productivity figures are difficult to interpret without a stable starting point. Establish the baseline before major migrations or, if work is already underway, reconstruct it from comparable periods and operating groups. Document changes in definitions, allocation methods and workforce scope so that apparent improvements are not created by a new denominator.
A balanced scorecard should combine economics, productivity, service, control and relationship health:
- Gross profit per operator: useful for assessing labour productivity, but sensitive to pricing, volume mix, staffing and cost allocation.
- Transaction cost: total operating and technology cost per order, shipment, invoice or other relevant unit.
- Error and rework rates: incorrect prices, duplicate records, failed invoices, manual corrections and control failures.
- Service levels: response times, on-time completion, fulfilment performance and resolution time for disruptions.
- Exception backlog: the number and age of cases requiring intervention. Faster average processing can coexist with a growing queue of difficult cases.
- Stakeholder retention: customer, supplier and employee retention in the migrated group, supplemented by complaints and documented reasons for departure.
Segment these measures by migrated versus non-migrated operations, customer type, geography and transaction complexity. A company-wide average can conceal deterioration among strategically important customers or suppliers.
Separate migration savings from scale and workforce effects
A credible integration review should reconcile reported gains into distinct components:
- retirement of applications, infrastructure and vendor contracts;
- reduced manual work or fewer handoffs;
- scale effects such as higher capacity utilization or purchasing leverage;
- commercial effects from pricing, customer selection or transaction mix;
- workforce reductions, vacancies left unfilled or roles relocated;
- temporary integration costs and parallel-running expenses.
This prevents every improvement after cutover from being attributed to the platform. It also makes the business case more useful for future acquisitions. An increase driven mainly by scale, pricing or staffing changes should not be presented as a system saving.
Migrate in waves with stop and rollback gates
A single go-live date concentrates technical and operational risk. A phased migration provides better evidence and limits the impact of failures. Waves can be defined by country, branch, customer group, supplier group or process complexity.
Start with a group large enough to test real operating conditions but not so critical that failure threatens the combined business. Do not select only the easiest transactions: a pilot that excludes important interfaces and exceptions proves little.
Each wave should have entry criteria covering data quality, interface testing, user readiness, support capacity and control approval. Exit criteria should cover transaction completion, reconciliation, service performance and unresolved defects. Set thresholds that pause the next wave, as well as conditions that trigger rollback. Examples include an exception queue exceeding support capacity, failed financial reconciliation, unacceptable service deterioration or loss of required control evidence.
A rollback plan needs more than a backup. It should identify the system of record during transition, how transactions entered after cutover will be reconciled, who can authorize reversal, how affected stakeholders will be informed and how long the legacy environment can remain viable. This guide to de-risking a business data migration before cutover provides a more detailed preparation framework.
Protect continuity beyond the software boundary
Customers and suppliers experience an integration through changed contacts, response times, documents, portals, payment processes and exception handling—not through the architecture diagram. Continuity plans should therefore identify relationship owners and high-risk changes for each stakeholder group.
For major customers, verify that pricing logic, service commitments, reporting formats and escalation routes survive the move. For suppliers or carriers, test onboarding status, payment information, platform access and support channels. Where automation or AI agents are involved, as sennder says they are in load matching, real-time pricing and issue resolution, assign a human owner for exceptions, overrides and adverse outcomes.
Control ownership must also be reassigned explicitly. A person who owned a control in the legacy operation may lose system access or change roles after migration. Every key control needs a named owner, evidence requirements, delegated cover and an escalation path in the combined organization.
Judge the platform after operations stabilize
The first weeks after cutover measure recovery as much as steady-state performance. Review the scorecard at agreed intervals and compare like-for-like groups against the baseline. Investigate apparent gains accompanied by rising exception backlogs, slower resolution, stakeholder losses, manual work outside the platform or weakened controls.
A single platform is successful when it lowers the cost and complexity of running the combined business without shifting hidden work to customers, suppliers or frontline teams. Sennder’s reported integration illustrates the ambition and potential scale of that model, but its financial and productivity indicators should be assessed over time alongside service, control and retention measures.
For acquisition managers, the decisive question is not merely whether both businesses can use the same platform. It is whether the combined operating model can perform reliably on it—and whether management can demonstrate where any improvement came from.
