I have led four platform integrations at Webfleet and have seen the results of a lot more in my M&A-work recently. In every one of them, the number that mattered most was the one that never appeared in the business case.
In The Fleet Management M&A Situation in 2026 I argued that the buy-and-build thesis in this industry is broken, and that the cost of actually merging two platforms is a large part of why. That claim got one paragraph there and deserves more, because it is the part of the model that buyers consistently get wrong. This is the long version.
Three years for a migration of a bought in platform to a new one is achievable. I have seen migrations in this industry completed in three years, done properly, with the customer base largely intact at the end. I have also seen migrations that were still unfinished after seven, and in my experience those are the more common outcome. Not because the teams were weak, but because the work has a structure that makes it resistant to the things that normally speed projects up.
This matters beyond the engineering department. It is the single most underestimated line item in fleet management M&A, and the reason a great many buy-and-build stories in our industry delivered less than the model promised.
If you read CIMs in this space, you will recognise the pattern. An acquired portfolio is presented as an integrated platform. Ask a few specific questions and it often turns out that besides single sign-on, very little has actually been merged. In most cases the people writing the deck have simply underestimated what integration means when there is hardware in the field.
Here is what makes it different.
You Cannot Flip a DNS Record
In normal software migration, cutover is a configuration change. Point the traffic somewhere else, watch the dashboards, roll back if something breaks.
Every vehicle in a fleet management system has a physical device in it, and that device points at a specific backend URL or APN. Moving it means an over-the-air reconfiguration if you are fortunate and the device supports it, and a workshop visit if you are not. Across thousands of vehicles that are in active duty, earning money for their owners, on routes that were planned weeks ago.
The rollback story is worse. A botched cutover produces dark vehicles, meaning a customer who cannot see part of their fleet, cannot prove driving times, and cannot answer their own customers’ questions about where a delivery is.
OEM-installed hardware will make this easier, eventually. But how many of those will you have in your acquired legacy platform? Thought so.
The Installed Base Is Not One Thing
An acquired platform typically arrives with five to ten generations of hardware from multiple vendors. Each generation has different firmware capabilities, different protocol support, different quirks that somebody documented once and then left the company.
The newest thirty percent is usually straightforward. The oldest ten percent is where migration projects go to die: devices that cannot be updated remotely, devices whose manufacturer no longer exists, devices sitting in vehicles whose owners have no appetite for a workshop appointment to solve a problem they do not have.
That long tail is small in unit terms and enormous in effort terms, and it belongs to customers who are frequently among the longest-tenured and most valuable in the base.
The Data Does Not Mean the Same Thing
This is the part that surprises people who have done software migrations elsewhere.
Source and target systems speak different dialects of CAN and FMS interpretation. They use different event taxonomies. They implement different tachograph parsing logic. Speed in system A is not speed in system B: one may be sampled at 1Hz and the other at 10Hz, one raw and one filtered, one GPS-derived and one taken from the vehicle bus. Trips are worse, because a trip is a derived concept and every platform derives it slightly differently.
Meanwhile the customer expects unified definitions across all their vehicles and all their drivers, because that is what they were promised, and because their own reporting depends on it.
History Travels With the Customer
Customers expect one to three years of history to come along, and in many cases the law agrees with them. Tachograph records, driving time documentation and accident reconstruction data all carry retention obligations.
Migrating terabytes of time-series data while preserving semantic fidelity is a project inside the project. And even when it is done carefully, KPIs re-derived on migrated data rarely match the originals exactly. A fuel consumption figure shifts by two percent. A driver score moves. An idling report that a customer has been using for years to run a bonus scheme now says something slightly different.
Many migrations decide to skip this, on the reasonable grounds that the data is old and the effort is enormous. They pay for it later in churn. Because after all, if the customer loose their history anyways, they might as well switch to a competitor now and many will.
Your Timeline Belongs to Your Customer
This is the structural point, and it is the one that makes calendar time so hard to compress.
Every larger fleet has API consumers, ERP and TMS integrations, dispatch couplings, BI dashboards, fuel card connections and insurance feeds. Each of those is a separate migration project, and most of them are owned by the customer’s IT department or by a third party you have no relationship with. Those parties do not follow your schedule, they will rather strongly oppose it.
Driver-facing systems make it harder still. Driver IDs, DDD downloads, in-cab terminals, navigation devices and messaging all have to be updated, and drivers are the hardest stakeholder group to retrain at scale.
The connectivity estate is its own negotiation. M2M contracts, APNs, eUICC profiles and roaming agreements are tied to the legacy platform, and your counterparty in that negotiation frequently stands to lose revenue once you complete the move. Their incentive to be quick is negative.
And legacy contracts often guarantee specific features, specific screens, specific reports, occasionally even specific URLs. Functionally equivalent rarely means contractually equivalent, and experienced customers use a migration as leverage to reopen commercial terms. Your clock is ticking. Theirs is not.
Dual-Running Is the Real Cost
Because of everything above, you do not switch. You run both platforms in parallel, typically for twelve to thirty-six months. Or more. Sometimes a lot more.
Double infrastructure. Double support organisation. Double on-call rotation. Every bug fixed twice, every compliance deadline met twice, every new customer commitment evaluated against two roadmaps. Exactly at the point in the ownership period when you can least afford it, because the acquisition has already consumed the budget.
Meanwhile the regulatory clock does not pause. Tachograph deadlines, GSR requirements and CO2 reporting obligations arrive on their own schedule, and they compete with the migration for the same engineering capacity. So does the feature an important customer has been promised.
What This Costs an Acquirer
I have seen cases where more than half of an acquired company’s installed base had churned out before the migration was completed.
That number deserves a moment. The buyer paid a multiple on a subscriber base. By the time the platform consolidation that justified the multiple was actually delivered, a large share of those subscribers were gone. Not because anything dramatic happened, but because migration is precisely the period during which a customer relationship is most fragile, and because a migration that drags on for years gives every competitor a standing invitation.
Customer trust is the currency being spent here. Every hiccup, a missing trip, an incorrect driving time, a broken report on payday, erodes trust that took years to build. Migration risk is reputational as much as technical, and rushing is the most reliable way to increase churn rather than reduce it.
Where AI Helps and Where It Does Not
There is real leverage available now. Protocol translation, data model mapping, test generation, migration tooling, and the analysis work of understanding an unfamiliar legacy platform have all become dramatically faster. I would expect a modern migration team to move through the engineering portion considerably quicker than we did at Webfleet back in the days.
None of that compresses calendar time, because the binding constraint sits outside engineering altogether. It is when a vehicle can come into a workshop, when a customer’s IT department will schedule the API work, when drivers can be retrained, when a connectivity contract can be renegotiated, and when the customer is willing to accept the disruption. Those are decisions made outside your organisation, on timelines you do not control.
The right conclusion is that AI moves a three-year migration to perhaps two and a half, and does nothing at all for a seven-year one, because seven-year migrations are not slow for engineering reasons.
How to Underwrite This Honestly
If you are buying, or selling, in this space, three questions get you most of the way.
How many production platforms are actually running today, and how many teams are maintaining them? Not how many are planned to be consolidated. How many exist.
What is the age profile of the installed base, and what forced replacement events are coming? A network shutdown or a homologation refresh imposes a hardware cycle nobody chose, and it interacts badly with a migration already in progress.
What happened to the customer base during the last integration this company completed? If they have done one before, the churn curve through that period is the most honest number in the data room.
I go into what this means for valuations and current deal structures in The Fleet Management M&A Situation in 2026.
