Switching platforms is expensive, disruptive and sometimes clearly the right decision. The failure mode is switching for the wrong reasons, or switching for the right reasons without accounting for the true cost.
When switching is justified
- The vendor is failing structurally — repeated outages, support degradation, no development
- Vendor viability risk — financial difficulty, acquisition with an unclear roadmap, product sunset announced
- Your operation has outgrown the product in a way that cannot be configured around
- Cost has risen beyond what the market requires, and negotiation has failed
- A capability you now genuinely need does not exist and is not coming
- Security or compliance requirements the vendor cannot meet
A large proportion of platform replacements solve nothing, because the problem was data quality, configuration or process — all of which migrate perfectly to the new system.
When it is usually not
- Poor configuration presented as a product failure. Most "the system can't do it" complaints are configuration or training issues.
- Bad data. Migrating bad data to a new platform produces the same problems in a new interface.
- A single frustrating feature in an otherwise adequate product.
- A new manager's preference for a familiar product.
- A cheaper quote that has not been modelled over five years including migration cost.
Before committing to a switch, run a structured review of what is actually failing. A remediation project with your current vendor costs a fraction of a migration and frequently solves the problem.
The true cost
| Cost | Frequently overlooked |
|---|---|
| New platform licence | No |
| Implementation | No |
| Data extraction from the incumbent | Yes — sometimes chargeable |
| Data transformation | Yes — formats never align |
| Parallel running | Yes — paying for both |
| Retraining everyone | Yes |
| Productivity dip | Yes |
| Integration rebuild | Yes — every connection |
| Hardware replacement | Sometimes — telematics devices rarely transfer |
| Historical archive | Yes — where to keep it and how to read it |
| Internal project effort | Yes, consistently |
Telematics hardware deserves specific attention: devices are generally vendor-specific, so switching telematics providers means removal and installation across the fleet, plus the residual value of the devices you are discarding.
Extracting your data
Start here, before signing with anyone new.
- Read your contract. What are you entitled to, in what format, in what timeframe, at what cost?
- Request a full export now, while the relationship is intact. Vendors are less accommodating once they know you are leaving.
- Inspect what you receive. Are attachments included? Are relationships preserved? Is it documented?
- Identify gaps — data you cannot extract in usable form. Decide now how you will handle it.
- Plan the archive for data you will not migrate. A read-only archive with a documented retrieval method, retained for your compliance period.
Compliance records deserve particular care. Inspection records, driver hours and maintenance history may have statutory retention periods that outlast your relationship with the vendor. An archive you cannot read is not a record.
Running the migration
1. Overlap deliberately. Run both systems for a defined period — typically two to six weeks — with a hard end date. Open-ended parallel running means the old system wins.
2. Migrate in the right order. Reference data, assets, open transactions, then history. See data migration.
3. Do not migrate everything. Use the switch as an opportunity to leave behind data nobody uses. Migrate open items and the history you genuinely need.
4. Rebuild integrations early. They are the longest lead-time item and the most likely to slip.
5. Retrain properly. People who know the old system need more retraining than new users, not less, because they have habits to unlearn.
6. Keep the old system read-only for at least 90 days after cutover, and confirm you can still export from it.
7. Manage the incumbent relationship. Give proper notice, meet your contractual obligations, and stay professional. You may need their cooperation during transition, and their transition assistance obligations are worth invoking calmly rather than adversarially.
Common questions
How long does switching take?
For a fleet or route platform, typically three to nine months from decision to full cutover, depending on integration complexity and data volume. It is usually longer than the original implementation, because you are migrating history as well as building new.
Can we switch without losing history?
Usually you can migrate the operational history you need, though some detail — audit logs, system-generated records, attachment metadata — rarely transfers cleanly. Plan a read-only archive of the incumbent's data for anything you cannot move.
What if the vendor will not give us our data?
Check the contract first; most oblige provision. Escalate formally, involve legal if necessary, and note that data protection law in many jurisdictions gives independent rights over personal data. This situation is exactly why export terms belong in the original contract.
Should we tell the incumbent we are looking?
Usually yes, and often before you start — a serious remediation conversation sometimes resolves the problem, and it always improves your negotiating position. Extract your data first if you have any concern about the reaction.
Is it worth switching to save money?
Only after modelling the full switching cost against the five-year saving. Migrations frequently cost more than one to two years of the saving, so the case needs a long horizon and a confident view that the new vendor is genuinely better, not just cheaper.
