Image: Feeling Wired, licensed under CC0 1.0.
The renewal quote arrives with an escalator on it, and somebody asks the obvious question: what would it cost to move? Three weeks later engineering comes back with a number bigger than the increase, and you sign.
That outcome was not decided in the negotiation. It was decided two years earlier, by whoever wrote the provider’s field names into your audit logic.
Leverage at renewal is a property of your code
The Negotiation Experts’ 2026 guide to logistics and supply chain IT licensing calls annual escalation the single largest controllable line in these contracts, and puts the common range at 5 to 10 percent baked into multi-year deals. Its arithmetic on the upper half of that band is worth keeping in view: “Over a five-year term, an uncapped 8% escalator adds nearly 47% to your year-one price by renewal.”
The same guide names the structural problem more plainly than most procurement advice manages. “Once you are single-vendor, your next renewal has no competitive anchor.” Its recommendation is to insist on line-item pricing so you keep the ability to benchmark and re-tender any component independently.
Keeping that ability is the hard part, and it is not a clause. You can write the right into every agreement you sign and still be unable to use it, because using it is an engineering project nobody will approve in the eight weeks before the contract rolls. The vendor knows this. So does your CFO, usually about a week too late.
What a provider swap actually costs
Terminal49 publishes migration guides for customers moving off project44, FourKites, Vizion, OpenTrack, ShipsGo, GoComet, Beacon and SeaRates. They are written by a vendor with every interest in making the move look small. Read the project44 one anyway, because the field-level inventory is honest about what has to change.
Authentication is the trivial part. project44 issues an OAuth2 bearer token from client credentials, Terminal49 uses a static API key sent as a token header, and the guide notes you can delete your refresh logic outright. After that it gets structural. project44 bundles multi-modal legs into a single shipment resource; Terminal49 expects one identifier per tracking request, typed as container, bill of lading or booking number.
The response shape differs too. project44 returns custom JSON, Terminal49 returns JSON:API with data, relationships and included. An ISO equipment code that arrives from one provider as a single value like 45G1 arrives from the other split across separate type, length and height fields. Timestamps come back in UTC with an IANA timezone beside them. The creation call does not return results at all: a tracking request comes back pending, and the answer lands later as tracking_request.succeeded, tracking_request.failed or tracking_request.awaiting_manifest.
Scope is where the migration plan quietly breaks. The guide states that Terminal49 covers ocean and terminal only, and that road, rail, LTL and air tracking have to stay with project44 or go somewhere else. It lists 36 direct ocean carriers plus two on request as of 14 August 2026. What you budgeted as a replacement becomes a second provider you now run in parallel, with two event vocabularies arriving at the same audit.
None of this is a criticism of either company. It is the ordinary shape of two good APIs built by different teams for the same box. The cost only lands on you if their field names reached code that was supposed to be about freight.
The standard moves as well
Waiting for the industry to converge is not a plan either. DCSA published Track and Trace 3.0.0 on 30 September 2026, adding two event types: IoT events covering geolocation, geofence crossings and door status from connected containers, and reefer events covering temperature, setpoints, power status and alarms.
The rollout matters more than the feature list. Version 3.0.0 goes to DCSA members and DCSA+ partners first and reaches the public during the second half of 2027. Anyone on 2.2.0 has a migration to schedule, and DCSA’s own framing is that the changes affect both the information exchanged and how it is shared. The organisation published a migration guide with value mappings because the gap is wide enough to need one.
Count the interface changes across one normal contract cycle. The schema under your container events shifts once because you picked a different vendor, and again because the standard moved beneath the vendor you kept. Code that treats either as a one-off gets rewritten twice.
Pluggable by construction
Vendor neutrality is not a procurement posture or a slide in an architecture review. It is a testable property, and the test takes an afternoon: list every file in your own systems where a provider’s name appears. If the answer is more than a short directory of adapters, you are not neutral, whatever the contract says.
The arrangement that passes is unglamorous. Each provider gets an adapter whose only job is to translate that vendor’s payload into one internal event model: an arrival is an arrival, with a timestamp, a location, a source and a confidence, no matter which API produced it. Chase reads the internal model when detecting exceptions. Penny reads it when deciding whether a detention charge has execution evidence behind it. Neither knows which vendor answered, and neither needs to.
| Question at renewal | Integration written against the provider | Integration written against an interface |
|---|---|---|
| Cost of a switch | Unknown until you scope it, which takes weeks | One adapter, scoped against a published spec |
| Blast radius | Audit rules, exception logic, reporting | The adapter and its tests |
| Running two providers | Two code paths that disagree | Two sources behind one event model |
| Standard version bump | A project | A version of the adapter |
| Negotiating position | Your only alternative is to pay | You can price the alternative honestly |
Chained resolution
The same discipline solves a problem you already have. An invoice arrives carrying a reference that matches nothing in your TMS, and somebody opens four tabs to work out which load it belongs to. We covered why that bottleneck swallows audit capacity in the piece on load resolution.
Behind one interface, resolution runs as an ordered chain. Try the TMS load ID. Then the bill of lading. Then the container number against whichever visibility provider is configured. Then the carrier pro number. Each link is a resolver with the same signature, so adding a provider adds a link and dropping one removes a link. The audit never learns which link answered, only that the load resolved and how confidently.
The same shape buys you corroboration rather than redundancy. Once two visibility providers sit behind one event model, running both is a configuration choice instead of a rebuild, and a disputed timestamp has two independent observations behind it. That is the argument we made in the post on single-source container events, and it is only affordable when the second feed costs an adapter.
What to do next
Three things, none of which require a budget cycle.
- Search your own repositories for your visibility provider’s name. Count the files. That number is your switching cost expressed honestly, and it is the only estimate nobody can talk you out of.
- Read your incumbent’s migration guide for the vendor you would move to, before you need it. Vendors publish these, and they will tell you more about your exposure than a renewal benchmark will.
- Price the switch six months before the contract rolls, not six weeks. Leverage you cannot execute in the time available is not leverage.
Vendor neutrality is cheap to build and expensive to retrofit, which is why it is almost always retrofitted. If you want to see what the adapter boundary looks like in a running audit, book a walkthrough and we will show you the resolution chain on your own lanes.