Magellan
TMS migration: map what each status means before moving data
Define status meanings, field conversions and exception handling before a TMS migration, then reconcile relationships and business decisions.
In the old system, “complete” means the driver delivered. In the new system, “complete” means the invoice has been issued. The migration transfers every record successfully, and the first report still tells the wrong story.
The imported data kept its rows but changed what employees could conclude from them. This is a difficult migration failure because the data can look tidy, the row counts can match and employees can spend weeks discovering that familiar words now trigger different decisions. Before moving the records, establish what the business means by the fields it plans to trust.
For each important status, record the event it represents, the evidence required, the person or process allowed to set it and what happens next. Include whether the status can be reversed and how that correction is recorded.
Use real questions. Does “assigned” mean a dispatcher selected a driver, the driver acknowledged the load or the assignment passed the relevant release checks? Does “paid” mean a payment notification arrived or the amount was reconciled through the accounting process?
These are operational mapping recommendations. NIST SP 800-128 (https://csrc.nist.gov/pubs/sp/800/128/upd1/final) provides broader context for controlling system changes; it does not prescribe trucking statuses. Define those meanings through the approved business process.
A field called delivery date may contain a planned appointment in one system and an actual event in another. A matching name is not enough. Identify what the value represents, its time zone, its source and whether historical records used it consistently.
Build a mapping that states the old meaning, new meaning, transformation and verification. Where no reliable conversion exists, preserve the uncertainty explicitly. Do not manufacture precision by inserting a default timestamp simply because the destination requires a date.
Test blanks as well as populated values. A missing amount can mean unknown, not applicable or zero; those are different states. If the new system turns all three into zero, a technically successful import can change financial reports and employee decisions without an obvious error message.
Do not test only clean, recently completed loads. Include cancelled loads, reopened jobs, partial payments, disputed charges, duplicate customers, changed equipment and records missing key documents. Those are the cases most likely to expose hidden assumptions.
Name the person responsible for each unresolved mapping decision. An implementation specialist should not decide what a disputed commercial status means merely because the conversion script needs a value. Route the decision to the person responsible for the workflow.
Keep an exception log with the affected record, issue, decision and evidence. If the business chooses to retain an old value without converting it, explain how employees will recognize that limitation. A known, visible gap is easier to manage than a guessed value presented as settled history.
Consider a hypothetical migration of 600 loads carrying the legacy value “Complete.” The old team used that label for several stages. The new workflow distinguishes delivery reports, document review, invoicing and payment reconciliation. Three sample records show why one blanket conversion would be misleading:
1. Load 6001: Complete → Delivery reported; documents pending. The source is a driver call logged at 14:20. There is no delivery receipt in the source file. Preserve the call reference, leave document review unresolved and assign collection of the receipt to the document team. Do not turn the call into an approved proof of delivery.
2. Load 6002: Complete → Invoice issued; payment unreconciled. The source file contains a reviewed delivery receipt and invoice INV-6002. It has no matched payment entry. Preserve those document links and route the outstanding payment check to accounting. An issued invoice does not establish receipt of funds.
3. Load 6003: Complete → Legacy status; review required. The record has no reliable delivery, invoice or payment evidence. Retain the original label in the migration history, leave the destination milestones unconfirmed and assign a source-record search. No event date or settled payment is supplied merely to fill a required field.
These destination labels are choices for this example, not standard TMS fields. Each mapping records the old value, new value, supporting evidence and unresolved work. Apply the approved definitions to the remaining records, recording exceptions rather than promoting every legacy “Complete” entry into a final state. The result may expose unfinished work that the old label concealed.
Count records, but also test whether customers, loads, equipment, documents and financial entries remain connected correctly. A thousand imported documents are not useful if they are attached to the wrong load.
For amounts, use the approved accounting definitions and appropriate reconciliation. Check totals within meaningful groups and inspect individual exceptions. A matching grand total can conceal one overstated customer and another understated customer.
Verify representative workflows with authorized business users in a safe test environment. Can billing find the controlling documents? Can dispatch identify a current restriction? Can a manager explain the same sample load before and after migration? The test is whether the business meaning survives, not merely whether the new screen can open the record.
Define when the old system stops accepting ordinary changes, how work during the transition is recorded and who authorizes the new system as the operating source. If the plan uses a limited parallel period, establish which system may create or change each type of record.
Topics
- TMS
- Data migration
- Status definitions
- Change control