TMS implementation — a week-by-week checklist.

TL;DR

• Cloud TMS (Truckbase, Tailwind, Rose Rocket, Alvys, AscendTMS, ITS): 4–10 weeks, $0–$25K implementation, 1–3 office staff committed.
• Enterprise TMS (McLeod, Trimble): 4–9 months, $50K–$250K+ implementation, dedicated PM and 5–15 office staff committed.
• Single biggest risk: data migration quality. Bad customer/vendor data + bad rate data = bad invoices on day 1.
• Single biggest controllable safeguard: a 2–4 week parallel-run period where the old and new TMS run side-by-side and dispatch double-keys until reconciled.
• Don't skip: writing the implementation scope-of-work into the contract. "Vendor will provide reasonable implementation support" is not a scope-of-work.

Cloud vs enterprise — typical timelines

Phase	Cloud (small/mid)	Enterprise (on-prem/hybrid)
Discovery & contract	1–2 weeks	4–8 weeks
Data migration prep	1–2 weeks	4–6 weeks
Configuration	1–2 weeks	6–10 weeks
Integration wire-up	1–2 weeks	4–8 weeks
User training	1 week	2–4 weeks
Parallel run	2 weeks	4–8 weeks
Cutover	3 days	1–2 weeks
Total	~8 weeks	~6 months

Before signing — contract red flags to clear

• No documented scope-of-work. Implementation should list specific deliverables, milestone gates, named project contacts, and acceptance criteria. Generic language is the #1 dispute trigger.
• No documented data-export procedure. Demand a clause specifying loads, customers, drivers, settlements, documents are all exportable on cancellation in a documented format. Without this you're locked in.
• No annual-uplift cap. Vendors auto-uplift 3–7% by default. Negotiate a 3% or CPI cap.
• No parallel-run language. The contract should give you the right (and the vendor support) to run old and new in parallel for at least 2 weeks before cutover.
• "Custom development" billed T&M with no cap. Fixed-price the deliverables you can; cap T&M lines at a notional ceiling.
• Lock-step payment to vendor milestones. Avoid contracts that pay 50% on signing — gate payments to your accepted deliverables (configured environment, data migrated, training delivered, parallel-run accepted).
• No performance/SLA backstop. If the system is unavailable for X hours, what happens? At minimum you want pro-rated subscription credits. Enterprise contracts get explicit financial penalties.

Cloud TMS — week-by-week (8-week plan)

Week 0 — Pre-signing

1. Lock the contract red flags above.
2. Designate one internal owner — usually office manager or operations lead — as project lead. Avoid letting it default to ownership.
3. Schedule the discovery/kickoff call for the week the contract is signed.

Weeks 1–2 — Discovery & data export

1. Discovery call with vendor's onboarding team: business model, fleet size, ELD, factor, accounting, load board, primary brokers.
2. Inventory current-state data: customers, locations, vendors, drivers, equipment, rate tables, open loads, AR aging, AP aging.
3. Export each data set to CSV or whatever format the new TMS imports. Clean as you export. Address mismatches, dupe customers, dead drivers — fix in source first.
4. Map your chart-of-accounts (revenue codes, expense codes) to the new TMS's load codes and settlement structures.

Weeks 3–4 — Configuration & data load

1. Vendor configures account: company info, branding, user roles, permissions, dispatcher views, AR settings.
2. Bulk-import master data (customers, locations, drivers, equipment).
3. Wire up integrations: ELD (Samsara/Motive/Geotab), accounting (QuickBooks), factor (Apex/RTS/etc.), load board (DAT/Truckstop). One at a time — verify each before moving on.
4. Test invoice generation end-to-end on a sample load. Numbers must match what would have come out of the old system.

Weeks 5–6 — Training & soft-launch

1. Train each role separately: dispatchers, drivers, AR clerk, AP clerk, owner. Don't combine training sessions.
2. Run dispatchers through 5–10 sample loads in the new system before any real load touches it.
3. Soft-launch with a single broker or a single lane: real loads start moving in the new TMS while everything else stays in the old.
4. Keep a daily issues log. Categorize each: blocker / issue / nice-to-have.

Weeks 7–8 — Parallel run & cutover

1. Parallel run: dispatch every load in both systems. Reconcile invoices weekly. Reconcile settlements weekly.
2. If any blocker remains unresolved at end of week 7, pause cutover. Adding a week is cheaper than recovering from a botched cutover.
3. Cutover decision meeting Friday week 7. Go/no-go criteria documented in advance.
4. Cutover weekend: old system frozen, new system canonical. Final reconciliation Monday morning.

Enterprise TMS — phased (6-month plan)

McLeod LoadMaster and Trimble TMW.Suite implementations are typically run by a certified-partner system integrator, not the vendor directly. The integrator's professional services line item often equals or exceeds the software license itself. Expect a project organization with:

• Carrier side: Executive sponsor, project manager, business analyst, dispatcher SME, accounting SME, IT lead.
• Vendor side: Project manager, solution architect, configuration specialists per module, training lead.
• Integrator side: Project manager, technical lead, business analyst, change-management lead.

Months 1–2 — Discovery & design

