Moving off spreadsheets without breaking the week

Most carriers under fifty trucks run on some combination of a dispatch spreadsheet, a settlements workbook, a maintenance notebook and a lot of text messages. It works, right up until the person who built the spreadsheet takes a vacation.

Moving to a TMS fails more often from bad sequencing than from bad software. Here is a plan that survives contact with a real week.

Decide what you are actually migrating

You are not migrating everything. You are migrating the things that are true right now, plus enough history to be useful.

Migrate: - Active drivers with contact info, CDL and medical expiry dates - Trucks and trailers with unit numbers, VIN, plate, registration and inspection dates - Current assignments — who is in which truck - Customers and brokers with MC numbers and billing contacts - Open loads and anything not yet invoiced - Outstanding driver balances (advances, escrow, installment deductions in progress)

Do not migrate: - Years of closed loads. Keep the spreadsheet as an archive. Nobody queries 2023 loads in the new system, and importing them makes every list slower and dirtier. - Historical settlements. Same reasoning — archive the PDFs. - Dead records. Every fleet has trucks sold in 2022 still sitting in a tab.

The instinct to bring everything is strong and it is wrong. It doubles the work and imports all your accumulated data quality problems into a clean system.

Clean the data before, not after

Spend an afternoon on this and save a month:

Import quality is entirely determined by this step.

The order that works

Week 1 — assets and people. Import trucks, trailers, drivers, assignments, customers. Nothing operational yet. Let the office click around and find what looks wrong. Fix it now while nothing depends on it.

Week 2 — dispatch runs parallel. New loads go into the TMS *and* the spreadsheet. Yes, double entry, and yes, it is annoying for a week. This is the week you find out that your loads have a field the software calls something else, or that your rate structure has a case nobody mentioned. Finding that with a safety net is much better than finding it on payroll Friday.

Week 3 — dispatch cuts over, accounting runs parallel. Loads only in the TMS. Settlements calculated both ways and compared, driver by driver. Expect differences. Track down every one — they are almost always a rule that lived in someone's head.

Week 4 — accounting cuts over. Run payroll from the TMS. Keep the spreadsheet as a check for one more cycle, then stop.

Month 2 — maintenance and compliance. These are the ones everyone postpones. Put real dates in, or the expiry alerts you bought the software for never fire.

The mistakes that kill migrations

Cutting over on payroll week. Never. Pick a quiet week.

Training only the dispatcher. If safety, maintenance and accounting do not get their own logins and a walkthrough, the system stays a dispatch tool and the rest of the company keeps using the old files. Then the data is half-true, which is worse than either extreme.

Skipping the parallel period. The parallel weeks feel like wasted effort right up until they catch the thing that would have cost you a payroll cycle.

Importing history. Covered above, and people do it anyway.

No owner. Somebody has to be responsible for the migration finishing. Without a name on it, it ends up 70% done, which is the worst possible state — half the company on the new system, half on the old.

What "done" looks like

You are finished when:

That last one is the real test. A system only one person can navigate is a spreadsheet with a login screen.