Fleet Software Data Migration Checklist

Scope a fleet-software data migration by identifying the records that must move, who can authorize their use, how source identifiers map to destination records and what evidence will establish acceptance. Count distinct, verified assets separately from spreadsheet rows, historical events and software users. A carrier's reported power-unit count cannot set a migration price or a license quantity.

This use case answers what should a fleet-software seller and customer agree before putting data migration into a proposal? The deliverable is a bounded migration schedule: included records and history, field mappings, unresolved exceptions, reconciliation totals and a named acceptance owner. It assumes the customer has a relevant project; it does not establish buying intent from public data.

Start with the customer's data boundary

The trucking-software account shortlist helps decide which businesses merit research. The telematics discovery brief identifies an operational problem. Migration scoping comes next, when a proposed change depends on transferring specific data.

Write down the legal entities, operating sites, asset classes and time period included in the transfer. Identify the source systems and the destination's currently documented import route. Separate a vehicle master record from a maintenance event, a device record, a site assignment and a user account. Each is a different thing to reconcile.

FMCSA's MCS-150 instructions, item 26(a) request vehicle counts by type and acquisition method, including owned and leased categories. They do not provide a vehicle-by-vehicle migration inventory. A public carrier export may identify the operating business; obtain the actual asset register and relevant history from an authorized customer source.

Keep these statements separate:

Observed public fact: a dated carrier record reports a fleet count.
Fit hypothesis: the business may use a workflow your product supports.
Confirmed project need: the customer identifies the records needed for an agreed workflow.
Migration commitment: the parties accept a specific transfer scope and its completion tests.

Only the last two support the proposed work. None of them automatically defines billable seats; confirm the applicable commercial terms separately.

1. Assign a source owner and an acceptance owner

An employee's ability to export a file is not, by itself, evidence that the employee can authorize its disclosure or approve the transfer. Record who owns the business data, who permits access and who can resolve its meaning. The destination administrator may be a different person from the fleet manager who accepts the result.

For each source, agree:

The exact export or report, extraction time and included population.
Who can supply it through an approved route.
Which fields are necessary for this phase and which should be omitted.
Who resolves conflicting identifiers, dates, units or ownership information.
Where the original and working copies will remain available, with access and retention responsibilities.

Use fictitious or appropriately de-identified examples for an early mapping discussion when real personal or commercial details are unnecessary. A maintenance-record mapping usually does not need driver identity documents, payment credentials or customer contract contents. If a later step genuinely needs additional data, name its purpose and authorization before including it.

Keep any required record-retention review separate from a convenient project cleanup date. For example, 49 CFR 396.3 includes vehicle identification and inspection, repair and maintenance records within its applicable scope, with retention provisions. Successful import is not permission to erase the source. Have the responsible records owner determine what must remain accessible and in what form before retiring an old system.

2. Map identities before mapping descriptive fields

A familiar unit number can be reused at another site or in another source system. A display name is not sufficient proof that two rows refer to the same physical asset. Begin with a crosswalk that retains the source system, source identifier, verified asset identity and destination identifier once assigned.

For a fictional asset, the crosswalk might say: “Maintenance System A / unit 0042 and Yard System B / unit 42 both refer to verified asset ASSET-017.” That conclusion requires customer evidence; stripping leading zeroes is not the evidence. Keep the original values even when the working format changes.

Also record relationships: the legal entity responsible for the asset, its relevant site assignment and the event records attached to it. Decide whether a site field means current location, home terminal or location when an event occurred. A vehicle can change sites without becoming a new vehicle.

Current vendor documentation shows why these distinctions matter. Fleetio's Vehicle Import Guide distinguishes new vehicle creation from updates using fleetio_id, and requires unique vehicle names. Samsara's gateway CSV guidance describes external identifiers as a system key paired with an object value and warns about leading-zero loss in exported numeric fields. These are examples of different import semantics, not universal instructions or a claim that USDOTData connects to either product.

When two records disagree, do not let “last row wins” silently decide the customer master. Assign an explicit rule: a named source is authoritative for a particular field, an owner resolves the conflict, or the record stays on hold. A later export timestamp does not necessarily make every field more accurate.

