The legacy TMS question nobody wants to answer
Somewhere in most carrier offices is a TMS that was chosen ten or twenty years ago. It has been upgraded a few times, customized more times than anyone can count, and wired into ELD, fuel card, imaging and accounting interfaces one at a time. It still moves freight. But every change takes longer, the person who understood the custom code retired, and a vendor or two is telling leadership that it is time to replace the whole thing.
Replacing a TMS is one of the largest projects a trucking company will take on. It touches every desk from order entry to payroll. Done well, it removes years of friction. Done badly, it stalls billing, frustrates drivers and burns cash for months. And sometimes, after an honest look, the right answer is not to move at all.
This guide gives you a way to make that call with evidence, then covers the three stages where migrations most often go wrong: data, parallel run and cutover.
The decision framework: three honest options
Every legacy system review should end with one of three answers.
Stay
The system meets the business's requirements, is supported, and can be secured. The pain is mostly process, training or data quality. You keep it, document it and invest modestly in using it well.
Fix
The system is fundamentally capable, but it is behind on versions, carrying undocumented customizations, or poorly configured. You stabilize it: upgrade to a supported release, inventory and test custom code, clean the data, turn on features you already pay for and retrain staff. Fixing buys years, and it also leaves you in a much better position if you move later.
Move
The system cannot support where the business is going, or carries risk you cannot accept. You plan a controlled exit: requirements, selection, data migration, parallel testing and cutover.
Signals that point each way
| Signal | Usually means |
|---|---|
| Staff complain about steps that the system can already automate | Fix: configuration and training |
| Billing is slow because of duplicate customers and stale tariffs | Fix: data cleanup |
| Several releases behind, upgrades blocked by custom code | Fix first, then reassess |
| Version is out of vendor support with no upgrade path | Move, or isolate and plan an exit |
| Runs on an operating system or database that no longer gets security updates | Fix the platform if possible, otherwise move |
| Cannot support a business line you are entering (brokerage, drayage, LTL) | Move, or add a purpose-built module if integration is solid |
| Required EDI or integrations cannot be built or maintained | Move, unless middleware closes the gap reliably |
| Multiple systems after an acquisition | Consolidate onto the stronger platform |
Separate system limits from setup problems
The most expensive mistake in this decision is replacing software to fix problems the software didn't cause. A new TMS will happily inherit your duplicate customers, inconsistent lane naming, undocumented accessorial rules and untrained new hires. Before you put a dollar figure on a replacement, ask each department to list its top five frustrations, then classify each one:
- System limit: the software genuinely cannot do it.
- Setup: the software can do it but isn't configured to.
- Data: the software works, but the data feeding it is wrong.
- Process or training: people work around the system because nobody showed them the right way.
If most of the list falls outside the first bucket, the strongest business case is usually Fix.
Put real numbers on stay versus move
Compare a five-year cost of staying (support, upgrades, infrastructure, workarounds, manual labor, risk) against the cost of moving (software, implementation, integrations, data migration, staff time, transition slowdown). Include the cost of doing nothing about known risks, such as an unsupported database. A decision made on numbers is easier to defend to owners and lenders, and harder for a vendor to talk you out of. Our TMS selection guide covers the cost buckets in detail.
Data migration: plan the path before anything moves
Data migration decides whether go-live week is calm or chaotic. Treat it as its own workstream with an owner, a plan and a test schedule, not as a task the vendor handles in the background.
What moves, and when
| Data type | Examples | Typical approach |
|---|---|---|
| Master data | Customers, bill-to and ship-to locations, carriers, drivers, tractors, trailers, vendors, chart of accounts | Cleanse, then migrate all active records |
| Rates & rules | Tariffs, contract rates, FSC tables, accessorial codes, pay rates, deductions | Migrate and re-validate; often rebuilt rather than copied |
| Open transactions | Loads in progress, open AR invoices, open AP, unsettled driver pay, escrow balances | Migrate at cutover, then reconcile to the penny |
| History | Closed loads, paid invoices, past settlements | Defined window migrated; full archive kept read-only |
| Documents | BOLs, PODs, rate confirmations, driver files | Move or link, with retention rules confirmed |
The migration cycle
- Profile. Pull counts and samples from every table you plan to move. Find the duplicates, blanks, invalid codes and orphaned records before they become someone else's problem.
- Map. Field by field, document where each value goes and how codes translate. Pay special attention to customer and location identifiers, accessorial codes, pay codes and GL accounts.
- Cleanse. Merge duplicate customers, retire dead lanes and inactive drivers, standardize location names. Cleanse in the old system where possible, so both sides agree.
- Test-load. Load into a test environment at least two or three times before cutover. Each cycle should get faster and cleaner.
- Reconcile. Compare record counts, AR and AP totals, driver balances and escrow by account. Have billing and payroll leads sign off.
Keep the old database
Do not decommission the legacy database at cutover. Keep a secured, read-only copy for audits, IFTA questions, claims and historical reporting. It is cheap insurance, and someone will need it.
Parallel run: prove it before you trust it
A parallel run means processing real work in both the old and new systems and comparing the results. A full parallel of every load is rarely practical for a busy dispatch floor; people simply won't double-enter everything for weeks. A targeted parallel works better.
What a targeted parallel looks like
- Pick a representative sample: a few customers from each rating type, each major load type, and drivers from each pay method.
- Run that sample through order entry, dispatch, billing and settlement in the new system for at least one full billing cycle and one pay period.
- Compare invoices line by line: linehaul, FSC, accessorials, totals.
- Compare settlements line by line: miles, pay, deductions, advances, net pay.
- Compare GL postings and IFTA mileage outputs.
- Log every difference, find the root cause, fix it and rerun.
Define the exit criteria in writing before you start, for example: all sampled invoices match to the cent or have an explained, approved difference; all sampled settlements match; GL postings balance. When the criteria are met, you have earned the right to schedule cutover.
Cutover: a weekend, a runbook and a way back
Cutover is the controlled switch from the old system to the new one. It should feel boring. Boring comes from a written runbook rehearsed in advance.
Cutover runbook checklist
- Date chosen in a low-volume window, away from month-end, quarter-end and peak season.
- Billing and settlements closed in the old system right before the switch, so open items are minimal.
- Final full backup of the legacy system, verified restorable.
- Freeze time for the old system announced to every department and to drivers.
- Final open-transaction migration script, with reconciliation steps and sign-off owners.
- Integrations repointed: ELD, fuel card, accounting, imaging, mileage, EDI trading partners (with partners told the date in advance).
- User accounts, security roles and printers or forms tested.
- A go/no-go meeting with named decision makers and clear criteria.
- A rollback plan: what triggers it, who calls it, and how far back you can go.
- Floor support scheduled for the first week, with experienced people at dispatch, billing and payroll desks.
The first two weeks
Expect friction. Order entry will be slower for a few days. Hold a short stand-up every morning with dispatch, billing, payroll and IT to triage issues. Track every problem on one list with an owner and a status. Watch three numbers closely: loads entered versus a normal week, invoices sent versus a normal week, and settlement exceptions. If billing falls behind, staff it up immediately; unbilled freight is the most expensive kind of go-live problem. Our TMS go-live checklist goes deeper on this window.
Common mistakes to avoid
- Choosing a replacement before deciding whether a replacement is needed.
- Leaving data migration to the end of the project.
- Copying old rate tables and pay setups without re-validating them.
- Forgetting to notify EDI trading partners and integration vendors of the cutover date.
- Cutting over at month-end or in peak season.
- Shutting off the old system before the first month-end close is clean in the new one.
- Under-staffing billing and payroll during the first pay cycle.
How Strong Tower Consulting helps
Strong Tower Consulting has worked inside legacy carrier systems since 2008: installations, upgrades, custom code reviews, database migrations and on-site go-live weeks. We start with an assessment that classifies your pain points honestly, then recommend Stay, Fix or Move with the numbers behind it. If moving is right, we run the data migration, design the parallel test and manage the cutover with your team.
- Legacy TMS Advisory & Migration: stabilize, optimize or plan a clean exit.
- TMS Selection & Advisory: vendor-neutral requirements, scripted demos and scoring.
- TMS Implementation & Go-Live: conversion, testing, training and go-live support.
- SQL Data Mining & Analytics: data profiling, cleanup and reconciliation.
Independent by design
Strong Tower Consulting never requires you to buy our software. Our sister company, Exspeedite, builds a TMS, which is why we know what is under the hood of yours. If staying put is the right answer, we will say so. If another product fits better, we will say that too. Read more about how we work.
Frequently asked questions
How do we know if our TMS is really the problem?
Separate system limits from setup and process problems. If the issue is stale rate tables, duplicate customers, untrained staff or features nobody turned on, a new TMS will inherit the same mess. If the system cannot do something the business requires, cannot be supported or cannot be secured, that is a true system limit.
How much history should we migrate to a new TMS?
Migrate all active master data and open transactions. For closed history, most carriers bring over a defined window for reporting and keep the full archive in a read-only copy of the old database. Keep whatever your tax, audit and customer contract obligations require, and confirm retention periods with your accountant.
Is a parallel run always necessary?
A full parallel run of every load is expensive and often unrealistic for a busy dispatch floor. A targeted parallel, where a sample of real loads, invoices and settlements is processed in both systems and the results reconciled, gives most of the protection at a fraction of the effort.
When is the best time to cut over?
Pick a period with lower volume and avoid month-end, quarter-end and your peak season. Many carriers cut over on a weekend shortly after a pay period and billing cycle close, so open items are at a minimum.
Will Strong Tower Consulting push us to replace our system?
No. Strong Tower Consulting is independent. Our consulting never requires buying our sister company's software, and many assessments end with a recommendation to stabilize and optimize the system you already have.