Leaving a legacy TMS: the freight records and rules that must come with you
Key Takeaways
- Leaving a legacy TMS means preserving decisions, not screens: approved carriers and contacts, rates and contracts, routing and business rules, approval limits, accessorial rules and customer notification rules.
- Two more items need their own plan: shipments still open at cutover, which need a named owner, and the history the company wants to keep for audits, disputes and reporting.
- For each item, the migration checklist records where it usually lives, who owns it and what to confirm before cutover.
- Wilson, by Cartage, replaces the TMS for freight execution and works from the company's approved carriers, rules, approval limits and contacts.
- How that information moves into the new freight workflow depends on the customer's environment and implementation scope; historical records may need to be retained by the company itself.
What has to come with you when you leave a legacy TMS?
What has to come with you is the operating logic the TMS carried: who you ship with, at what rates, under which rules and approvals, who gets told what, which loads are still moving, and the history you may need to explain past freight. The software itself stays behind.
A legacy TMS rarely holds that logic cleanly. After years of use, the carrier master lists carriers nobody tenders anymore, the routing guide reflects a network from two contracts ago, and the real approval limit is whatever the logistics manager signs without asking. Some of the most important rules never entered the TMS at all; they live in a customer SOP, a contract PDF or a senior coordinator's memory.
Leaving is the moment to separate what is current from what merely accumulated. Copying everything forward carries stale rules along; copying nothing forces the team to rebuild decisions under live freight. The checklist below sits between the two: identify each record, name its owner, and confirm it before the first lane moves.
Separate the rules that run the next load from the history that explains past loads
Every item a legacy TMS holds falls into one of three groups, and each group is handled differently.
Rules for the next load. Approved carriers and contacts, rates and contracts where relevant, routing and business rules, approval limits, accessorial rules and customer notification rules. These decide how freight runs after cutover, so they have to be current, owned and written in a form the new workflow can follow.
Loads in motion. Shipments booked before cutover that have not delivered, been POD-confirmed or been paid. They need an owner who finishes them, whichever system they finish in.
History. Past shipments, invoices, claims and rate changes the company wants for audits, disputes and reporting. This is a retention decision, not a workflow input: the company decides what to keep, in what format and for how long.
The exact way the first group moves into the new freight workflow depends on the customer's environment and implementation scope. In some cases the company exports a carrier list or rate sheet; in others the rules are written down fresh during setup. For which rules matter first and how much effort they take, see how much work onboarding an AI logistics agent takes.
Where these records usually hide and who owns them
Most migration surprises come from records that were never fully inside the TMS, so the inventory has to look past it.
Carrier contacts are a typical example. The TMS may hold a carrier's main email, while the dispatcher who actually confirms pickups is saved in a coordinator's phone. Rates split in a similar way: contract rates may sit in a rate table, while fuel tables, minimums and lane exceptions sit in a signed contract that procurement holds.
Routing and business rules are often half configuration and half habit, such as "never use carrier X into this customer's dock" or "always LTL under six pallets." Approval limits may exist in a finance policy but be applied differently in practice. Accessorial rules, such as liftgate, appointment and detention free time, are spread across contracts, customer requirements and the corrections finance made on past invoices. Customer notification rules usually live with customer service.
Ownership follows the decision, not the system: logistics owns carriers and routing, procurement owns contracts, finance owns approval and payment limits, customer service owns notification preferences, and IT owns any exports. Each owner confirms their items; the logistics lead confirms the whole list is complete.
Decision rules for open loads, old history and stale rules
Decide the hard cases before cutover, because each one otherwise lands on whoever happens to be on shift.
- Open loads need an owner. Each shipment booked before cutover gets a named person or workflow responsible for tracking, the POD, the invoice and payment. Late invoices for loads booked in the old system need the same answer.
- History stays a company decision. Historical shipment and invoice data may need to be retained by the company in its own archive or the old system's export. Confirm with finance which records audits and disputes require and how long to keep them.
- Do not carry a rule nobody can explain. If no owner can say why a routing rule or carrier restriction exists, flag it for review instead of moving it.
- Expired rates stay behind. Only rates and contract terms in force at cutover belong in the new workflow; older ones belong in history.
- Inactive carriers do not come back by default. A carrier must be confirmed as approved for the lane before it is used.
- Move lane by lane. Confirm the records for the first lanes, run them, then repeat for the next set.
The legacy TMS migration checklist
Fill one row per item before the first lane moves, and leave the last column blank until the owner signs off.
| Item | Where it usually lives | Who owns it | What to confirm |
|---|---|---|---|
| Approved carriers and contacts | TMS carrier master, coordinator phones and inboxes | Logistics lead | Each carrier is still approved for its lanes, with current dispatch contacts |
| Rates and contracts, where relevant | TMS rate tables, contract PDFs, rate sheets | Procurement or logistics | Rates in force at cutover and their expiry dates |
| Routing and business rules | TMS configuration, routing guide, team habit | Logistics lead | Each rule has a reason and an owner |
| Approval limits | Finance policy, manager practice | Finance and logistics | Written thresholds for booking, rebooking and payment |
| Accessorial rules | Contracts, customer requirements, past invoice corrections | Procurement and finance | Which accessorials are expected per lane or customer |
| Customer notification rules | Customer SOPs, customer service inboxes | Customer service | Who is told about which events, and how |
| Open shipments at cutover | Legacy TMS, carrier emails | Named coordinator | Owner for tracking, POD, invoice and payment of each load |
| Historical information to keep | Legacy TMS, ERP, shared drives | Finance with logistics | What is retained, in what format, where and for how long |
A row without an owner is the first thing to resolve.
How Wilson, by Cartage works from the records you bring
Wilson replaces the TMS for freight execution and connects to the company's ERP or order data flow; it works from the approved carriers, rules, approval limits and contacts the company confirms. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica, and other ERP environments, with the exact connection depending on the customer's data flow and scope.
Wilson tenders to the company's approved carriers first. Cartage can introduce additional capacity, but the company approves any carrier before Wilson uses it, and if no approved carrier accepts, Wilson escalates. It negotiates against the company's rate targets within configured approval limits, and it follows the notification rules the company sets.
The exact way carriers, rates, rules and other information move into the new freight workflow depends on the customer's environment and implementation scope. Customers can configure Wilson themselves or with the Cartage team, and Cartage helps map the first workflow during discovery. Open loads at cutover still need an owner, and historical data may need to be retained by the company. For loads Wilson runs, messages, confirmations and changes are recorded in the shipment history. Most teams start on a few lanes and expand, as described in can an AI logistics agent replace your TMS.
Bring an export or a list of what your TMS holds today to a demo with Cartage and see how Wilson would run your loads from the carriers, rules and records that come with you.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai