Broker guides

Freight Broker TMS Migration Checklist: Export, Cutover, and Reconcile Without Losing the Record

freight broker TMS migration checklist

Switching a freight broker TMS is not complete when users can log in. It is complete when the team can run today’s freight, retrieve yesterday’s evidence, and explain tomorrow’s invoice without guessing which system is right.

Migration is an operations-control project, not just a file import. The practical risk is a quiet mismatch: a dropped carrier identifier, shifted stop time, detached document, or stranded payable.

Use this checklist to define what moves, what stays in a controlled archive, how open work crosses the cutover, and what must reconcile before the old system becomes read-only.

> Product boundary: This is a vendor-neutral migration method. It does not claim that ServeOps or any other TMS imports, exports, maps, stores, secures, reconciles, or retains a particular field or file. Confirm scope, format, fees, timing, access, and support in writing with the systems you are evaluating.

<!-- Visual placement: /content/broker-guides/freight-broker-tms-migration-checklist/01-migration-control-map.svg -->

1. Start with a record inventory, not an “export all” button

Name one business owner for each data family. That person decides whether the source is authoritative, whether the record is active, and what evidence proves the migration succeeded.

Build an inventory across five groups:

  1. Master data: customers, billing entities, carriers, facilities, contacts, lanes, service types, users, roles, payment terms, and reference tables.
  2. Open operations: quoted or booked loads, active stops, current carrier assignments, status, appointments, notes, tasks, and unresolved exceptions.
  3. Financial work: customer charges, carrier costs, accessorials, invoice state, payable state, payment dates, credits, adjustments, and accounting references.
  4. Documents and communications: rate confirmations, bills of lading, proofs of delivery, invoices, notices, supporting receipts, email evidence, and the relationship between each file and its load.
  5. Historical records: closed transactions, prior versions, audit history, reports, exports, and records retained under the brokerage’s policy.

Do not assume that “customer,” “carrier,” or “load” means the same thing in two systems. Add the source field, destination field, data type, required/optional status, transformation rule, owner, sample value, and acceptance rule to the map. A carrier MC number stored as free text, for example, may not land cleanly in a destination field that expects digits only.

2. Preserve the broker transaction record

The current text of 49 CFR 371.3 requires a broker to keep a record of each transaction. It identifies information the record must show, including consignor details, the originating motor carrier’s name, address, and registration number, the bill of lading or freight bill number, specified compensation and freight-charge information, and the date of payment to the carrier. It sets a three-year retention period and gives each party to the brokered transaction a right to review the required record.

That public rule is a records obligation; it does not certify a TMS, export, archive, or migration process as compliant. Map every required element to the place it will remain retrievable after cutover. If some history will stay in the old system, document who retains access, for how long, at what cost, and how the team will respond to a record request.

Keep the exported source files in a controlled archive before transformation. CISA’s current Back Up Business Data guidance recommends inventorying important information, storing backups separately from primary systems, and testing recovery. A backup you have never opened is only a hope.

3. Decide what migrates, archives, or gets rebuilt

For each data set, choose one disposition:

  • Migrate: needed for active operations or frequent retrieval in the new system.
  • Archive: must remain available but does not need to be loaded into daily workflow.
  • Rebuild: safer to create cleanly in the destination, such as roles, templates, or current approval rules.
  • Dispose under policy: duplicate, expired, or unnecessary material approved for disposal by the proper owner.

Do not use migration as an excuse to move every stale contact, expired rate, inactive user, or duplicate carrier record. The FTC’s Start with Security advises businesses to know what information they hold, keep only what is essential, and restrict access according to legitimate need. Apply the brokerage’s approved retention, legal, contractual, and security rules before deleting anything.

4. Run two rehearsals before the real cutover

Use sanitized or properly authorized data for the first rehearsal. Import a representative sample rather than the easiest records:

  • one ordinary closed load;
  • one multi-stop load;
  • one load with a carrier change;
  • one revised customer or carrier rate;
  • one accessorial with supporting evidence;
  • one open load;
  • one invoiced but unpaid customer transaction;
  • one carrier payable not yet paid;
  • one record with several documents and notes.

Reconcile both counts and meaning. Matching 10,000 load rows is not enough if documents are detached or customer and carrier amounts are reversed. Open the destination records as an operations user and as a finance reviewer. Search by customer reference, carrier identifier, bill of lading or freight bill number, load number, and date—not only the destination’s new internal ID.

The second rehearsal should use the planned production sequence and owners. Time each step, record defects, and prove that the rollback materials can be accessed.

5. Freeze only what must be frozen

Choose a clear cutoff timestamp and timezone. Then document which system owns each type of change before, during, and after that moment.

Open freight is the hardest part because it continues to move while data moves. Use a cutover register with one row per open load and these minimum checks:

  • source and destination load IDs;
  • current customer, carrier, stops, appointments, and status;
  • current sell and buy amounts;
  • unresolved accessorials or exceptions;
  • required documents present or missing;
  • invoice and payable state;
  • last source update and first destination update;
  • named operations and finance reviewers;
  • final decision: migrated, completed in source, or manually rebuilt.

Avoid uncontrolled dual entry. If both systems remain writable, state exactly which one is authoritative for every workflow and how conflicts will be resolved.

6. Reconcile the cutover in three passes

<!-- Visual placement: /content/broker-guides/freight-broker-tms-migration-checklist/02-cutover-reconciliation-board.svg -->

Pass one: population

Compare record counts by data family and disposition. Explain every difference: deliberately archived, merged duplicate, failed import, or still pending. Record counts alone do not prove accuracy, but unexplained differences are a stop signal.

Pass two: field and relationship checks

Sample high-risk records and compare values, not screenshots. Check identifiers, dates and timezones, money, status, user ownership, document links, and relationships among customer, carrier, stops, invoice, and payable. Confirm that users can open exported or archived files outside the source system.

Pass three: operational proof

Have the actual roles finish representative work in the destination: update an active load, handle a carrier change, add approved supporting evidence, prepare customer billing, review carrier payable information, and retrieve a historical transaction. Record each workaround and every item that still depends on the old system.

7. Set go/no-go and rollback rules before go-live

Write the conditions that stop the cutover. Examples include an unexplained difference in open-load counts, incorrect financial amounts, missing required documents, failed user access, or inability to retrieve required historical records. Assign one person with authority to call no-go.

Rollback is not “we still have the old login.” It should identify the authoritative system, the latest recoverable export, the changes made after the cutoff, how those changes will be replayed, who tells users which system to use, and when the next decision occurs.

Keep the old environment read-only until operations, finance, records, security, and leadership approve decommissioning. Before cancellation, verify contract terms, export availability, post-cancellation access, retention or deletion timing, support dependencies, and the brokerage’s own archive-recovery test.

A migration is done when the evidence works

The cleanest cutover is boring: open loads have owners, differences have explanations, financial samples tie out, and a second person can retrieve the record.

Public facts versus verified ServeOps functionality

Public facts used here: the current eCFR text describes broker transaction-record content, retention, and review rights; CISA recommends inventorying, separately backing up, and recovery-testing critical business data; FTC guidance addresses data minimization and need-based access. None of these sources evaluates ServeOps.

Verified ServeOps offer only: 60-day free trial; card collected upfront; no charge for 60 days; cancel anytime; then $49 per seat/month or $490 per seat/year.

No ServeOps migration, import, export, archive, backup, security, mapping, onboarding, integration, or reconciliation functionality is claimed here. If ServeOps is on your shortlist, verify each required workflow and data field directly before moving production records.

Start a 60-day ServeOps trial with synthetic or properly authorized data, then make the migration decision from documented evidence.

Sources