Switching Travel & Expense Management Tools? Here's How to Not Lose Everything

Switching travel and expense management tools is one of those projects that looks straightforward on the demo call and gets messy by week two. The new vendor promises a one-click import. Your finance team has three years of receipts, half-closed reports, and a custom approval chain nobody documented. Somewhere in there, a sales rep is about to fly to Berlin and doesn't care which platform they book through, as long as they get reimbursed.

Here's the honest version of how to do this without losing data, audit trails, or your team's trust.

Why T&E Migrations Are Harder Than They Look

Most SaaS migrations move structured data between similar schemas. T&E migrations don't. You're moving receipts (images), expense reports (workflow state), policies (business rules), corporate cards (live integrations), virtual card mappings, GL codes, approval chains, and traveler profiles with frequent flyer numbers — across vendors who model all of this differently.

The short answer: start planning eight to twelve weeks before cutover, not two. The rest of this guide covers what to actually do in those weeks.

If you're still evaluating destinations, our travel and expense management category has the current landscape, and

is worth a look if you want booking and expense unified in one platform — which removes a whole class of migration pain you'd otherwise inherit.

Step 1: Audit What You Actually Have

Before you export anything, inventory it. You can't migrate what you can't see.

• Closed expense reports — last 7 years if you're US-based (IRS retention), longer in some EU jurisdictions
• Open and in-flight reports — these are the riskiest items; they're mid-workflow
• Receipt images — count them, sample a few, confirm they're not just thumbnails
• Policy rules — per diem tables, mileage rates, category limits, country-specific overrides
• Approval chains — who approves what, with delegation rules and out-of-office routing
• Corporate card feeds — issuer, account numbers, mapping rules to GL codes
• Traveler profiles — passports, TSA numbers, dietary preferences, loyalty programs
• Integrations — ERP, HRIS, SSO, accounting, BI dashboards

Make this a spreadsheet. You'll reference it every week.

Step 2: Decide What Moves, What Archives, What Dies

Not everything needs to migrate live. Here's a rough split that works for most companies:

Move live: Open reports, active traveler profiles, current policies, integrations, the last 12 months of closed reports for finance reference.

Archive read-only: Older closed reports, historical receipts. Most legal retention requirements can be satisfied with a PDF export sitting in cloud storage, not a live platform.

Let die: Stale approval chains, deactivated users, three-year-old card feed mappings, that one custom field nobody remembers adding.

This split alone can cut migration scope by 60%. Vendors won't suggest it because they want your full dataset on their platform.

Step 3: Export — and Verify Before You Trust

Most T&E platforms offer CSV exports of structured data and a separate bulk download for receipt images. A few key things to check:

1. Test the export on a sample first. Export one closed report end-to-end and confirm every receipt, line item, GL code, and approver shows up.
2. Check character encoding. International names and currency symbols often break on naive CSV exports. UTF-8 with BOM is your friend.
3. Pull via API where possible. CSV is fine for reports; API gives you better fidelity for receipts, comments, and audit history.
4. Keep raw exports forever. Even after migration is done, store the original export bundle in cold storage. If something's missing in the new system in month nine, you'll want the original.

If the source vendor charges extra for a full data export — and some do — pay it. Fighting that fee costs more than it saves.

Step 4: Map the Schema Honestly

The new vendor's import template never matches your old export exactly. Fields you'll commonly have to remap:

• Expense categories — old system had 47, new system encourages 18
• Project/cost-center codes — different hierarchy depths
• Tax fields — VAT handling varies wildly between vendors
• Custom fields — almost never migrate cleanly

Do this mapping in a spreadsheet, get sign-off from finance, then automate it. Don't let your implementation consultant do it alone — they don't know your business rules well enough.

Step 5: Plan the Cutover Window

You have three realistic options:

Hard cutover

New system goes live Monday, old system is read-only Friday. Cleanest, but requires every in-flight report to be closed first. Doable for small teams, painful for 500+ travelers.

Parallel run

Both systems live for two to four weeks. Travelers submit to the new one; finance reconciles against the old. Safer but expensive — you're paying two vendors and confusing users.

Phased rollout

One department, region, or business unit at a time. Best for large orgs. Worst for companies with cross-team approval chains, because someone in a migrated unit will inevitably need approval from someone who isn't migrated yet.

Most teams pick hard cutover and underestimate it. Add 50% buffer to whatever date the vendor proposes.

Step 6: Don't Forget the Card Feeds

This is where migrations quietly fail. Corporate card transactions flow in via direct feeds from issuers (Amex, Visa Commercial, Mastercard). When you switch platforms:

• The new vendor needs to be re-enrolled with each card issuer
• Enrollment can take 2-6 weeks per issuer
• Mid-cycle transactions can land in both platforms or neither
• Refunds and disputes from the old period need a clear home

Start card feed setup the day you sign the new contract. Not after kickoff. The day you sign.

Step 7: Bring the Team Along

The technical migration is half the project. The other half is change management. A few things that actually work:

• Pick 5-10 power users from across teams to test the new platform before general rollout. Their feedback finds the workflow gaps no consultant will.
• Record short Loom-style videos for the top 5 tasks (submit expense, attach receipt, approve report, check policy, request travel). Documentation nobody reads loses to a 90-second video every time.
• Hold one live Q&A in the first week post-launch. Not a webinar — an open call where people show their screens.
• Designate a Slack channel for migration questions and triage there for the first 30 days.

For more on team rollout patterns, our guide on running a smooth software rollout covers cross-tool tactics.

Common Pitfalls (And How to Dodge Them)

Pitfall: Assuming receipts migrate automatically. They often don't, or migrate as broken links. Verify a random sample of 50 receipts in the new system before declaring done.

Pitfall: Forgetting per diem and mileage rate effective dates. A 2024 trip approved at 2024 mileage rates needs the old rate, not the new one. Migrate rate history, not just current values.

Pitfall: Breaking SSO at cutover. Test SSO on a pilot group at least two weeks before go-live. IT calendar conflicts are the most common Monday-morning launch killer.

Pitfall: Not telling AP. Accounts Payable gets blindsided when GL exports change format. Loop them in week one, not week eight.

A Realistic Timeline

For a mid-sized company (100-1000 employees) switching T&E platforms, here's what works:

• Weeks 1-2: Audit, decide what to migrate, sign vendor
• Weeks 3-4: Schema mapping, card feed enrollment kickoff, sandbox setup
• Weeks 5-7: Test exports/imports, configure policies, build approval chains
• Week 8: Pilot group rollout, fix issues
• Weeks 9-10: Train remaining users, finalize integrations
• Week 11: Cutover weekend
• Weeks 12-14: Hypercare — both systems available, finance reconciles

If you've also been postponing a broader stack cleanup, our best travel and expense tools roundup is a sane place to compare what's out there.

Frequently Asked Questions

How long does a T&E migration typically take?

For a company with 100-500 employees, plan on 10-14 weeks from contract signature to full cutover. Larger enterprises with international operations, multiple card issuers, and complex approval chains routinely run 4-6 months. Anything under 8 weeks is either a very small org or an undercooked plan.

Can I migrate without losing my audit trail?

Yes, but only if you keep the source data accessible. Export full audit history (comments, approval timestamps, edit logs) before deprovisioning the old system, and store it in a queryable format. Most new platforms will import current state but not historical workflow events, so the old export becomes your compliance record.

What happens to in-flight expense reports during cutover?

The cleanest path is to freeze new report creation in the old system 2-3 weeks before cutover, push hard to close everything in flight, and migrate only the closed records. Any reports still open at cutover either get manually re-entered in the new system or stay in read-only access to the old one until closed.

Do I need to re-enroll my corporate cards?

In almost every case, yes. Direct feeds from issuers like Amex, Visa Commercial, and Mastercard are platform-specific. Re-enrollment can take anywhere from two to six weeks per issuer, which is why it should start the day you sign the new contract — not after kickoff.

How do I handle receipts and attachments?

Export them in bulk (most platforms offer ZIP exports or API access), verify file integrity on a sample, then upload to the new system. Watch out for file size limits and naming conventions that differ between platforms. Keep the original export bundle in cold storage permanently as a backup record.

Should I run both systems in parallel?

For most mid-sized companies, no — it's expensive and confusing for users. Parallel runs only make sense when you have strict audit requirements, complex multi-entity reconciliation, or are migrating during a fiscal year-end period when you can't afford gaps. Otherwise, a hard cutover with a 2-week hypercare window works better.

What's the biggest mistake teams make during T&E migration?

Underestimating change management. The technical migration usually works. What fails is adoption — travelers stop submitting expenses, approvers don't know the new workflow, finance can't close the month. Budget at least as much time for training and communication as you do for data migration.

Closing Thought

T&E migrations reward over-preparation. The teams that come out of these projects with their sanity intact are the ones who treated it as a change-management project that happens to involve some data, not a data project that happens to involve some people. Audit first, archive aggressively, start card feeds early, and pad your timeline. The platform you're migrating to is rarely the hard part — your own assumptions are.