3. Define what happens to every field and its history

Use the carrier-data field dictionary for the general discipline of keeping definitions, units and dates attached to values. For this migration, apply that discipline to the customer's actual source and destination specifications.

At minimum, the mapping should distinguish:

Identity fields: original keys and their destination matches; keep identifiers as text where appropriate.
Measured values: the number, unit and observation date. “54,000” without miles, kilometers or hours is unresolved.
Status fields: the original category, destination category and approved translation. Do not silently turn every unknown status into active.
Dates and times: whether each value is a calendar date, local timestamp or timestamp with a time zone. Record any conversion.
Missing values: whether blank means unknown, intentionally omitted, unchanged or cleared under this import route.
Related history: event identifiers, asset links, event dates and any attachments required to interpret the record.

Classify every field as transferred unchanged, transformed by an agreed rule, retained in a separate accessible archive or excluded with a reason. If the destination cannot hold a required historical detail, that is a scope decision to resolve before the proposal promises its preservation.

A new asset list with only today's meter readings is not a migration of maintenance history. Equally, moving every historical attachment may be unnecessary for the confirmed task. State the chosen boundary explicitly and obtain the relevant owner's acceptance.

Worked example: 120 rows do not mean 120 assets

All businesses, identifiers and numbers in this example are fictional. No customer dataset or real vendor behavior is represented. A fleet supplies two site exports and an overlapping repeat extract. The proposed phase covers its current asset master and a specified set of maintenance events.

The customer owner resolves the identifiers and confirms this input structure:

50 distinct assets appear once: 50 rows.
25 distinct assets appear in both site exports: 50 rows.
10 other distinct assets appear once plus a repeated export copy: 20 rows.

That is 120 source rows representing 85 distinct assets: 50 + 25 + 10. The extra 35 rows are additional representations of already identified assets, not additional equipment. Preserve them in the source evidence while selecting or combining values under the approved rules.

The owner then confirms five of the 85 assets are retired and excluded from this phase. Their history remains in the agreed archive. That leaves 80 in-scope assets. Six of those have unresolved meter units; their identities are known, but their destination values are not acceptable yet. The proposal can therefore describe 74 ready assets and six held assets, with the held records explicitly assigned for resolution.

The complete reconciliation is:

120 source rows
- 35 additional representations of identified assets
= 85 distinct verified assets
- 5 retired assets excluded from this phase
= 80 in-scope assets
- 6 assets held for unresolved meter units
= 74 assets ready for the agreed import

Do not promise an 80-asset completed transfer while silently leaving six behind. Either resolve them before acceptance or have the customer approve a smaller 74-asset phase with the six recorded as deferred work. Do not replace an unknown unit with the destination default to make the count look complete.

Now suppose the approved 74-asset phase also contains exactly two selected maintenance events per asset: 148 events. A trial produces 74 asset records and 148 event records, but two events point to the wrong assets. The counts reconcile; the relationships fail. Acceptance should wait for correction and a repeated relationship check. Record the resulting evidence rather than declaring success from the import message alone.

This example establishes three separate quantities: source rows, distinct assets and related events. Its figures do not estimate another fleet's data quality, implementation effort or software licenses.

4. Turn acceptance into observable checks

Agree the evidence before the production transfer. A small authorized sample can test mappings and expose exceptions; it cannot establish that every unseen record will work. Select cases that exercise the actual risks: repeated source keys, different sites, missing units, inactive assets and linked history. Record what the sample covers and what it leaves untested.

Use a short acceptance checklist for each agreed phase:

Scope: the source revision, extraction cutoff and included population match the approved schedule.
Disposition: every source record has an explained result: mapped, held, excluded or retained elsewhere. Counts use the correct record type.
Identity: every accepted asset has the intended destination match, with no unexplained duplicates or merges.
Meaning: required values retain their units, dates, statuses and approved transformations; critical unresolved conflicts remain outside the accepted set.
Relationships: events and attachments resolve to the correct assets and remain understandable to the responsible user.
Use and access: the acceptance owner can retrieve agreed records and inspect representative history with the intended permissions.
Recovery: the team knows how to stop, correct or restore this transfer if its checks fail, using capabilities actually supported by the systems.

