Migration is where a new system earns or loses credibility. Users judge a platform in its first fortnight, and what they judge is whether the data looks right. Everything else is recoverable; a reputation for wrong numbers is not.
Decide scope before touching data
Four questions, answered by the business owner, in writing:
- Which objects migrate? Assets, drivers, work orders, parts, documents, fuel transactions, telematics history, customers.
- How much history? Per object, with a stated reason.
- What is the cut-off? A date after which records exist only in the new system.
- What happens to the old system? Read-only archive, exported to files, or decommissioned — and who pays for it during the retention period.
A defensible default for a fleet system:
| Object | Migrate | Rationale |
|---|---|---|
| Assets | All active, plus disposed within 24 months | Reporting continuity |
| Open work orders | All | Operational necessity |
| Closed work orders | 24 months | Cost trending and warranty |
| Major lifetime events | All | Engine replacement, accident repair, ownership change |
| Documents | Current valid only | Expired certificates rarely have value |
| Fuel transactions | 12–24 months | Consumption baselines |
| Parts stock | Current balances only | History rarely useful |
| Telematics | None or 3 months | Volume is huge, value is low; keep it in the telematics platform |
Every extra year of history multiplies transformation effort, validation effort and the number of edge cases.
The five-stage process
1. Profile. Before cleansing, measure. Record counts, null rates per field, duplicate candidates, value distributions, referential integrity failures. This profile is your baseline and your evidence later.
2. Cleanse at source. Fix data where it is created wherever possible. Cleansing in a transformation script means the source keeps producing bad records and you repeat the work at every future migration.
Typical cleanse tasks:
- Standardise registration and VIN formats
- Resolve duplicate assets from depot mergers
- Fill missing acquisition dates and costs
- Normalise vendor and part names
- Reconcile the asset list against finance's fixed asset register
- Verify current odometer readings against telematics
3. Map and transform. Field-by-field mapping documented in a spreadsheet both vendor and customer sign. Include: source field, target field, transformation rule, default when null, and validation rule. Ambiguity here becomes an argument at go-live.
Watch for classic traps: date formats, units (miles versus kilometres, litres versus gallons), currency, character encoding, and enumerated values that do not map one-to-one (your six vehicle statuses into their four).
4. Load in cycles. Never a single attempt.
| Cycle | Purpose |
|---|---|
| 1 | Technical load — does it import at all? |
| 2 | Full-volume load — performance and edge cases |
| 3 | Business validation — users check their own data |
| 4 | Dress rehearsal — timed, scripted, exactly as go-live |
| 5 | Go-live |
5. Validate and prove. Three layers:
- Counts — records in, records out, rejects explained.
- Totals — sum of asset acquisition cost, sum of open work order value, count of active documents.
- Spot checks — 20 records chosen by users, including the awkward ones, verified field by field.
Publish the reconciliation. A one-page document showing counts and totals matching is worth more to user confidence than any amount of assurance.
Reference data first
Load in dependency order or you will spend days on failed constraints:
- Organisational structure — depots, cost centres, entities
- Users and roles
- Vendors and suppliers
- Parts catalogue
- Vehicle classes, makes, models
- Assets
- Drivers
- PM schedules
- Open work orders
- Historical work orders
- Documents
The rejects file
Every load produces rejects. The failure mode is not the rejects — it is nobody owning them. Assign a person, review the file after every cycle, and categorise: data error (fix at source), mapping error (fix the rule), or acceptable exclusion (document it). Rejects silently ignored in cycle 2 reappear as missing vehicles in month three.
Cutover mechanics
- Freeze source changes 24–48 hours before cutover, with a documented manual process for genuine emergencies.
- Run a final delta load for anything changed since the last full extract.
- Reconcile again after the delta — this is where errors hide.
- Keep the source system read-only for at least 90 days.
- Have a written rollback decision point with a named decision-maker and a deadline.
Common questions
Should we migrate maintenance history at all?
Migrate enough to support cost trending and warranty claims — typically two years — plus lifetime major events. Deep history has diminishing value and rising cost, and it is usually accessible from a read-only archive if genuinely needed.
Who should own data cleansing?
The business, not IT and not the vendor. Only the people who use the records can decide whether two similar entries are the same vehicle, or whether a missing acquisition cost should be estimated or left blank.
How long does migration take?
For a mid-sized fleet with moderate data quality, four to six weeks of elapsed time across profiling, cleansing and load cycles. Poor source data, multiple legacy systems or a depot merger can double it. It is nearly always the critical path.
Can we start clean instead of migrating?
Yes, and for badly degraded data it is often the right call. Migrate the asset register and open work orders only, keep the legacy system read-only for historical queries, and accept a reporting gap of a year. Say so explicitly rather than discovering it later.
What proves the migration succeeded?
A signed reconciliation showing record counts and financial totals matching between source and target, plus user-performed spot checks. Insist on it as a formal acceptance gate before go-live, not as a task to complete afterwards.
