Migrating Off Spreadsheets: A Traffic Control Operations Playbook

Most traffic control companies do not run on one spreadsheet. They run on a constellation of them: a job board, an equipment list, a credential tracker, a quote log, and a rate sheet, each maintained by a different person and each slightly disagreeing with the others.

That system works, in the sense that the company functions. It also has a specific failure mode — the information exists but cannot be assembled quickly enough to answer a question — and that failure mode gets more expensive as you grow.

What spreadsheets actually cost

Not license fees. Three other things.

Reconciliation time. Somebody spends hours a week making the job board agree with the equipment list and the invoices agree with the tickets. That work produces nothing; it only repairs drift.

Single points of knowledge. One person understands how the equipment workbook is structured. When they are unavailable, the company's ability to answer "what is on that site right now" degrades sharply.

Unanswerable questions. Which jobs were actually profitable. Which equipment goes missing and where. Whether the crew assigned tomorrow holds current credentials. These are answerable in principle and not in practice, because assembling the answer takes longer than the answer is worth.

That last category is where the real exposure sits. A GPS-stamped field record is not only a billing artifact — it is the evidence of what was set up and by whom. The underlying risk is well documented: the Work Zone Safety Information Clearinghouse records 850 work zone fatalities in 763 fatal crashes in 2024, and conformance obligations run through OSHA's construction standards, which incorporate the traffic control manual by reference at 29 CFR Part 1926 Subpart G. When a claim or a payment dispute surfaces months later, a spreadsheet that was overwritten in place has no history to consult.

Sequence the migration

Do not migrate everything at once. Order matters, and the order below is roughly by effort-to-value.

Phase one: customers and active jobs. The smallest, cleanest datasets, and they unblock everything downstream. Expect duplicates, inconsistent naming, and dead contacts. Dedupe before import, not after — cleaning inside a new system is slower than cleaning in the spreadsheet you already know.

Phase two: field tickets and time. This is the highest-value change and the one that requires the most behavior change. Cut over one crew first, not the whole company. Let a foreman who is willing to try it prove the flow works, then expand. A crew that hears "the app works, Danny's been using it for three weeks" adopts faster than one that receives a mandate.

Phase three: equipment and inventory. The most valuable and the most laborious, which is why it earns its own phase. This is where you discover that the equipment workbook has not matched reality for some time. Budget for a physical count.

Phase four: quotes, invoices, and accounting sync. Once jobs and tickets are flowing, billing has something real to pull from. Doing this first — a common instinct, because billing feels most urgent — means invoicing from estimates rather than from actuals, which is the problem you were trying to solve.

Phase five: credentials, permits, and documents. Attach them to people and jobs so they surface at dispatch. This is the phase most often skipped, and it is the one that prevents staffing a job with an expired credential.

The cleanup nobody budgets for

The bottleneck is never the software. It is that your data is messier than you think.

Expect: the same customer under three spellings. Equipment that exists in the workbook and not in the yard, and vice versa. Rate sheets with no effective dates, so nobody knows which version applied to a job last spring. Credential records with no expiration dates. Jobs marked open that closed two years ago.

None of this is unusual. All of it has to be resolved before or during import, and it is the reason implementations take longer than planned.

One decision that saves substantial time: migrate less history than you want to. Closed jobs from prior years rarely justify the cleanup. Archive the old spreadsheets read-only, keep them accessible, and migrate open work plus the records you actively use. You can always consult the archive; you cannot get back the weeks spent scrubbing 2023 job records nobody will open.

Avoiding the parallel-systems trap

The most common way migrations fail is not a technical problem. It is running old and new side by side indefinitely.

It happens for understandable reasons. The office does not fully trust the new system, so they ask foremen to keep filling out paper tickets too. Now field staff are doing the work twice, and the app is strictly worse than paper from their perspective. Within a week or two they stop using it, and the migration is dead while everyone still believes it is underway.

The fix is to commit to a cutover date per area and accept a short period of imperfection. Pick the date, communicate it, and let the first weeks be rough. Double entry is not a safety net — it is the mechanism by which the new system fails.

Two supports make the cutover survivable: someone owns the transition and is available to answer questions the same day, and there is a fast path for reporting problems that produces visible fixes. Crews tolerate a rough week if they can see their complaints landing.

What to expect after

Realistic calibration.

The first benefit is usually billing speed, not labor savings. Tickets that used to arrive days after the work arrive the same evening, and invoices go out sooner. That cash-cycle improvement typically pays for the software before any efficiency gain shows up.

Reporting takes a season to become useful, because job costing needs a full cycle of real data before comparisons mean anything.

And some spreadsheets will survive. That is fine. The goal is not zero spreadsheets — it is that the operational core, the records you would need to reconstruct a job, lives in one place with history.

If you are still deciding what to buy, the dispatch software buyer's guide covers requirements and vendor questions. If you want to see the ticket and equipment flow on real screens, book a walkthrough.