Go-live is a process, not a date
Every carrier remembers its TMS go-live. For some, it was a smooth Monday: dispatch logged in, loads moved, invoices went out on Tuesday, and drivers were paid correctly on Friday. For others, it was weeks of re-rated loads, missing accessorials, rejected EDI invoices, and drivers calling about short settlements.
The difference is rarely the software. It is preparation. Since 2008, Strong Tower has supported carrier installations, conversions, upgrades, and on-site go-live weeks, and the pattern holds: the go-lives that go well are the ones where data was cleaned early, rates were tested against real loads, trading partners were certified ahead of time, people were trained on their own work, and the cutover was rehearsed.
This checklist is organized by phase. Adapt it to your system and your operation, but do not skip a phase. Each one protects the next.
Phase 0: Governance and go/no-go criteria
Before anyone converts a record, agree on how the project will be run and how you will decide you are ready.
| Governance Element | Executive Owner | Mandatory Sign-Off Criteria |
|---|---|---|
| Executive sponsor named | Owner / president | One person can make final calls on scope, date, and spend |
| Project manager named | Sponsor | Owns the plan, the issues log, and the weekly status |
| Department leads named | Sponsor | Dispatch, billing, settlements, safety, accounting, and IT each have a decision-maker |
| Go-live date selected | Sponsor and PM | Avoids month-end, peak season, holidays, and settlement day |
| Go/no-go criteria written | PM and leads | Specific tests that must pass, signed off in advance |
| Rollback plan written | PM and IT | Clear point of no return and how to revert before it |
Write the go/no-go criteria early, while nobody is under deadline pressure. Typical criteria: rating tests pass on an agreed sample of loads, a test settlement matches the old system, every EDI trading partner is certified or has a manual fallback, opening balances reconcile, and every user has completed role training.
Phase 1: Master data conversion
Bad data in the old system becomes bad data in the new one, only faster. Clean before you convert.
| Master Data Domain | Conversion & Cleansing Protocol |
|---|---|
| Customers and bill-to accounts | Merge duplicates; confirm bill-to vs. shipper vs. consignee relationships; credit limits and terms; invoice delivery method and required paperwork |
| Locations | Standardize addresses; confirm geocodes or mileage points; hours, appointment rules, and special instructions |
| Drivers | Pay profiles, home terminal, hire dates, license and medical card dates, deduction and escrow setups |
| Owner-operators and carriers | Lease or carrier agreements, pay terms, insurance, authority, remit-to and 1099 details |
| Equipment | Tractors, trailers, and containers with unit numbers, ownership, and maintenance status |
| Vendors | Fuel, repair, lumpers, and other payees mapped to accounting |
| Users and security | Roles and permissions by job, not by person; nobody gets admin by default |
Run at least two test loads of the converted data before the final conversion. After each, have the people who use the data check it. A billing clerk will spot a wrong bill-to in seconds that an analyst might miss for weeks.
Phase 2: Rates, tariffs, and fuel surcharge tables
Rating is where go-lives quietly lose money. A missing accessorial or a wrong FSC table does not crash anything. It just under-bills, load after load, until someone notices.
- Inventory every rate source: customer contracts, tariffs, spot quotes, lane rates, minimums, and mileage bases.
- Retire dead rates before conversion instead of moving them across.
- Build fuel surcharge tables per customer agreement: index source, update day, peg price, increment, and calculation method.
- Set up accessorials: detention, layover, stop-offs, tarping, lumper reimbursement, TONU, driver assist, and hazmat, with the rules for when each applies.
- Pick a test sample of real recent loads that covers every major customer, lane type, and accessorial.
- Rate the sample in both systems and reconcile every difference to a cause before sign-off.
- Confirm mileage settings such as routing type and version match what customers were billed under.
Phase 3: EDI trading partners
Your largest shippers likely tender and pay through EDI. A broken 204 or 210 at go-live can mean lost tenders or rejected invoices, so treat each trading partner as its own mini-project.
| EDI Transaction Set | Trading Partner Certification Test Scope |
|---|---|
| 204 Load Tender | Tenders create orders correctly with stops, references, and appointment times |
| 990 Response | Accept and decline responses reach the partner within their acceptance window |
| 214 Status | Pickup, delivery, and in-transit statuses fire with the codes the partner expects |
| 210 Invoice | Invoice totals, accessorial codes, and references match the partner's requirements |
| 997 Acknowledgment | Functional acknowledgments are sent and received; rejects are monitored |
- List every partner, transaction set, and connection method.
- Confirm identifiers, qualifiers, and any connection changes with each partner well before go-live.
- Schedule partner testing early. Many shippers need lead time to test and certify.
- Plan the switch so tenders in flight are not lost or duplicated at cutover.
- Agree on a manual fallback, such as email tenders or portal invoicing, for any partner not certified in time.
Phase 4: ELD, telematics, and other interfaces
- ELD and telematics: unit and driver IDs mapped correctly; positions, HOS data, and messages flowing; load assignments reaching the cab if your workflow uses them.
- Mileage and routing: the same settings used for rating, pay, and fuel tax reporting.
- Fuel cards: transaction imports mapped to drivers and units; advances and fuel purchases flowing to settlements and fuel tax records.
- Document imaging: scans attach to the right orders; PODs available to billing; historical images still reachable.
- Customer tracking or portals: statuses and documents visible to customers as before.
Test each interface with live-like data, then test the whole chain: tender in, dispatch, ELD status, delivery, POD, invoice, settlement.
Phase 5: Accounting and settlements
The first settlement run is the moment drivers judge the new system. Get it right.
| Accounting Subsystem | Opening Balance & Sub-Ledger Verification Checklist |
|---|---|
| Chart of accounts mapping | Revenue, accessorial, fuel surcharge, pay, and deduction codes post to the right GL accounts |
| Opening AR | Open invoices converted; aging totals match the old system to the penny |
| Opening AP and payables | Open vendor and carrier payables converted and reconciled |
| Driver balances | Escrow balances, advance balances, loan and recurring deduction balances converted and confirmed |
| Pay rules | Mileage, percentage, hourly, stop pay, and detention pay tested on real trips |
| Test settlement | Run a settlement period in both systems and compare driver by driver |
| Statements and cheques | Invoices, settlement statements, and cheque layouts printed and approved |
Have payroll staff and, if possible, a couple of trusted drivers or owner-operators review test settlement statements. If a driver cannot read the statement, you will hear about it on Friday.
Phase 6: Training
- Train by role: customer service, dispatch, billing, settlements, safety, maintenance, and management.
- Use your own customers, lanes, and loads in the training environment, not generic demo data.
- Train close to go-live so skills are fresh, with a refresher the week before.
- Name and train super-users in each department who will be the first line of help.
- Provide short written job aids for the top tasks in each role.
- Confirm every user can log in with the right permissions before cutover weekend.
Phase 7: Cutover weekend
Write the cutover as an hour-by-hour runbook with owners, and rehearse it at least once.
| Cutover Timeline | Execution Task & Technical Milestone |
|---|---|
| Before freeze | Full backup of the old system; confirm it restores |
| Freeze | Stop new entry in the old system; capture final open orders, loads in transit, and balances |
| Conversion | Run final data conversion; load open orders and in-transit loads |
| Reconciliation | Compare counts and totals: customers, open orders, AR aging, AP, driver balances |
| Interfaces | Switch EDI, ELD, fuel card, and imaging connections; send test transactions |
| Smoke test | Department leads enter, dispatch, and bill test loads end to end |
| Go/no-go | Sponsor reviews criteria and makes the call |
| Old system | Set to read-only for lookups and history |
Enterprise TMS Go-Live Cutover Runbook & Zero-Defect Migration Matrix
A flawless cutover is orchestrated like a precision military operation. Below is the hour-by-hour operational matrix governing the transition from legacy system freeze to live dispatch:
| Cutover Phase | Target Timeline (T-Minus) | Critical Technical Deliverables | Verification Checkpoint | Rollback Contingency Trigger |
|---|---|---|---|---|
| 1. Legacy Data Freeze & Extraction | Friday 18:00 - 22:00 | Lock legacy database permissions to read-only; execute automated SQL extraction scripts for open loads, tractors, drivers, and rate tariffs. | Source and extracted record counts match 100% across all entity tables; baseline SQL backup verified restorable. | Corrupt database export or missing relational keys aborts cutover before legacy write freeze is enacted. |
| 2. Staging Load & Master Transformation | Friday 22:00 - Saturday 06:00 | Ingest extracted data into new TMS database; execute postal code geocoding, tariff schema mapping, and driver profile initialization. | Automated staging audit confirms zero orphan orders, duplicate customers, or unmapped bill-to entities. | Data transformation failure exceeding 4-hour remediation buffer halts migration. |
| 3. Telematics & EDI Re-Pointing | Saturday 06:00 - 14:00 | Switch EDI AS2 and VAN endpoints to new mailboxes; update ELD in-cab telematics data feeds (Samsara, Motive) to point to new API listener. | Test EDI 204 tender parsed; live test GPS ping and duty status update ingested and visible on dispatch board. | Inability to establish stable 2-way ELD communication triggers immediate escalation to fallback integration protocol. |
| 4. Financial Re-Rating & Dual Run Smoke Test | Saturday 14:00 - Sunday 12:00 | Execute rating engine against 100 real delivered loads; run sample driver settlement batch; compare gross revenue and driver net pay. | Variance between legacy and new rating output is $0.00 or traced to known, documented accessorial correction. | Unexplained rating variance exceeding 1.5% across contract lanes triggers executive project sponsor review. |
| 5. Go/No-Go Decision & Floor Activation | Sunday 14:00 - Monday 06:00 | Executive sponsor reviews all 12 sign-off checkpoints; floor support personnel stage at terminals; live dispatch opens. | Dispatchers successfully book, assign, and dispatch first live Monday morning loads without supervisor intervention. | Hard go/no-go deadline of Sunday 16:00; if no-go, revert network DNS and restore write access to legacy TMS. |
72-Hour Cutover Weekend Minute-by-Minute Operational Runbook
A successful transportation cutover leaves nothing to chance. Below is the carrier minute-by-minute execution timeline from legacy system freeze through full Monday morning dispatch:
| Execution Window | Cutover Workstream | Operational Tasks & Milestones | Lead Role | Rollback Gate Check |
|---|---|---|---|---|
| Friday 16:00 - 18:00 | Pre-Freeze Snapshot | Broadcast final driver in-cab notifications; verify all delivered Friday loads have POD scans indexed; snapshot legacy database. | IT Lead / Operations | All in-transit loads confirmed assigned and geofence locations mapped. |
| Friday 18:00 - 22:00 | Database Cold Backup | Disable user write logins across legacy system; generate full cold database SQL dump; compute SHA-256 hash checksum for legal archives. | Database Admin | Hash matches source export; trial restore verified in air-gapped staging VM. |
| Friday 22:00 - Saturday 04:00 | Active Load & Balances ETL | Extract open orders, active trips, equipment status, and open AR/AP sub-ledger balances; execute cleansing and schema translation scripts. | Migration Engineer | Zero orphan records or broken customer bill-to foreign keys. |
| Saturday 04:00 - 10:00 | Target Database Ingestion | Bulk-load cleansed records into production TMS database; verify row count parity across orders, drivers, tractors, trailers, and tariffs. | Migration Engineer | 100% record match between legacy source extract and new database tables. |
| Saturday 10:00 - 16:00 | Telematics & EDI Re-Pointing | Re-point ELD telematics webhooks (Samsara, Motive, Geotab) to new TMS listeners; re-route AS2 / FTP EDI trading partner connections. | EDI / Telematics Specialist | Test EDI 204 received and acknowledged with 997; live GPS coordinates flowing to dispatch board. |
| Saturday 16:00 - 22:00 | Tariff & Accessorial Benchmarking | Rate 100 historical loads across contract, spot, and multi-stop tariff structures; verify DOE fuel surcharge calculations and accessorial rules. | Billing Supervisor | Total invoice variance across test sample is less than $1.00 ($0.00 variance on linehaul). |
| Sunday 08:00 - 12:00 | Opening Ledger Reconciliation | Reconcile opening AR aging report and driver escrow balances between legacy sub-ledger and new TMS general ledger integration. | Controller / CFO | Penny-perfect reconciliation between source sub-ledger and new database opening balances. |
| Sunday 12:00 - 15:00 | End-to-End Operational Smoke Test | Super-users enter, dispatch, track, deliver, bill, and settle three live test loads across dry van, flatbed, and brokerage divisions. | Super-User Team | All dispatch screens, driver mobile prompts, and invoice generation flows complete smoothly. |
| Sunday 15:00 - 16:00 | Executive Go/No-Go Decision Gate | Review 12 mandatory sign-off criteria with executive sponsor; confirm all departmental leads concur with cutover proceeding. | Executive Sponsor | Formal unanimous sign-off; if aborted, restore legacy write access before 17:00 Sunday. |
| Monday 05:00 - 17:00 | Live Floor Staging & First Dispatch | Strong Tower floor support engineers stationed beside dispatch, billing, and settlements desks; live Monday dispatch commences. | Floor Support / Leads | First 50 loads dispatched with active tracking and zero customer or driver friction. |
Staffing go-live week
Go-live week is not the time to run lean. Freight does not slow down because you changed systems, and every new screen takes a little longer the first few times. Plan the people before you plan the parties.
| Go-Live Support Role | Operational Floor Mandate |
|---|---|
| Floor support | Experienced implementers sitting with dispatch, billing, and payroll, answering questions at the desk |
| Super-users | First line of help in each department; log issues they cannot solve |
| Issues coordinator | Owns the issues log; assigns, tracks, and closes every item |
| Vendor support | Named contacts on call, with an agreed escalation path for system defects |
| Interface watcher | Monitors EDI, ELD, fuel card, and imaging queues throughout the day |
| Sponsor | Available daily to make scope and priority calls quickly |
Consider lightening the load where you can: avoid onboarding new customers, launching new lanes, or starting other projects the same week. Tell your key customers and drivers that you are changing systems, who to call with questions, and what, if anything, will look different on their invoices or settlement statements.
Day 1, week 1, and month 1
Day 1
- Support staff on the floor at start of shift, in every department.
- Morning stand-up and end-of-day review of every issue.
- Watch EDI queues for rejected tenders and missing 214s.
- Confirm ELD positions and statuses are updating.
Week 1
- Review the first invoices before they go out; check rates, FSC, and accessorials.
- Confirm first 210s are accepted by trading partners.
- Triage the issues log daily: fix, train, or defer with an owner.
- Run the first settlement with extra review time and compare a sample to expected pay.
Month 1
- Close the first month and reconcile the TMS to the general ledger.
- Check AR aging against expectations; look for invoices stuck on billing holds.
- Run fuel tax and mileage reports and confirm the data looks right.
- Hold a lessons-learned session and schedule refresher training where needed.
- Close or schedule every remaining punch-list item.
Common go-live mistakes
- Converting dirty data and planning to clean it "after go-live."
- Testing rates on a handful of easy loads instead of a representative sample.
- Starting EDI partner testing too late.
- Training too early, or training on generic data.
- Going live on month-end or right before settlement day.
- No written rollback plan or go/no-go criteria.
- Sending vendor support home on Tuesday.
How Strong Tower Consulting helps
Strong Tower Consulting has planned and supported carrier go-lives since 2008, including on-site go-live weeks, data conversions, and staff training. Our TMS Implementation & Go-Live practice covers data conversion, testing, cutover planning, and floor support. Project & Program Management keeps vendors and internal teams on plan, Training & Enablement builds role-based training on your own freight, and ELD, EDI & Back-Office Integration handles trading partner and interface testing.
Independent by design
Strong Tower Consulting never requires you to buy our software. We support go-lives on the system you chose, and our only goal is a clean cutover and a first settlement run your drivers trust.
Frequently asked questions
What is the optimal day and time to execute a TMS cutover?
Friday evening at 18:00 is the industry standard cutover window for motor carriers. It provides 48 to 60 hours over the weekend to freeze legacy transactions, execute database extraction scripts, reconcile opening AR/AP balances, and conduct end-to-end smoke tests before full Monday morning dispatch commences.
Should a carrier run the legacy TMS and new TMS in parallel?
Full operational dual-entry parallel runs double dispatcher workload and lead to data drift. Best practice is parallel validation of high-risk financial outputs only: rating a representative 100-load test batch in both systems, running dual driver settlement calculations, and maintaining the legacy system in read-only mode for historical lookups.
How much historical data should be migrated into the new TMS database?
Carriers should migrate 100% of active master data (customers, locations, drivers, equipment, tariffs), all active open orders, and uncollected AR / unpaid AP sub-ledger balances. Historical closed loads older than 12 to 24 months should remain archived in a cold reporting SQL database to avoid database bloat and indexing latency.
When is a TMS software implementation officially complete?
Go-live is not the finish line. An implementation is deemed successful only after the 30-day stabilization window concludes: when the first complete driver settlement run balances without manual pay adjustments, customer EDI 210 invoices achieve 99%+ acceptance, and the first month-end general ledger closes cleanly.
How does modern native TMS architecture simplify go-live cutover compared to legacy on-premise systems?
Modern cloud-native platforms like our sister company Exspeedite require zero client workstation installations, local SQL server configurations, or VPN tunnels. Dispatchers and billing clerks access the platform instantly via secure web browsers, allowing immediate cutover, frictionless floor training, and rapid remote user onboarding.
Does Strong Tower Consulting require software purchases to provide go-live advisory?
No. Strong Tower Consulting is an independent transportation technology advisory firm founded in Minnesota in 2008. We provide vendor-neutral cutover planning, data migration engineering, and on-site go-live floor support across Trimble Truckmate, TMWSuite, McLeod LoadMaster, and Exspeedite.
Should we run the old and new TMS in parallel?
A full parallel run doubles the workload, so most carriers parallel only the high-risk outputs: rating a sample of loads in both systems, running a settlement in both and comparing, and reconciling invoices. Keep the old system available read-only for history and lookups.
How much history should we convert into the new TMS?
Convert all active master data, open orders, and open AR and AP balances. For history, decide based on reporting, audit, and claims needs. Many carriers convert a limited window and keep older history accessible in the old system or a reporting database.
When is a TMS implementation really finished?
Not at go-live. Plan on the first month as stabilization. The implementation is finished when billing, settlements, EDI, and the first month-end close all run cleanly, and the punch list is closed or scheduled.
Do we have to buy software from you to get go-live help?
No. Strong Tower Consulting is independent and supports go-lives on the TMS you selected. Consulting never requires buying our sister company's software.