Mergers & Acquisition Due Diligence
B2B Transportation Hub
- Industry
- B2B Transportation & Logistics
- Service
- Technical Due Diligence | Cloud Migration Planning | Cybersecurity Assessment | Vendor Contract Re-negotiation
Overview
The client asked Sphere’s leadership team to evaluate a B2B transportation hub’s technology in preparation for an acquisition. In an interesting turn of events, the client placed more value on the business assets — the customers and vendor network — than on the technology that ran the business.
As a result, the scope of this due diligence was maintenance-focused: what would it cost to maintain the technology, transition the customers, and then decommission the technology over a 12–18 month period?
Risks Surfaced
Scarce, Expensive Talent
Finding talent familiar with the dated technology stack would be difficult and expensive — driving up the cost of every month the platform stayed alive.
OS Nearing End-of-Life
The old operating system was nearing end-of-life, forcing an immediate migration to the cloud rather than a leisurely 12-month windown.
Cybersecurity Exposure
Security issues stemming from the legacy OS required additional cybersecurity assessments as part of the migration — a hidden line item in the deal.
External Vendor Contract
The external development team’s agreement included a revenue-share clause that complicated the acquisition and created serious financial risk for the buyer.
Risk-Mitigation Plan
The client was willing to take a number of risks because the business value of the acquisition outweighed the technology limitations. To make the deal viable, Sphere put a structured risk-mitigation plan in place around three concrete moves:
1. Re-negotiate the External Development Team’s Contract
Removed the revenue-share clause that compounded acquisition cost and replaced it with a fixed maintenance retainer aligned to the planned 12–18 month wind-down — converting an open-ended liability into a known operating expense.
2. Migrate from the Outdated OS to AWS
Lifted the application off its end-of-life operating system and onto AWS, ahead of the OS reaching end-of-support. The migration unblocked talent acquisition and made the security posture defensible.
3. Lock Down Security and Run “As Is” for 12 Months
Following the OS migration, the platform was security-hardened and run “as is” for 12 months — long enough for customers to be transitioned cleanly before the legacy system was decommissioned.
The Results
For each risk, a mitigation plan was put in place. Understanding the risks, the client made the decision to acquire the business and technical assets of the target. The OS migration was successful, the customers were transitioned without disruption, and the legacy platform was decommissioned on schedule.
