- There are four paths, not two: keep, optimize, integrate around, or replace.
- The decision starts with an inventory of what the current system really does, including the parts nobody wrote down.
- Cost is compared over the same period for every option, including migration, training, and parallel running.
- The largest migration risk is a field whose meaning changes quietly. Reconcile totals, not just row counts.
- EDI partners and driver settlement move on a written schedule, with a parallel run and a rollback plan.
Why a legacy TMS decision deserves an independent review
Strong Tower Consulting, LLC is an independent systems architecture and technology advisory firm founded in Minnesota in 2008 by Scott Elliott. For more than 18 years, the firm has worked on the systems that run freight operations: transportation management systems, EDI 204, 990, 214, and 210 flows, driver settlement, rate and tariff engines, accounting integration, SQL data, ELD and telematics, and applied AI.
A TMS that has been in place for ten or fifteen years is rarely just software. It holds the customer rate history, the settlement rules drivers rely on, the EDI maps every shipper depends on, and dozens of reports that finance and operations use each week. Some of the habits built around it are good business rules. Others are workarounds. A sound decision separates the two before anyone signs a contract.
The common question is "should we replace our TMS?" The better question is "what problem are we trying to solve, and which path solves it with the least risk?" Sometimes the answer is a new platform. Often it is a cleaner configuration, a better report, or a small integration built around a system the team already knows. Strong Tower Consulting writes the comparison down so leadership can see the reasoning, not just the conclusion.
Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership.
The four paths: keep, optimize, integrate around, or replace
Every review compares the same four options, even when one looks obvious.
- Keep. The system meets current needs, the vendor or internal team supports it, and the pain is tolerable. The work is documentation, a support plan, and a date to review again.
- Optimize. The system can do the job, but configuration, data quality, or reporting holds it back. Examples include cleaning up rate tables, retiring unused pay codes, fixing slow reports, and training dispatch on features they never turned on.
- Integrate around. The core is stable, but a specific function needs more than the system offers. A rate engine, a document workflow, a telematics feed, or an accounting sync is built beside the TMS and connected through a defined interface.
- Replace. The system cannot support where the business is going, support is ending, or the cost of workarounds exceeds the cost and risk of moving. Replacement is planned as a program with a migration plan, a parallel run, and a rollback point.
Whether the current platform is a commercial product such as Truckmate, McLeod LoadMaster, or TMW, or a system built in house, the four paths and the questions behind them are the same. The review is about fit for this carrier, not a ranking of products.
Decision criteria Strong Tower Consulting applies
Each path is scored against written criteria that the carrier agrees to before the scoring starts. Agreeing on criteria first prevents the loudest complaint in the building from deciding the outcome.
- Business fit. Does the system support the freight the carrier actually hauls: truckload, LTL, dedicated, brokerage, intermodal, or a mix? Does it support where the business plans to be in three to five years?
- Supportability. Is the version supported? Are there people, inside or outside, who can maintain the customizations? Is knowledge concentrated in one person?
- Data health. Are customers, locations, drivers, and equipment clean and unique? Are rate tables current, or full of expired entries nobody trusts?
- Integration surface. How many EDI partners, ELD and telematics feeds, fuel card files, and accounting connections depend on the system? Each one is work in any change.
- Settlement and billing accuracy. Can the team explain every driver pay line and every invoice line from source records?
- Total cost over a fixed period. Compare the same number of years for every option, with one-time and recurring costs separated.
- Change capacity. Does the organization have the people and the calendar room to absorb a large project this year?
Signs to optimize or integrate around
- The core workflows run, but reports or rate tables are hard to maintain
- One function, such as rating or settlement, needs more than the system offers
- The version is supported and the team knows the system well
- Most complaints trace to data quality or training, not missing capability
Signs to plan a replacement
- The version is near or past the end of support with no path forward
- The business is entering freight modes the system cannot model
- Customizations are maintained by one person or nobody
- Workarounds and side spreadsheets now carry core business rules
Cost belongs in the comparison, but it has to be counted the same way for every path. A replacement that looks cheaper per year can cost more over five years once migration, training, and a parallel run are included. A keep decision can look free while hiding the labor of manual workarounds.
Total cost of ownership over the same period for each path:
TCO = one-time costs (implementation + migration + training + parallel run) + years × (license or subscription + support + integration upkeep + workaround labor)
Teaching numbers only. Keep path with heavy workaround labor:
0 + 5 × (40,000 + 15,000 + 10,000 + 35,000) = 500,000
Replace path with lower recurring cost:
(120,000 + 60,000 + 20,000 + 30,000) + 5 × (55,000 + 10,000 + 8,000 + 5,000) = 230,000 + 390,000 = 620,000
In this teaching case the keep path costs less over five years even though its yearly cost is higher. Change the workaround labor or the period and the answer can flip. That is why the inputs are written down and checked with the carrier's own figures.
Data migration risks
When a replacement is chosen, migration is where most of the risk lives. Moving rows from one database to another is the easy part. Keeping their meaning intact is the hard part.
Meaning drift. A status code, a pay type, an accessorial code, or a rate unit can move cleanly and still be used differently by the new system. A load marked "complete" in one system might mean delivered, while in another it might mean billed. Every code needs a written mapping to its business meaning, signed off by the people who use it.
Master data duplicates. Long-running systems collect duplicate customers, locations, and drivers. Migrating duplicates moves the problem forward and can split billing history across records. Clean and merge before the move, not after.
History scope. Decide how much history moves. Open loads, open invoices, open settlements, and active rates must move. Closed history may stay in a read-only archive that finance and audit can still query. Moving everything by default slows the project and imports old errors.
Hidden logic. Business rules often live in stored procedures, custom reports, or spreadsheets outside the TMS. If nobody inventories them, they disappear at cutover. SQL data mining work is how those rules are found and written down.
Reconciliation by totals. Matching row counts proves little. Totals by customer, driver, and period must match between the legacy system and the new one before anyone trusts the new numbers.
Find every customer and month where migrated billing totals differ from the legacy system. An empty result is the goal.
SELECT l.customer_id, l.bill_month, l.total_billed AS legacy_total, COALESCE(n.total_billed, 0) AS new_total, l.total_billed - COALESCE(n.total_billed, 0) AS difference FROM legacy_billing_summary l LEFT JOIN new_billing_summary n ON n.customer_id = l.customer_id AND n.bill_month = l.bill_month WHERE l.total_billed <> COALESCE(n.total_billed, 0) ORDER BY ABS(l.total_billed - COALESCE(n.total_billed, 0)) DESC;
The same pattern applies to driver pay by driver and pay period, and to fuel surcharge by customer and week. Table and column names here are placeholders.
The TMS data migration practice covers mapping, cleansing, trial loads, and sign-off in more detail.
EDI and settlement continuity at cutover
Customers notice an EDI failure within hours. Drivers notice a settlement error on the next statement. Both deserve their own cutover plan, separate from the general go-live checklist.
EDI. Inventory every trading partner and every transaction set in use: 204 load tenders, 990 responses, 214 status messages, and 210 freight invoices, plus any others. For each partner, confirm the map, the identifiers, the communication method, and the test contact. Move partners in planned groups rather than all at once. A partner is not moved until test tenders are accepted, status messages arrive with correct codes, and a test invoice is accepted. Keep the legacy connection available until each partner confirms. The EDI transaction lifecycle playbook walks through each set.
Driver settlement. Run settlement in both systems for at least one full pay cycle. Compare every driver statement line by line: mileage pay, accessorials, fuel, deductions, escrow, and advances. A difference stops the cutover for that driver group until it is explained. Drivers are paid from the legacy system until the new statements match. The driver settlement and escrow guide covers the ledger rules.
Do during cutover
- Move EDI partners in planned groups with a named test contact
- Run settlement in parallel for a full pay cycle
- Reconcile billing and pay totals before turning off the legacy system
- Write a rollback point and the conditions that trigger it
Avoid during cutover
- Switching every trading partner on the same day
- Paying drivers from the new system before statements match
- Turning off legacy access before history is archived and queryable
- Scheduling go-live at month end or during peak season
Accounting needs the same care. Invoices, payables, and settlements must post to the general ledger the same way before and after. Transportation accounting integration work confirms the postings tie.
How a Strong Tower Consulting review runs
The review follows a plain sequence, so leadership can stop at any point with something useful in hand.
The inventory phase interviews dispatch, billing, settlement, safety, and finance, and reads the database where access allows. The final document states the recommendation, the assumptions behind it, and what would change the answer.
Every recommendation lists its assumptions and inputs. If an input changes, such as support dates, freight mix, or staff capacity, the carrier can see whether the answer changes too.
When the answer is replace, the plan continues into selection and TMS implementation. When it is optimize, it continues into business process optimization or rate matrix optimization. When it is keep, the plan sets a review date in the IT strategy plan.
Frequently asked questions
What does Strong Tower Consulting do when a carrier asks whether to replace its TMS?
Strong Tower Consulting starts by documenting what the current system actually does today: the workflows, the EDI partners, the settlement rules, the reports, and the integrations. Only then are four paths compared side by side: keep, optimize, integrate around, or replace. The recommendation is written with its assumptions, so the carrier can check the reasoning.
Does the review favor a particular TMS vendor?
No. The review looks at the system the carrier runs, whether it is a commercial platform or a homegrown one, and scores every option against the same written criteria. Vendor names appear only as facts about the current environment or the candidate list the carrier chose to evaluate.
What is the biggest data migration risk in a TMS replacement?
Meaning changing without anyone noticing. A field can move cleanly from one database to another and still be used differently by the new system, such as a status code, a rate unit, or a settlement pay type. Mapping every code to its business meaning, then reconciling totals by customer, driver, and period, is how that risk is controlled.
How do EDI and driver settlement keep running during a cutover?
Each trading partner is tested and moved on a written schedule, with the 204, 990, 214, and 210 flows confirmed before the legacy connection is turned off. Driver settlement runs in parallel for at least one full pay cycle, and the new statements must match the legacy statements line by line before drivers are paid from the new system.
Who founded Strong Tower Consulting and how long has it operated?
Strong Tower Consulting, LLC was founded in Minnesota in 2008 by Scott Elliott and has more than 18 years of continuous commercial operation as an independent systems architecture and technology advisory firm for motor carriers, freight brokers, private fleets, and enterprise clients.
Decide on your TMS with the facts written down.
Carriers, freight brokers, private fleets, and enterprise clients can call Strong Tower Consulting at 763-244-1373 to talk through a legacy TMS, the four paths, and what an independent review would cover for their operation.
Published October 23, 2026 by Strong Tower Consulting, LLC. Founded 2008 in Minnesota by Scott Elliott.