Many shipping lines and NVOCCs still run on a system installed decades ago that only one or two people fully understand. Replacing it is less risky than keeping it forever, but only if the move is planned around your data: what exists, what must move, what must stay retrievable for regulators, and how to switch over without missing a Customs filing or an invoice.
The software itself is rarely the problem in a failed migration. The problems are usually data that nobody knew was there, balances that do not match after conversion, and a go-live date that lands in the middle of a vessel closing. The result is a team running two systems at once, retyping shipments, and losing trust in the new system before it has a chance.
A legacy system also holds knowledge that is not written down anywhere: special rating rules for one customer, a report the accounting department depends on, an EDI file a terminal still expects. Finding those dependencies early is most of the work.
Start by listing every kind of data the current system holds and deciding how each will be handled. The table below is a typical starting point for a carrier or NVOCC.
| Data | Typical approach | Watch out for |
|---|---|---|
| Customers, vendors, agents, truckers | Migrate after cleanup | Duplicates, old addresses, missing tax or FMC reference numbers |
| Tariffs, service contracts, NRAs | Migrate current ones, archive expired | Rates stored as free text or in side spreadsheets |
| Equipment master and current status | Migrate with last known event | Containers in the field with no recent move |
| Open bookings and bills of lading | Migrate, or finish in the old system | Shipments half-filed with Customs |
| Historical bills of lading and documents | Migrate or keep in a readable archive | Attachments and printed forms that are not in the database |
| Open receivables and payables | Migrate as open items by invoice | Totals that do not tie to the general ledger |
| General ledger balances | Migrate opening balances at a period end | Unposted or suspense entries |
| EDI partner setups and reports | Rebuild and retest | Formats only the old vendor understood |
Conversion is the best opportunity you will ever have to fix master data. Merge duplicate customers and vendors, retire contacts nobody has used in years, standardize port and commodity codes and confirm reference numbers such as FMC organization numbers and tax IDs.
Validate container numbers too. Every ISO 6346 container number ends in a check digit that validates the owner code and serial number, so numbers that fail the check can be found and corrected before they enter the new system. Our guide to container tracking for small carriers explains how the number is built.
Agree on who owns each cleanup task and a date by which it must be finished. Cleanup that is left for after go-live rarely happens.
Not everything has to move into the new system, but everything you are required to keep has to stay retrievable. Two sets of rules are worth reading with your counsel before you decide what to archive:
In practice, that means the old database should not simply be switched off. Either migrate the history, or keep a read-only copy with a documented way to search and print it, and do not destroy originals until your customs broker or counsel confirms that you can.
The safest cutover point is a natural boundary in your business: the start of an accounting period and, ideally, a quiet point in your sailing schedule. A few rules keep the switch clean:
Customs deadlines do not pause for a software project. Under 19 CFR 4.7(b)(2), CBP must receive the electronic cargo declaration 24 hours before the cargo is laden at the foreign port, so the new system must be able to file before the old one stops. Confirm that the new system is set up to transmit through a CBP-approved system, test with real bills of lading and agree with your vendor on who handles CBP responses during the first sailings.
Do the same for every EDI trading partner: terminals, truckers, carriers and foreign customs systems. List each interface, the format it uses and a contact on the partner side, then schedule tests well before go-live. CBP's ACE Import Manifest Documentation is the reference for the ocean manifest messages your new system must handle.
Choosing the right partner makes every step easier. If you are still comparing systems, start with our shipping line software checklist. GDZ acts as a system integrator for GDZ-ISIS, tailoring each installation to the company that runs it, so the way you work can be discussed before anything is converted.
Inventory every type of data, clean master data, decide what migrates and what stays in a readable archive, convert accounting at a period end, confirm Customs filing and EDI work in the new system, then go live at a defined boundary with the old system set to read-only.
Not necessarily, but records you are required to keep must remain retrievable. 46 CFR 515.33 requires NVOCC records to be readily available to the FMC, and 19 CFR 163.4 sets a general five-year retention period for records CBP requires. Confirm with your counsel.
At an accounting period end and, ideally, a quiet point in your sailing schedule. Each shipment should live in only one system, and accounting balances should be tied out before new transactions are posted.
Make sure the new system can transmit to CBP before the old one stops, test with real bills of lading, and agree who monitors CBP responses during the first sailings. The 24-hour advance cargo declaration rule in 19 CFR 4.7 still applies on go-live day.
A short, defined parallel run can build confidence by comparing rated bills and invoices on the same shipments. A long open-ended one usually means double work and confusion about which system is right.