1. Process workshops by department: dispatch, ops, safety, billing, settlement.
2. Solution-design document signed by carrier and vendor before configuration starts. This is the contract for what gets built.
3. Infrastructure provisioning (on-prem) or environment setup (hosted).
4. Data-migration strategy document: what gets migrated, what gets archived in old system, what gets re-keyed.

Months 2–4 — Configuration & build

1. Module configuration: dispatch, settlements, AR/AP, EDI, GL.
2. Custom-development items (vertical-specific workflows). Track each as a deliverable with acceptance criteria.
3. EDI partner setup with each broker (typically 5–20 partners). Each EDI connection is a mini-project.
4. Reports and dashboards: P&L by truck, lane, customer; KPI dashboards; settlement reports.

Months 4–5 — Integration & UAT

1. Wire up ELD/telematics, accounting (or rip out QuickBooks if McLeod/Axon-style), maintenance, factor, load board.
2. User Acceptance Testing — every workflow scripted and tested. Sign-off by the SME for each module.
3. Performance and load testing (especially on-prem).
4. Disaster-recovery and backup testing. Run a simulated DR drill.

Month 5 — Training

1. Train-the-trainer with internal SMEs first.
2. Cascade training to all end-users by role.
3. Materials: quick-reference cards, video tutorials, internal Slack/Teams channel for questions.

Month 6 — Parallel & cutover

1. 4-week parallel run minimum. Reconcile invoices and settlements weekly.
2. Phased cutover: high-volume customers first, long tail second.
3. Hypercare period: vendor + integrator + internal team on standby for 2–4 weeks post-cutover.

Data migration — what actually breaks

The single most common implementation failure is data migration quality. Specific traps to watch:

• Customer dupes. Same broker spelled three different ways across years of data. Migrate the dupes and AR aging by customer is meaningless.
• Dead drivers / equipment in the master tables. Drivers who left in 2022 still show in dispatch dropdowns.
• Inconsistent rate data. Standing rates per lane that haven't been updated. Migrate stale rates and your dispatcher quotes are wrong on day 1.
• Open AR that doesn't reconcile. Aged invoices in the old system that don't have a clean trail. Don't migrate these — close them out in the old system, start clean in the new.
• Documents that don't migrate. Most TMS migrations move structured data but not the BOL/POD PDF archive. Decide whether to bulk-archive old docs or migrate them.
• EDI transaction history. Almost never migrates. Decide what historical detail you need vs. archive.
• Settlements in flight. Driver settlement runs that span the cutover. Plan a clean break — either close out in the old system Friday, start fresh in the new system Monday.

The parallel-run period — why it's non-negotiable

Carriers who skip parallel run because "the new system is ready" almost always pay for it in the first 30 days post-cutover. Lost loads, mis-billed customers, double-paid drivers, missing PODs. Parallel run is the single largest risk-reduction tool you have. It's also where the vendor's implementation team should be most engaged — if they push back on a 2-week parallel run for a cloud TMS or a 4-week parallel run for enterprise, that's a red flag.

Parallel-run discipline: dispatcher dispatches every load in both systems. AR generates the invoice in both. Settlement runs in both. Every Friday, reconcile: where did the two systems disagree, why, and which one is right?

Most reconciliation issues fall into three buckets: (1) fee/accessorial coding mismatches, (2) customer mapping mismatches (same broker → different customer ID), (3) unit-of-measure issues (per-mile vs flat, per-hundredweight vs flat). Fix the configuration in the new system; don't accept the variance.

Post-launch — first 90 days

• Daily issue triage for the first 14 days. Project lead reviews every reported issue.
• Weekly stand-up for weeks 3–6 with vendor/integrator support engaged.
• Day-30 retrospective: what worked, what's still broken, what needs vendor attention.
• Day-60 KPI review: are operational metrics (loads/dispatcher/day, AR DSO, fuel-card reconciliation time) tracking better, same, or worse than before? "Worse" indicates training or workflow gaps.
• Day-90 acceptance: formal sign-off on the implementation. Final-payment milestone if any payment was withheld.

Common failure modes

• The "we'll figure it out at go-live" gap. A workflow nobody mapped during discovery — usually one specific customer's billing quirks, or one driver's settlement structure — surfaces day 1 and dispatch is paralyzed.
• Training-as-afterthought. Training pushed into the last week, then squeezed by overrun in configuration. Users hit go-live underprepared.
• Cutover-on-Friday-night theater. Old system shut down 5pm Friday, new system live 8am Monday, problems surface 8:15am Monday with no support team available. Cut over on a quiet day mid-week, not Friday night.
• Single point of failure. Project lead is also dispatcher / AR clerk / owner. They're the implementation expert AND the daily-ops resource. They can't do both.
• Vendor changes during implementation. Vendor's onboarding lead leaves mid-project. The replacement doesn't have your project history. Insist on documented project status updates and milestone deliverables that survive personnel turnover.
• Skipping integration depth verification. "We integrate with QuickBooks" → reality, the integration only pushes invoices, not payments back. Test the bidirectional flow during configuration, not after go-live.

---

Use this with our other guides

1. Use the 12-question framework to narrow your shortlist.
2. Use our RFP template to force structured vendor answers — including their proposed implementation plan.
3. Run the pricing guide to budget realistically — implementation is the line that gets under-counted most.
4. Cross-check vendor integration claims against our integration matrices before signing.