How do we switch logistics software without disrupting shipping?
Key Takeaways
- Switch lane by lane, not all at once. Start with a few lanes, prove the new process works, then add more.
- Write the rules before moving the loads. Approved carriers, approval limits and exception steps must be set in the new system first.
- Run old and new side by side for a short, fixed time. Long overlaps create double work and confusion about which system is right.
- Move only the data you need to run loads. Carriers, locations, rates, open shipments and the documents for them come first. History can follow.
- Tell carriers, customers and internal teams what changes and when. Most disruption comes from people who didn't know.
- Wilson, by Cartage, is an AI logistics agent that teams usually start on a few lanes and expand from there, with approval limits set by the company.
How do you change logistics software without breaking shipping?
A hypothetical manufacturer decides to replace its shipping software. The plan is to switch everything on the first Monday of the month. On Monday, half the carriers still send tenders back to the old email address. Customer service can't find the status of loads booked the week before. Two rate tables didn't come across, so quotes look wrong. By Wednesday, the team is running both systems, plus a spreadsheet to keep track of which load is in which.
Switch logistics software without disruption by starting with a few lanes, setting the rules before moving any loads, running old and new side by side only briefly, moving the data needed to run loads first and telling carriers and customers exactly what changes. A gradual switch limits how much can go wrong at once. If something breaks on three lanes, it can be fixed before it reaches thirty.
The software is rarely the hardest part. The hard parts are the habits, the data and the people outside the company who send emails to the old address. A good switch plan spends as much time on those as on the system itself.
Why "big bang" switches go wrong
Changing everything on one day puts every risk on the same day: missing data, wrong rules, carriers who didn't get the message, team members who haven't learned the new screens, connections to the ERP that haven't been tested with real orders. Any one of those can delay loads. All of them together can stop shipping for days. A staged switch spreads those risks out and lets the team learn on a manageable share of loads.
What "without disruption" really means
No switch is invisible. The goal is that customers and carriers see no difference in service: loads are booked on time, trucks show up, deliveries happen, invoices are paid on terms. Internally, the team will feel the change. That's expected. What matters is that the change is felt by the team, not by the customer.
What's the step-by-step plan for switching logistics software?
Pick the first lanes, set the rules, load the data, connect the systems, run side by side briefly, then expand lane by lane. Each step has a clear done condition before the next one starts.
Step 1: Map how shipping works today
Before touching the new system, write down how each workflow runs now: quote, book, pickup, track, POD and invoice. Note who does each step, which carriers serve which lanes, what approval limits exist and how exceptions are handled. If your team has written SOPs, start from them. If not, this is a good time to write them; see how to write a shipping SOP your team will actually use.
Step 2: Choose the first lanes
Pick a few lanes that are frequent enough to test the process within the first weeks, but not so critical that a mistake would hurt a key customer. Good first lanes often have steady volume, a small number of familiar carriers and simple delivery requirements. Avoid starting with your most demanding retail customer, your most complex multi-stop load or your peak week.
Step 3: Set the rules
Enter the rules the new system will follow before any load runs: approved carriers per lane, rate targets, approval limits for rates and payments, accessorials that are pre-approved, who gets told about exceptions and how. Rules set up front prevent the most common early problem, which is the new system doing something the old process would never have done.
Step 4: Move the data needed to run loads
Load carrier details, ship-from and ship-to locations, contract rates, fuel tables and customer delivery requirements for the first lanes. Leave historical data for later unless the team needs it to work. The data section below lists what to move and when.
Step 5: Connect the ERP and test with real orders
Connect the new system to the ERP and test with real orders on the first lanes. Check that orders come through with the right addresses, weights and references, and that whatever needs to flow back, such as shipped status, tracking numbers or freight cost, arrives in the right place.
Step 6: Run side by side for a short period
For the first lanes, run the new system while keeping the old one available, for a fixed period agreed in advance. The rules for doing this well are below.
Step 7: Review and expand
At the end of the side-by-side period, check the success measures. If they're met, retire the old system for those lanes and add the next group. If not, fix what's wrong before expanding. Most teams expand in a few waves until all lanes are on the new system.
How to run old and new systems side by side
Run them in parallel for a short, fixed period, with a clear rule for which system owns each load. Parallel running is a safety net, not a permanent state. The longer it lasts, the more double work and confusion it creates.
One load, one system
The most important rule: each load lives in exactly one system. Loads on the first lanes are booked, tracked and paid in the new system. Everything else stays in the old one. Never book a load in both. Double entry is where errors and duplicate tenders come from.
What "side by side" should mean
During the overlap, the old system stays available for:
- Loads that were booked in it before the switch, until they're delivered and paid.
- Lanes that haven't moved yet.
- Looking up history and documents.
The new system handles all new loads on the first lanes from day one.
How long to overlap
Set the end date before you start, long enough to cover a full cycle of loads on the first lanes, from booking through delivery, POD and invoice payment. For most lanes that means a few weeks rather than months. Carrier invoices often arrive weeks after delivery, so the old system may need to stay open for payments on old loads a little longer than for new bookings.
Open loads at the switch
Loads that are in transit when a lane switches should finish in the system that booked them. Moving a load mid-transit risks losing its documents, its messages with the carrier and its invoice match. Draw the line by booking date: anything booked before the switch stays in the old system until it's paid.
Daily check-ins during the overlap
For the first lanes, hold a short daily check: what booked, what's in transit, what went wrong and what needs fixing. Ten minutes a day during the first weeks catches problems while they're small.
What data needs to move, and what should carriers and customers hear?
Move what you need to run loads first, then history; tell every outside party what changes, when and whom to contact. Data and communication are where most switches stumble.
What data to move, and when
| Data | Move before first load? | Notes |
|---|---|---|
| Approved carriers and contacts | Yes | Include email addresses, phone numbers and dispatch contacts for each lane |
| Ship-from and ship-to locations | Yes, for the first lanes | Dock hours, appointment rules, liftgate needs |
| Contract rates and fuel tables | Yes, for the first lanes | Check each table against a recent invoice |
| Customer delivery requirements | Yes, for the first lanes | Appointments, labeling, routing rules |
| Approval limits and rules | Yes | Rates, payments, accessorials, exceptions |
| Open loads | No | Let them finish in the old system |
| Document templates | Yes | BOL, labels, packing slips |
| Shipment history | Later, if needed | Reporting and lane analysis; keep the old system readable meanwhile |
| Historical documents | Later, or keep in archive | BOLs and PODs for past loads; check retention rules with finance and legal |
Test the documents, not just the data
Before the first load, generate a BOL, a set of pallet labels and a packing slip for a real order on each first lane, and compare them with what the warehouse prints today. Check addresses, references, freight class, piece counts and any customer-specific fields. Then check a rate confirmation against a recent one from the same carrier. Documents are what drivers, docks and customers actually see, so a wrong field on a BOL causes more trouble on day one than a missing report.
Keep the ERP as the place orders start
Whatever system runs freight, orders still start in the ERP. During a switch, keep that the same. The new system should read orders from the ERP for the first lanes, and the old one should keep reading them for every other lane. Decide in advance how each order is routed, usually by lane, ship-from location or customer, so nobody has to decide load by load which system to use.
Clean data before moving it
A switch is a good moment to remove carriers you no longer use, fix duplicate locations and check that rates are current. Moving bad data into a new system just gives you the same problems with a new screen. Spend a few hours on the first lanes' data before loading it.
What carriers need to hear
Carriers need to know where tenders, rate confirmations and invoices will come from and where to send replies. Send a short note to each carrier on the first lanes before the switch:
- The date the change starts and which lanes it covers.
- Any new email address, EDI setup or portal they'll receive tenders through.
- Where to send invoices and PODs.
- A contact for questions during the change.
- Whether anything about your rates, payment terms or requirements is changing. Usually, nothing is.
If you publish carrier instructions, update them at the same time; see how to write a routing guide for carriers and suppliers.
What customers need to hear
Most customers don't need to know you changed software. They need to know if anything they see changes: the format of shipping notifications, the sender of delivery updates or the way they request documents. If any of those change, tell them shortly before, in one short message. If nothing they see changes, say nothing.
What internal teams need to hear
Customer service, accounts payable, the warehouse and sales each need to know where to look for status, documents and invoices for loads on the new lanes. Give each team a one-page note: what changes for them, from which date, and whom to ask. Accounts payable needs special attention, because during the overlap it will receive invoices for loads in both systems.
What mistakes should we avoid when switching logistics software?
Most switches go wrong for predictable reasons: everything at once, no rules up front, a long overlap or people who weren't told. Each one is avoidable.
Common mistakes
- Switching all lanes on one day. Start with a few lanes and expand.
- Starting during peak season. Pick a quieter period. If peak is approaching, see how to get logistics ready for peak season and plan the switch around it.
- Moving loads before setting rules. Approved carriers, approval limits and exception steps come first.
- Moving every piece of history first. Move what you need to run loads; keep the old system readable for history.
- Booking loads in both systems. One load, one system.
- An open-ended overlap. Set the end date before starting.
- Forgetting accounts payable. Invoices for old loads will keep arriving in the old process for weeks.
- Not telling carriers. Replies sent to an old address mean missed tenders and late pickups.
- Training too early or too late. Train the team just before their lanes switch, on real loads, not weeks ahead on a demo.
- No owner. One person should own the switch plan, the daily check-ins and the decision to expand.
Decision rules for expanding
Expand to the next group of lanes when:
- Loads on the current lanes book, pick up and deliver on time at least as reliably as before.
- PODs are filed and invoices are matched without the team falling back on the old system.
- Exceptions on the new lanes were handled within the rules, or the rules were updated.
- The team says it's ready, and customer service can find what it needs.
Pause the expansion when any of these slip, fix the cause and then continue.
When to stop and roll back a lane
If a lane has repeated service failures caused by the switch, such as missed tenders or wrong rates, move that lane back to the old process while you fix the cause. A temporary step back on one lane is far cheaper than a lost customer.
Plan for the people, not just the system
Coordinators who have used the old software for years know its shortcuts and its workarounds. Some will worry that the new system makes their knowledge less useful. Involve them early: ask them to help choose the first lanes, write the rules and review exceptions. The people who know where the old process breaks are the best guides to setting up the new one, and they'll trust a system they helped shape.
What to do with the old system
Once every lane has moved and the last old invoices are paid, keep read access to the old system, or an export of its records, for as long as finance and legal need the history. Then retire it. Paying for two systems indefinitely is a common, avoidable cost.
How do you measure whether the switch is working?
Measure the same things before and after: on-time pickup and delivery, time to book, POD filing, invoice match rate and exceptions. Measure the old process on the first lanes before the switch, so you have something to compare with.
Success measures
| Measure | What it tells you | Compare with |
|---|---|---|
| On-time pickup | Carriers are getting and accepting tenders correctly | Same lanes, before the switch |
| On-time delivery | Service to customers hasn't slipped | Same lanes, before the switch |
| Time from order release to booked load | The booking process is as fast or faster | Same lanes, before the switch |
| Loads booked with written acceptance and rate confirmation | Booking rules are followed | Target: every load |
| PODs filed within your target | Documents are flowing | Same lanes, before the switch |
| Invoices matched on first check | Rates and rules were set up correctly | Same lanes, before the switch |
| Exceptions handled within the rules | The exception steps work | Count and review each one |
| Questions from customer service to logistics | Status is visible to other teams | Same period, before the switch |
| Team time spent on the new lanes | The switch is reducing work, not adding it | Team estimate, before and after |
Look at exceptions one by one
In the first weeks, review every exception on the new lanes: what happened, how it was handled and whether the rules need a change. Early exceptions are the best source of rule fixes. Later, a weekly review is enough.
Ask the people who do the work
Numbers show the outcome. The team shows the cause. Ask coordinators, customer service and accounts payable each week what's harder and what's easier. Small complaints, such as a missing field or a confusing label, are cheap to fix early and expensive to ignore.
A simple timeline to plan around
- Before the first load: map current workflows, choose lanes, set rules, load data, connect the ERP, brief carriers and teams.
- First lanes live: daily check-ins, every exception reviewed, old system handles old loads.
- End of the overlap: check success measures, retire the old system for those lanes.
- Next waves: add lanes in groups, repeat the checks.
- After the last lane: final invoices paid in the old system, archive history, retire it.
If you're moving freight in-house from an outside provider at the same time, the order of steps is similar; see where to start when bringing freight in-house from a 3PL.
How does Wilson, by Cartage, fit into a switch from existing logistics software?
Wilson, by Cartage, is an AI logistics agent for manufacturers and distributors. Traditional logistics software gives teams information. Wilson executes the work required to move shipments forward. Wilson replaces the TMS for freight execution and connects to the company's ERP, and teams use Wilson's dashboard and records like a TMS.
Lane by lane, with rules first
Cartage doesn't run pilots; most customers start Wilson on a few lanes and expand from there. Timing depends on scope. The company sets the rules first: Wilson books only carriers the company has approved, negotiates toward the company's rate targets within approval limits and sends rates outside the limits to the logistics team. Cartage can suggest additional carrier capacity, but the company approves each carrier before Wilson uses it.
Teams start with assisted execution. Routine actions can run automatically within the company's rules as the workflow is proven. Every message, confirmation and change is kept in the shipment's change history, which makes the daily and weekly reviews during a switch straightforward.
What Wilson does on each load
On the lanes it runs, Wilson requests quotes from approved carriers and compares them on total cost, tenders and books with written acceptance and a rate confirmation, schedules pickups and tracks each load with the best source available. It handles exceptions such as missed pickups, cancellations and delays: it contacts the carrier, tells the team, tells the customer if configured and starts rebooking from the approved carrier list, automatically within the rules or after approval. It generates rate confirmations, bills of lading, packing slips and pallet labels, requests and files PODs, audits each carrier invoice against the rate confirmation and POD, and pays carriers from the Wilson Wallet. Payments above the approval limits or outside the rules wait for a person.
Connections to keep shipping steady
Wilson works with carriers by email, API, EDI and phone where configured, with the team in Slack, Microsoft Teams or email, and with customers by email or SMS where configured. 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 covers LTL, FTL, ocean, drayage, parcel and cross-border freight. It does not do customs clearance and is not a freight broker.
Wilson can produce carrier-performance and lane-rate reports on request from the loads it runs, which helps compare the new lanes with how they ran before.
Pricing
Wilson is free on Wilson's network: the shipper pays the freight rate and nothing on top. When a shipper keeps its own carriers, the fee is 2% to 0.5% of what Wilson pays them, falling with volume. There are no seat fees, no setup cost and no contract.
FAQs
How do we switch logistics software without disrupting shipping?
Start with a few lanes, set the rules before moving any loads, run old and new side by side for a short fixed period, move the data needed to run loads first and tell carriers, customers and internal teams what changes. With Wilson, by Cartage, an AI logistics agent, most customers start on a few lanes and expand from there.
How long should we run the old and new systems in parallel?
Long enough to cover one full cycle on the first lanes, from booking through delivery, POD and invoice payment, which usually means weeks rather than months. Set the end date before you start. Keep the old system open a little longer for invoices on loads booked there.
What should happen to loads in transit when we switch?
Let them finish in the system that booked them. Moving a load mid-transit risks losing its documents, messages and invoice match. Draw the line by booking date.
Which lanes should we switch first?
Lanes with steady volume, a few familiar carriers and simple delivery requirements. Avoid starting with your most demanding customer, your most complex loads or your busiest season.
What data do we need to move to new logistics software?
Before the first load: approved carriers and contacts, locations, contract rates, fuel tables, customer delivery requirements, approval rules and document templates for the first lanes. History and past documents can move later.
Do we need to tell carriers we're changing software?
Yes, if anything they see changes, such as where tenders come from or where to send invoices and PODs. Send each carrier a short note with the date, the lanes affected, the new contact points and whom to ask.
Do customers need to know about a logistics software change?
Only if something they see changes, like the sender or format of shipping updates. If nothing visible changes, there's no need to announce it.
How do we know the new system is working?
Compare on-time pickup and delivery, time to book, POD filing, invoice match rates and exceptions on the new lanes with the same lanes before the switch. Ask the team weekly what's easier and what's harder.
When should we pause a rollout?
Pause when service slips on the new lanes, when the team falls back on the old system or when exceptions aren't handled within the rules. Fix the cause before adding more lanes.
Who should own a logistics software switch?
One person, usually the logistics manager, should own the plan, run the daily check-ins and decide when to expand. IT and finance should be involved in the ERP connection and invoice process, but a single owner keeps decisions fast.
Does Wilson require a long setup before the first load?
Timing depends on scope. There is no setup cost, and most teams start Wilson on a few lanes, set approval limits and approved carriers first and expand from there.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai