Motus and Cardata Data Migration Checklist: What to Ask For Before You Switch
A clean reimbursement migration starts with a specific data request. Use this checklist to ask an incumbent vendor for the driver, rate, workflow, document, and history files needed for a controlled switch.
Published August 27, 2025. Updated May 23, 2026. By Kliks Editorial Team.
A Motus or Cardata migration should start with a vendor-ready data checklist that defines exactly what needs to be exported, how it should be transferred, and how both teams will validate it. The checklist should cover driver data, FAVR rates, reimbursement history, workflow rules, documents, audit records, integrations, file formats, encryption, owners, dates, and control totals.
Key takeaways
- Ask for the operating data behind the program, not just a driver roster.
- Define secure transfer method, file formats, field definitions, date ranges, and validation totals before exports begin.
- Load the data into a sandbox and reconcile it before production cutover.
Switching reimbursement platforms is easiest when the first request to the incumbent vendor is specific. A vague request such as "send us our data" creates delay because the vendor has to interpret what is needed, your internal team has to chase missing files, and the new provider has to guess how fields should map.
A better migration starts with a vendor-ready checklist. The checklist should be clear enough that Motus, Cardata, or another incumbent provider can hand it to the right operations or data team without a long discovery cycle.
Start with the data you actually operate
Many migration projects fail because they treat driver data as the whole program. The roster matters, but it is only one part of the operating model.
A reimbursement program also depends on rate assumptions, approval rules, eligibility groups, historical reimbursements, payroll exports, document status, audit trails, and integration mappings. If those details stay behind, the new system may technically import drivers but still fail to mirror how the program works.
The export request should cover the full reimbursement workflow:
- Active and inactive driver roster
- Driver eligibility status and reimbursement method
- Home location, work territory, manager, cost center, and approval hierarchy
- Vehicle records, insurance evidence, document status, and expiration dates
- Current FAVR fixed and variable rates
- Rate effective dates and historical rate changes
- Reimbursement history by driver and period
- Mileage, odometer, document, and audit records
- Approval rules, exception workflows, reminders, and escalation paths
- Payroll, HRIS, CRM, expense, and GL export mappings
That list gives the implementation team the context needed to rebuild the program, not just the names inside it.
Define the transfer method before the export
Data transfer should not be improvised over email. The checklist should define the secure transfer method, encryption expectations, file formats, file naming pattern, date ranges, owner contacts, and delivery schedule.
For many teams, a secure file transfer folder with encrypted CSV or spreadsheet exports is enough. Others may require SFTP, customer-controlled cloud storage, or direct IT involvement. What matters is that the method is agreed before the incumbent starts building files.
The checklist should also define control totals. For example:
- Number of active drivers
- Number of inactive drivers
- Number of driver vehicle records
- Number of current FAVR rate records
- Number of historical reimbursement rows
- Number of document records
- Number of approval or audit records
Control totals keep the migration grounded. If the incumbent says it exported 742 active drivers and the new provider imports 736, the team can find the issue immediately instead of discovering it during UAT.
Ask for field definitions, not just files
Files without field definitions create avoidable rework. A column named `status` may mean active, eligible, payroll-ready, onboarding-complete, or document-complete depending on how the incumbent system is configured.
Ask the incumbent vendor to provide a data dictionary or field notes for each export. At minimum, the request should define required fields, optional fields, accepted values, date formats, currency formats, and whether a field is system-generated or customer-configured.
This is especially important for FAVR rates and workflow rules. The new platform needs to know whether a rate is current, historical, pending, overridden, location-specific, vehicle-profile-specific, or tied to a particular effective period.
Separate current state from history
Current operating data and historical records serve different purposes.
Current state supports launch. It includes the drivers, rates, rules, documents, approvals, and integrations needed for day-one operation.
History supports audit, reporting, and reconciliation. It includes prior reimbursement periods, prior rate effective dates, mileage logs, approval records, document changes, and exports.
The checklist should separate these categories so the migration team can prioritize. In many projects, current-state data is loaded first for sandbox testing, while historical records are loaded or archived according to the customer's reporting and audit requirements.
Include workflow rules and exceptions
Workflow rules are easy to overlook because they may not sit in a clean export table. They often live as admin settings, custom rules, saved reports, or local operating knowledge.
Still, they need to be captured. Ask for documentation or exports covering:
- Who approves mileage or reimbursement exceptions
- When insurance reminders are triggered
- Which drivers require additional review
- What happens when documentation expires
- Which cost centers or managers receive reports
- How payroll files are reviewed and transmitted
- What manual overrides are common
These rules help the new sandbox behave like the current program. They also show where a cleaner process can replace manual steps.
Use the checklist as a project-control document
The checklist should not disappear after the first export. It should become a project-control document.
Each file should have an owner, due date, transfer status, validation status, mapping status, and UAT status. When a file changes, the team should record the version and reason. When a data issue is found, the checklist should show whether the fix requires a new export, a mapping change, or a customer decision.
This keeps finance, HR, payroll, operations, IT, and the new reimbursement provider aligned. It also gives the incumbent vendor a clearer path to completion.
What happens after the files arrive
Once the files are available, the new provider should load them into a sandbox instead of pushing straight to production.
The sandbox lets admins compare imported driver profiles, FAVR rates, workflow rules, reimbursement outputs, payroll exports, document records, and reports against the incumbent system. The team can reconcile differences, adjust mappings, and document open items before any driver-facing change is made.
The customer should not stop using the incumbent platform until the sandbox has passed review, UAT is complete, production readiness is confirmed, and stakeholders sign off on the cutover plan.
Questions to ask the new provider
Before choosing a replacement platform, ask:
- Do you provide a vendor-ready migration checklist we can send to Motus, Cardata, or our current provider?
- Which data sets do you require before sandbox setup?
- How do you validate imported driver, rate, reimbursement, and document records?
- Can we compare old-system and new-system outputs before production launch?
- How do you handle missing fields, unclear workflow rules, and historical records?
- Who owns migration issues during implementation?
- What does UAT sign-off require before cutover?
A provider that has done this before should have clear answers. The checklist is not just paperwork. It is the first proof that the migration will be controlled.
Download the migration checklist
Use the Kliks migration checklist PDF to request incumbent-vendor data exports, track control totals, plan sandbox validation, and manage UAT before cutover.
Editorial note
This article was prepared for finance, HR, and operations leaders evaluating vehicle reimbursement programs. It is educational content, not tax or legal advice; confirm policy changes with qualified advisors.