Switching Traffic Control Software: A Migration Checklist

To switch traffic control software without losing shifts or records, list every record you rely on, clean it, set up the new system's rules, move future bookings first, pick a cutover date at the start of a pay period, and keep read-only access to your old records. Then bring crews across in stages, supervisors first.

Switching systems is one of the riskiest things an operations team does. A mistake does not just annoy the office: a missing booking means a client without a crew, and an expired ticket that slips through means a controller on site who should not be. This guide is a practical migration checklist for owners and operations managers, with a worked example of a six-week move. It is vendor-neutral and applies whether you are moving from spreadsheets and paper, or from one software product to another. If you are still choosing, start with what to look for in traffic control software, and if you are still on paper, read moving a traffic control company off paper.

Step 1: List every record you depend on

Before talking about import files, write down everything the business uses each week, where it lives now, and who owns it.

The last row matters. You do not have to move years of history into the new system, but you do have to keep it.

Step 2: Clean the data before you move it

Migrating dirty data just moves the mess somewhere new. Before export:

• merge duplicate clients and sites, which build up over years of quick bookings
• remove crew who have left, but archive their records
• verify every ticket and expiry date against the card itself, not last year's spreadsheet
• retire equipment that has been sold, written off or lost
• check renewal dates for rego, insurance and inspections
• confirm rates for each client, including penalty and minimum-hour rules

Our guide to tracking crew tickets and inductions explains what to capture for each worker, and tracking rego, insurance and inspections covers the equipment side.

Step 3: Set up the rules before you add people

Configure the new system before you import crew or start rostering:

• fatigue limits from your own risk assessment, such as maximum daily and weekly hours and minimum rest between shifts
• ticket types and which roles need which tickets
• shift types, break rules and docket fields
• client booking settings and notification preferences
• equipment categories and renewal reminder timing

These rules drive the checks the allocator relies on. If they are wrong on day one, the clash and fatigue warnings will be wrong too.

Test the rules with deliberately bad allocations before anyone relies on them. Create three dummy shifts: one that double-books a controller, one that leaves too little rest after a night shift under your limits, and one that puts a controller with an expired ticket on a job needing that ticket. Each should produce a clear warning. If one does not, fix the configuration now, not after a real controller has been sent to site. Do the same for equipment: set a dummy vehicle with rego due next week and check that the reminder appears where your yard manager will actually see it. If you print QR labels for signs, lights and trailers, label a handful first and check that crew and office can both scan them before doing the whole yard.

Step 4: Move future bookings and plan cutover

Future bookings are the most important data you move. Every one must exist in the new system before the old one stops being used for rostering.

1. Pick a cutover date at the start of a pay period, so one fortnight's timesheets are not split across two systems.
2. Avoid your busiest week, holiday periods and the end of the financial year.
3. Freeze new bookings in the old system a few days before cutover, or enter them in both.
4. Move all future bookings and check each one: date, times, crew numbers, equipment, documents.
5. Reconcile: the count of future shifts in both systems must match.

Tell clients what changes for them before cutover, not after. If they book through a link, send the new one with a short note. If their site contacts sign dockets on a controller's phone, warn them so the first sign-off is not a surprise at 3 pm on a busy site.

Example scenario: a six-week move for a 40-controller company

Here is how this plays out on a typical migration. A traffic control company with about 40 controllers, eight vehicles and a yard of signs, cones and portable lights is moving from a mix of an older rostering app, spreadsheets and paper dockets.

What goes wrong: in week 2, the compliance officer finds six controllers whose cards in the spreadsheet show different expiry dates from the cards themselves, and two inductions that had lapsed. If those had been imported as-is, the new system would have trusted wrong dates. The fix: every ticket was re-checked against a photo of the actual card before import.

A second problem: in the parallel week, one supervisor kept completing paper dockets only. The operations manager rode along for a shift, showed the docket on the phone, and fixed a sign-off step that was confusing.

What gets recorded: the record list, the cleaning log, the configuration settings, the count of future bookings in each system at cutover, and the location and access details for the archived old records.

Step 5: Keep your old records accessible

Do not cancel the old system until you have what you are required to keep. Employers must keep employee records, including time and wage records, for set periods. The Fair Work Ombudsman publishes the current record-keeping rules. Contracts, tax laws and WHS laws may require you to keep other records, such as SWMS sign-ons, inspection records and incident reports.

Practical options:

• negotiate read-only access with the old vendor for a period
• export everything to files, in formats you can open without the old system
• store exports securely, with access limited to people who need it

Records contain personal information such as licence copies, addresses and emergency contacts. Handle exports according to your privacy obligations; the Office of the Australian Information Commissioner explains the rules.

Step 6: Bring the crews across

Crew adoption makes or breaks a switch. Keep the first steps simple:

1. Supervisors first: they answer questions on site.
2. Then a small group of willing controllers.
3. Then everyone, with someone at the depot to help with logins and the first shift.

Explain what changes for the crew: how they will get shift offers, sign onto the SWMS, do pre-starts and complete dockets. On the first live morning, have someone in the office from early with a list of every crew member's first shift, ready to call anyone who has not accepted or logged in. Expect password resets, phones without enough storage and a few people who never opened the invitation. Keep a short paper fallback docket in each ute for the first week, so a phone problem never stops a shift from being recorded, and enter any paper dockets the same day. Our guide to getting traffic controllers to use the crew app has a rollout plan.

A cutover day checklist

• All future bookings moved and counted
• Fatigue limits, ticket rules and templates configured and tested
• Every active crew member can log in
• Every vehicle and equipment item has current renewal dates
• Old system set to read-only, with access details recorded
• Allocator has a backup plan for the first morning
• Clients told about any change to booking links or docket sign-off

Next steps

Start with the record list and assign an owner to each line before you set a date. If you are considering TrafWise, you can start a free trial and test the allocation board, crew app, ticket expiry tracking and equipment register with your own data before you commit.