If you're moving from a spreadsheet to mileage software in July, the question isn't whether you can. The question is what you actually do for the six weeks of the migration.
I get the appeal of waiting until January. A clean year-start, no historical data to import, fresh band-split counters, payroll happy. But the reasons firms actually need to switch in July are usually urgent ones - a Revenue letter, a finance lead leaving, a client raising eyebrows about invoice accuracy. Waiting six months isn't always an option, and the hidden cost of staying on the spreadsheet tends to compound faster than the migration cost itself.
Here's what a mid-year migration actually looks like, week by week, based on the patterns I've seen.
Why mid-year is harder than starting fresh in January
Two reasons. First, the year-to-date mileage matters. The civil service rate bands reset on 1 January, which means by July every engineer has a YTD total that determines which band they're in for the rest of the year. That total has to come into the new system correctly, or the rest of the year's calculations will be wrong from day one.
Second, the project allocation history matters. Half-finished projects that have been billing mileage all year need their accumulated mileage to migrate cleanly so the project margins don't reset to zero. The new system has to know what was already coded where.
Neither of these is impossible. They just need to be planned for. A mid-year migration that doesn't account for them leaves you in August arguing about which engineer's year-to-date should be 8,200 km versus 8,460 km, and the audit trail won't help you.
Week 1: Data audit
The first week is reading the spreadsheet you currently have. Specifically, two questions.
One: is the YTD column trustworthy? Walk through three engineers' tabs end-to-end. Add up every trip manually. Does the total match the running YTD? If yes, the YTD column is reliable and you can use it as the migration starting point. If no, the YTD column is wrong somewhere, and you need to find where before importing it.
Two: are the project codes consistent? Pull every distinct project code that appears in mileage entries across the year so far. Compare it to the list of currently-active projects. Any code that doesn't tie to a current project is going to need a manual decision: was it a typo, an old project that's now closed, a placeholder that was never updated. Each one needs answering before migration, not during. (This is also the moment to find the project-coded mileage that has been quietly leaking margin.)
The data audit usually finds three things: at least one engineer whose YTD is materially wrong, at least one set of project codes that don't match the current project list, and at least one engineer whose engine-CC categorisation isn't in the spreadsheet at all (which means their band-split rate hasn't been applied correctly).
Document each finding. The migration plan is built on these.
Week 2: YTD import preparation
The second week is preparing the YTD opening balances for each engineer. For each person:
- The kilometres they've driven for work since 1 January
- The amount they've already been paid
- Their vehicle engine size and fuel type
- Which band their next trip will start in
This isn't import-ready data yet. It's the worksheet you build to feed the import. The format the new system needs is usually a simple CSV: employee identifier, YTD kilometres, vehicle CC, current band.
The trap to avoid: don't import the historic trip log itself. You're importing the year-to-date balance, not the trip-by-trip history. The trip log can stay in the spreadsheet as an archive. Importing it adds a week to the migration and creates duplicate-record problems if anything goes wrong.
What you do want to import is the trip log for the current month - the one that hasn't yet been paid. That's the bridge between "spreadsheet world" and "new system world." Trips before the cutoff stay archived. Trips after the cutoff live in the new system.
Week 3: Project-code mapping
The third week is the project allocation side. The new system needs to know which projects are active, who's assigned to each one, and what the billing convention is per project.
This is where a fair bit of housekeeping happens. Most spreadsheet processes accumulate project codes over years, and not all of them are valid anymore. Migration is the natural moment to rationalise.
The output is a clean project list with: project code, project name, client, status (active or closed), billing convention (recovered 1:1, recovered with markup, internal overhead). Each engineer is then assigned to the projects they're currently working on.
The discipline here is "current state, clean," not "history rebuilt." Don't try to retrofit historic project codes that have been retired. Just get the live picture right.
Week 4: Payroll format alignment
The fourth week is making sure the new system's payroll export matches what your payroll provider expects. This is usually quicker than people think, but it has to be done before cutover - not after.
Pull a sample of last month's payroll export from the spreadsheet. Note the column order, the date format, the rounding convention, the header row format. Compare it to what the new system can produce. Adjust the new system's export configuration to match.
Test with a single engineer's data. Send the test export to your payroll provider. Confirm it imports cleanly.
If the payroll provider needs format changes, this is the week to negotiate them. After cutover, format mismatches turn into payroll delays.
Weeks 5-6: Parallel run
The fifth and sixth weeks are running both systems side by side for one full month-end cycle. Engineers log trips in both the spreadsheet and the new system. Niamh produces month-end reports from both. The numbers get compared.
The parallel run does three things. It catches integration issues before they affect a real payroll. It familiarises the engineers with the new logging interface, ideally before they have to rely on it. And it gives you a side-by-side comparison of "spreadsheet result vs new system result" for the same trips, which is the strongest possible evidence that the migration is reliable.
The parallel run is also where you'll find the unexpected discrepancies. Almost always, the new system's calculation is right and the spreadsheet was wrong - usually because of a band-split or YTD error that nobody had spotted. The differences are uncomfortable. They're also the reason you're moving.
Week 7: Cutover
The seventh week is the actual switchover. The spreadsheet goes read-only. Engineers stop logging there. Month-end gets produced from the new system only. The payroll export goes through the new system's pipeline.
The cutover itself is a quiet event if the parallel run worked. The engineers have already been using the new system for two weeks. The format is already aligned with payroll. The YTDs are already reconciled. There's no big-bang weekend - just a Friday where the spreadsheet stops being the source of truth.
The first month-end after cutover usually feels suspiciously easy. That's normal.
What doesn't migrate, and what gets lost
Honest list of things that usually don't survive migration cleanly:
Historic receipt scans. The receipts attached to past mileage claims usually don't migrate. They stay in the spreadsheet's email-attachment archive or a shared drive. The new system holds receipts going forward. If you need to retrieve a historic receipt, it's a manual lookup.
Driver licence-check records. If your firm hasn't been documenting these (and most haven't), there's nothing to migrate. The new system's grey fleet records start fresh. The first round of licence verification gets done in the first month after cutover.
Comments and notes. The little annotations engineers leave in spreadsheet cells - "agreed with client", "out-of-pocket cash for parking" - usually don't migrate. They die with the spreadsheet. If specific notes matter, copy them out manually before cutover.
Custom project margin views. If your existing spreadsheet has bespoke pivots or charts that finance uses for management reporting, those won't survive. The new system has its own reporting. Some of it will be better. Some of it will be different in ways that take a month to get used to.
Month two and month six
The pattern after cutover is reasonably consistent across firms.
By month two, the engineers have stopped asking how to log trips. The finance lead is producing month-end in 30-40 minutes instead of a Thursday night. The first end-to-end audit-style query - "show me the trip log behind a specific payment from last month" - resolves in under five minutes.
By month six, the year-end picture is clean. The YTDs reconcile. The project margins are visible by leg, not just by total. The grey fleet duty-of-care records have a quarter of real data behind them. The next mid-year migration question never comes up because nobody's running a 47-tab spreadsheet anymore.
The bottom line
A mid-year mileage migration isn't a six-week disaster. It's a six-week project with predictable phases, a clear data audit upfront, and a parallel run period that catches the unexpected. The firms that struggle are the ones that try to compress the timeline or skip the data audit. The firms that do well are the ones who treat the spreadsheet's quirks as a project finding, not an inconvenience.
If you're considering a mid-year switch and you'd like a walk-through of what your migration would specifically look like - including the YTD audit and the parallel-run plan - book a 20-minute demo. Have your spreadsheet open if you can. The conversation goes a lot faster.
Last updated: 28 April 2026.