Do not assume that rerunning a file is harmless. Confirm whether the chosen operation creates new records, updates existing records or rejects existing identifiers, and preserve the mapping needed for a controlled retry. Do not promise a one-click rollback unless it exists and has been verified for this scope.

Specify how source changes after the extraction cutoff will be handled. A later addition or corrected meter value needs a documented follow-up transfer or an agreed exclusion; it should not disappear between an initial sample and final acceptance. This is a data-boundary decision, separate from the broader staffing and training plan.

Copyable migration scope and acceptance worksheet

Use one scope block per transfer phase, then repeat the mapping block for each record type or material field. Keep sensitive source files outside a general sales brief.

TRANSFER PHASE
Customer entity / sites / asset classes:
Confirmed purpose and included history period:
Source system / export / extraction cutoff:
Source owner / access authorization:
Destination product / supported import route:
Distinct assets / events / attachments in scope:
Held records and owner / explicit exclusions:

IDENTITY AND FIELD MAP
Record type and source key:
Verified asset key / destination key:
Source field -> destination field:
Meaning / units / date or time-zone rule:
Blank-value behavior / transformation rule:
Conflict rule and resolution owner:
History link / archive location if not transferred:

ACCEPTANCE
Expected created / updated / held / excluded counts:
Identity and relationship checks:
Required-field and unit checks:
Sample cases / limits / full-transfer checks:
Post-cutoff changes and retry method:
Recovery method / records-retention owner:
Acceptance evidence / approver / decision date:
Open items that prevent a fixed scope:

For the fictional case, write “74 ready assets; six held; five excluded from phase; 148 selected events associated with the 74” instead of “import fleet spreadsheet.” A proposal should also identify who resolves exceptions and when a changed source or added history changes the scope. If those decisions remain unknown, describe a bounded assessment first rather than inventing a fixed migration effort.

Frequently asked questions

Is a carrier export an asset register?

No. A carrier-level file can support company identification and reported operating context. It does not establish each vehicle's identity, site, meter unit or historical records. Obtain the actual project inventory from an authorized source and reconcile it independently.

Who can supply migration data?

The customer should identify a person authorized to provide the particular records and an owner who can explain them. Export access alone does not answer disclosure permission, contractual restrictions or acceptance authority. Record those responsibilities before obtaining the working files.

What if unit numbers or other identifiers conflict?

Keep both original records and resolve the match using evidence the customer can verify. Distinguish source-local identifiers from a verified asset identity. Hold unresolved matches rather than merging records by name or removing zeroes until they look alike.

How should historical records be preserved?

Specify the history period, event types, asset relationships and required attachments. Decide what transfers and what remains in an accessible archive, with an accountable records owner. Check applicable retention requirements before retiring a source; a successful asset import does not prove history was preserved.

Does a successful sample prove the full migration will succeed?

No. It shows how the tested cases behaved under that mapping and import route. The complete transfer still needs population reconciliation, exception review, relationship checks and the agreed acceptance evidence. New source revisions can introduce cases the sample never covered.

When is sensitive data unnecessary?

When a fictitious record, field specification or appropriately de-identified sample answers the scoping question. Ask for the minimum evidence needed at each stage. If a production step needs additional sensitive fields, document their purpose, authorized access and handling before expanding the transfer.

Make the proposal traceable to the accepted scope

Start with one source export, one destination route and a small set of representative cases. Resolve what one row means, prove the identity crosswalk and agree how counts and history will be checked. The useful next step is a reviewable transfer schedule, not a price multiplied by a public fleet count.

By John Hauler, USDOTData's editorial persona. Sources reviewed October 8, 2026. USDOTData is an independent information service, not FMCSA. The workflow and fictional example are editorial recommendations; cited vendor rules apply only to their documented operations.

Fleet Software Data Migration: Define Scope and Acceptance