Migration is a data project before it's a software project
The quality of a TMS implementation is set well before go-live, by the quality of the data being brought across. Operators who treat migration purely as a software switch — expecting the new system to simply absorb whatever exists in the old one — tend to carry years of accumulated inconsistency straight into the new platform.
Start with your customer and site records
Customer records built up over years often contain duplicates, outdated contacts, and sites that no longer receive freight. Before migration, reconcile this list against who you've actually invoiced in the last twelve months. It's far easier to clean this list once, in the system you know, than to migrate it and clean it twice.
Audit your rate cards for what's actually current
Rate cards accumulate exceptions over time — a special rate for one job years ago that never got removed, a surcharge that no longer applies. Migration is the natural point to confirm which rates are still live, which customer still has which agreement, and which can be retired rather than carried forward unquestioned.
Decide how much job history actually needs to migrate
Not every historical job needs to exist in the new system on day one. Distinguish between data you need for active reporting and reconciliation versus data you need only for occasional lookup — the latter can often stay accessible in the old system or an export rather than needing a full live migration.
Standardise product and freight-type codes before you move them
If general freight, container, and specialised freight jobs have been coded inconsistently across depots or over time, migration will carry that inconsistency forward and make it permanent in the new system's reporting. A short standardisation pass beforehand — even just a mapping spreadsheet — pays off every time a report is run afterwards.
Run a parallel period before switching over fully
Wherever practical, run a short period where jobs are entered in both the old and new system, or at minimum where a sample of completed jobs is checked against both. This surfaces data mapping issues — a rate that migrated incorrectly, a customer record missing a billing contact — while there's still an old system to compare against.
Plan the cutover date around your billing cycle, not your calendar
Switching systems midway through an open billing period creates unnecessary reconciliation work. Wherever possible, align go-live with the start of a new billing cycle, so completed and invoiced jobs stay cleanly on one side of the migration or the other.