We help ports choose Terminal Operating Systems. Here's what the procurement process gets wrong

A TOS selection is a 10-year infrastructure decision that touches every vessel call, yard move, gate transaction, and billing cycle at a port. It's also one of the most consistently mismanaged procurement processes in any capital-intensive industry.

After supporting TOS evaluations and deployments across container, bulk, and multipurpose terminals, we keep seeing the same failure patterns repeat. This is the honest breakdown.

The demo problem

Most TOS evaluations are structured around vendor demonstrations. The buyer establishes a shortlist, invites vendors to present, watches polished demos, and scores them on a matrix.

The demos are always impressive. That's the problem.

A well-configured sandbox environment, populated with synthetic data, running a pre-rehearsed workflow, tells you almost nothing about how the platform will behave with your EDI variant from a specific shipping line, your legacy crane PLC interface, or your specific customs authority connection.

The correct structure: Establish evaluation criteria before seeing any demo. Then use the demo only to verify claims against criteria you've already defined. Watching a demo before setting criteria is the fastest route to selecting the vendor with the best sales team, not the best platform.

What "integration depth" actually means

Every TOS vendor will tell you they have broad integration capability. The question is: integrated by whom, and maintained by whom?

There are two integration models:

Vendor-owned connectors — the vendor maintains native connections to customs EDI systems, shipping line APIs, ERP platforms, port community systems. Updates to these connectors happen in the vendor's release cycle. Breaking changes are their problem.

Marketplace connectors — the vendor's core platform is solid, but most integrations are delivered by a certified partner ecosystem. The terminal pays for the core licence and then separately engages integrators for each connection. The vendor is not accountable for integration failures.

Neither model is wrong. But a vendor presenting marketplace connectors as "native integrations" is withholding material information from your procurement team. The question to ask in writing: "Which integrations in your connector library are maintained in-house, and which are delivered by third-party system integrators?"

The on-premise vs cloud decision is not primarily a cost decision

It's frequently framed as capex vs opex. That's one dimension.

The more important dimensions:

Data residency. Port authorities in India, Indonesia, Saudi Arabia, and Brazil operate under data localisation requirements. A cloud-native TOS selected without a regulatory review creates a compliance remediation problem, not just a technical one. This needs a legal review before any cloud TOS shortlisting.

Latency. Real-time crane work instruction delivery requires sub-100ms response times. A cloud-hosted TOS serving yard control systems via WAN introduces latency that causes crane sequencing errors at high-throughput terminals. The architecture that resolves this is edge computing for real-time operations plus cloud for analytics — what "hybrid TOS" actually means in practice.

Update control. A crane scheduling algorithm update pushed to production without terminal-specific testing has caused operational disruptions at multiple port deployments in the past two years. Cloud TOS platforms require contractual staging environment access — the ability to receive, test, and accept/reject updates before they reach production. Most vendors don't offer this by default.

The hidden costs that sink five-year business cases

Most TOS proposals present licence cost plus a vague "implementation fee." The actual cost picture:

Data migration: 15–25% of licence cost. Moving 10+ years of container history, vessel records, and customer data from a legacy TOS to a new platform takes 4–8 months of specialist data engineering work. This is almost never a line item in the initial proposal.

Workforce change management: 10–20% of year-one cost. A TOS rollout touches every operational team. Planners, crane operators, gate supervisors, and finance staff all need new workflows. Terminals that skip structured change management see 20–40% productivity drops in the first three months post-go-live, regardless of platform quality.

Custom integration development: $150K–$500K. Legacy crane PLC interfaces, non-standard EDI variants from specific shipping lines, and bespoke port community system connections all require custom integration work. This doesn't appear in standard proposals because vendors haven't discovered the scope.

Support tier escalation. Most contracts include hypercare support for 6–12 months post-go-live, then transition to a standard ticket-queue SLA model. The cost of returning to premium support in year two is a budget item that procurement teams rarely price in advance.

The 5 questions that cut through any TOS shortlist process

These are the questions we use in every TOS vendor shortlist meeting:

"Show us a live terminal operation on your platform — not a configured demo environment."
A vendor who can arrange this has live deployments with confident customers. A vendor who can only show sandbox environments is telling you something.
"What were the top three reasons your last three implementations ran over timeline or budget?"
Every implementation has had challenges. A vendor who claims otherwise hasn't done enough implementations. A vendor who gives honest answers is giving you the most useful information in the evaluation.
"Which of our specific integration requirements do you rate as technically involved, and why?"
This tests whether they've actually reviewed your system landscape, and whether they'll be honest about complexity before contract signature.
"What happens to our system if throughput doubles in three years?"
Scalability architecture is a 10-year question. A vague answer about "horizontal scaling" without specifics about how the platform has actually been scaled in production is a flag.
"Who specifically will lead our implementation, and how many concurrent TOS deployments is that person managing today?"
Implementation quality is almost entirely a function of the team assigned to your programme. A named, available implementation lead is a green flag. "Resource to be confirmed post-award" is a red flag.

What we documented

We put this into a full TOS buyer's guide covering the 7 non-negotiable evaluation criteria, the on-premise vs cloud vs hybrid decision framework, a live platform comparison table, the vendor red flag list, hidden cost analysis, and a 4-step internal business case structure.

Full guide: https://theintechgroup.com/blog/tos-buyers-guide-terminal-operating-system/

Has anyone here been involved in a TOS selection or port technology procurement process? What was the evaluation failure mode that caused the most downstream pain?

We see the data migration underscoping and the integration discovery gap most frequently. Curious whether others have run into the update control problem with cloud TOS deployments, or the PLC interface gap at terminals with older crane fleets.

INTECH Group — port and terminal technology, TOS selection and deployment, digital transformation for ports and logistics operations. India / USA / UAE / Hong Kong. Happy to discuss any specific evaluation question in the comments.