A practitioner's guide to broker TMS migration
Freight broker TMS migration, without breaking the floor.
Most freight broker TMS migrations fail the same way: too much cutover on one day, too much dirty data carried across, too little training for the brokers who actually have to use the new system on Monday morning. This is the practitioner's guide we'd hand a brokerage migrating off McLeod, Aljex, BrokerWare, or MercuryGate — with the honest framing on when the right answer is "don't migrate, run an overlay".
2–4 wk
SMB migration timeline
5–25 broker shop, AscendTMS / Aljex baseline
6–10 wk
Mid-market migration timeline
25–200 brokers, phased per-desk
12–20 wk
Enterprise migration / overlay timeline
200+ brokers, EDI, multi-brand
The five data buckets that have to migrate
Carriers
Carrier records, MC/DOT, insurance, factor
Non-negotiable bucket #1. Carrier name, MC and DOT numbers, payment terms, insurance certificates and expirations, factor company assignment, contact records for dispatch. Clean duplicates in the source TMS before migration — debugging them in the new system is a tax nobody enjoys.
Shippers
Customer records, credit terms, accessorial agreements
Customer name, billing address, credit terms, contract rates, accessorial agreements, primary contacts. EDI trading partner IDs if applicable. Shipper-specific rate-confirmation language and document templates.
Active loads
Anything in flight or not-yet-invoiced
Non-negotiable bucket #2. Loads currently with a carrier, loads delivered but not invoiced, loads invoiced but not paid. These have to migrate cleanly or the brokerage spends a quarter reconciling AR/AP.
History + templates
Trailing 12-24 months, plus document templates
Historical loads for AR/AP reconciliation, tax filing, and lane-performance reporting. Rate-confirmation templates, BOL templates, invoice templates, report templates. Often the under-scoped part of a migration plan.
The phased cutover model that actually works
- Weeks 1-2 — Discovery and data audit. Pull a snapshot of all five data buckets out of the current TMS. Run duplicate detection on carrier and shipper records. Clean the obvious garbage in the source system, not in the destination.
- Weeks 2-3 — Sandbox build. Stand up a sandbox Keelway tenant. Import the cleaned carrier and shipper data. Configure rate-confirmation templates, accounting integration (QuickBooks Online), and load-board posting templates.
- Weeks 3-4 — Shadow mode (mid-market+). First desk goes live in shadow mode — Keelway reads and ranks the inbox, but the old TMS continues as system of record. Desk lead reviews ranked picks against their manual picks daily.
- Weeks 4-6 — First desk cutover. Lowest-risk desk (often dedicated lanes or a single shipper's account) cuts over to Keelway as system of record. Daily syncs for the first two weeks; weekly check-ins after.
- Weeks 6-10 — Phased rollout. Each remaining desk takes 4-7 business days from shadow to cutover. Critical EDI pairs run in parallel across both TMSs until the new pair has been clean for 14 days.
- Weeks 10-12 — Decommissioning. Old TMS goes read-only for AR/AP reference and tax. Account closes when invoice trailing settles.
When the answer is "don't migrate, run an overlay"
The mid-market case for overlay is documented in detail on the mid-market McLeod overlay case study. Short version: if your TMS investment is sticky (multi-year customization, working EDI, a built-out reporting suite), the overlay pattern delivers most of the AI productivity gain without the migration risk. Keep McLeod / Aljex / Tai as system of record, run Keelway as the AI layer on top, and revisit migration when the TMS contract is up for renewal.
Frequently asked questions
How long does a freight broker TMS migration actually take?+
For a 5-25 broker SMB shop on AscendTMS or Aljex, 2-4 weeks elapsed time from contract signature to full cutover is realistic. For a 25-200 broker mid-market 3PL on McLeod or Aljex with deep customization, 6-10 weeks elapsed is realistic, with phased rollout across desks. For a 200+ broker enterprise with EDI pipelines and multiple brands on different TMSs, 12-20 weeks is realistic with the overlay pattern usually preferable to outright replacement. Anyone quoting 'one week' for a real broker TMS migration is either underscoping the carrier-data work or overpromising.
What data has to migrate?+
Five buckets in priority order. (1) Carrier records — name, MC, DOT, payment terms, insurance docs, factor company assignment. (2) Customer/shipper records — same fields plus credit terms, billing addresses, accessorial agreements. (3) Active loads in flight — anything not yet invoiced. (4) Historical loads — typically the trailing 12-24 months for AR/AP reconciliation and tax. (5) Rate-confirmation templates, document templates, and report templates. The first three are non-negotiable; the historical loads are negotiable based on your accounting cutover plan.
What kills a broker TMS migration?+
Three things, in roughly this order. (1) Trying to cut over the entire floor on a single day instead of phased per-desk. (2) Migrating dirty data — duplicate carrier records, outdated insurance docs, stale shipper credit info — and then debugging it inside the new TMS. Clean it in the old TMS first. (3) Underestimating the broker retraining cost. A senior broker can move 20-30 loads/day on muscle memory; the first week in a new TMS that drops to 8-12. Plan for the productivity dip.
What about EDI and shipper integrations?+
If your brokerage has working EDI pipelines to top shippers (204 tenders, 214 statuses, 210 invoices), those integrations took quarters to build and you should treat them as load-bearing. Keelway supports EDI ingestion and outbound, but the cutover for established EDI pairs needs a careful test plan with the shipper's IT team. Most enterprise customers run EDI in parallel between the old and new TMS for 2-4 weeks before cutting over.
Should we even migrate, or run Keelway as an overlay?+
Honest take: if you have a sticky enterprise TMS investment (McLeod LoadMaster with two years of customization, Aljex with working EDI, MercuryGate with a built-out reporting suite), the overlay pattern is almost always the right answer for the first 12 months. Run Keelway as the AI layer on top, get the productivity gains, and revisit migration when your TMS contract is up for renewal. For brokerages on aging legacy TMSs without sticky investment — BrokerWare, older Aljex deployments, in-house spreadsheets — replacement is usually the right answer.
Planning a TMS migration?
Talk to the team that runs the migration plan.
Related
Mid-market McLeod overlay →
The reference deployment for an 85-broker 3PL choosing overlay over migration.
Migrating off BrokerWare →
Legacy broker TMS modernization framing — when migration is the right answer.
Keelway Enterprise →
The contracting and support posture for migrations that need a named implementation engineer.