The Systems Problem Most TOS Evaluations Get Wrong
Port IT and systems teams spend the majority of a TOS evaluation process watching vendor demos. The demos are polished. The feature lists are long. The integration slides are impressive.
Then go-live happens. Custom middleware breaks. The crane scheduling API doesn't match what was promised. The EDI connection to the national customs system requires a third-party integrator the vendor forgot to mention.
This post is written for the technical side of a TOS selection team — the people who will own the integration layer, manage the deployment, and live with the architectural decision for the next decade. Here's what actually matters at that level.
The Integration Architecture Question That Shortlists Vendors Immediately
The most informative technical question in any TOS evaluation isn't about features. It's about integration ownership.
Ask this: "Which integrations in your standard connector library are maintained in-house, and which are delivered via third-party system integrators?"
The answers sort vendors into two architectural models:
Model A — Platform with owned integrations
The vendor maintains native connectors for customs EDI, shipping line APIs, ERP platforms (SAP/Oracle), and port community systems (Portbase, INAPORT, etc.). Updates to those connectors happen within the vendor's own release cycle. Breaking changes are the vendor's responsibility to fix.
Model B — Platform with integration marketplace
The vendor's core platform is solid. Most integrations are delivered by a partner ecosystem. The terminal pays for the core licence and then separately engages a system integrator for each connection. This is not a failure mode — but it significantly affects total cost and long-term ownership structure.
Most large terminals need Model A for mission-critical connections (customs, shipping lines) and are fine with Model B for ancillary integrations (ERP reporting, BI tools). The danger is when a vendor presents all integrations as "native" and the discovery phase reveals most are marketplace connectors.
API Evaluation: What to Actually Test Before Signing
Modern TOS platforms support three integration paradigms:
REST API → JSON-based, stateless, event-driven webhooks
EDI (EDIFACT) → BAPLIE, COPARN, CODECO, COARRI, CUSCAR message types
Proprietary API → Platform-specific SDK, often legacy crane/equipment interfaces
The 5 API questions to put in writing before contract signature:
"What is your API versioning strategy, and how long are deprecated versions supported after a major release?"
Answer below 12 months = migration risk every upgrade cycle."Which shipping line APIs are you currently maintaining as live production connections, not certified in sandbox?"
Certified-in-sandbox connections require terminal-side integration work at go-live. Know the difference."What is the rate limit and SLA on your real-time yard position API?"
RTG and crane automation systems make thousands of calls per minute. Rate-limited APIs cause operational failures, not just slowdowns."How is equipment PLC interface connectivity handled — native driver, middleware, or third-party OEM integration?"
This single question eliminates half the field for terminals with non-standard crane configurations."Show us the API documentation for your berth planning module — the live production version, not a PDF."
If they don't have live API docs, the integration is not mature.
Cloud vs On-Premise: The Technical Architecture Decision
The business case for cloud vs on-premise usually lives in the commercial team. The technical risk lives with the systems team. Here's the architectural dimension:
Latency Requirements
Real-time yard operations require sub-100ms response times for crane work instruction delivery. Cloud-hosted TOS platforms serving yard control systems via WAN introduce latency that can cause crane sequencing errors at high-throughput terminals.
The architectural solution is edge computing — local processing for real-time operational functions, cloud routing for analytics, planning, and reporting workloads. This is what "hybrid TOS" means in practice, not just a cost compromise.
Edge layer (on-terminal):
- Crane work instruction generation
- RTG positioning and stack planning
- Gate OCR processing
- Real-time yard position database
Cloud layer:
- Vessel arrival planning (12-72 hour horizon)
- ESG/emissions reporting
- Business intelligence and KPI dashboards
- Cross-terminal data aggregation (for multi-port operators)
Data Residency
Several port authority markets have explicit data localisation requirements:
- India: Port data under DPDPA 2023 has localisation implications for sensitive operational records
- Indonesia: Government Regulation No. 71/2019 restricts certain data from offshore processing
- Saudi Arabia: PDPL 2021 and NCA cloud computing controls apply to critical infrastructure operators
- Brazil: LGPD has data residency implications for ports operating under federal concession
A cloud-native TOS selected without regulatory review creates a remediation problem, not just a compliance flag.
Upgrade Control
Cloud TOS platforms push updates on the vendor's schedule. For most software categories this is acceptable. For a TOS, it is not always safe.
The specific risk: a crane scheduling algorithm update that changes work instruction sequencing logic can cause operational disruption if it goes to production without terminal-specific testing. At least two major TOS deployments in Northern Europe experienced this between 2023 and 2025.
The contractual requirement for cloud deployments: Staging environment access. The ability to receive, test, and accept/reject updates before they reach production. Some vendors offer this. Most do not by default — it requires explicit contractual language.
AI/ML Capability: Native vs Bolt-On
The vendor marketing slide will say "AI-powered." The technical evaluation needs to determine what that means:
Native AI means the predictive model is trained on the platform's own operational data, runs within the TOS data environment, and influences operational decisions in real-time without data extraction.
Bolt-on AI means a third-party analytics layer (Palantir, C2RO, or similar) that receives a data export from the TOS, runs analysis separately, and returns recommendations that a planner then implements manually.
Both can be valuable. They are not equivalent. The distinction matters for:
- Data pipeline reliability (bolt-on requires stable export jobs; native is always current)
- Decision latency (bolt-on adds hours; native can influence in-cycle decisions)
- Vendor accountability (bolt-on failure responsibility is split; native failure is the TOS vendor's problem)
The evaluation question: "Where does the training data for your predictive berthing model live, and what is the latency from a vessel ETA update to a revised berth allocation recommendation?"
An answer above 30 minutes is a bolt-on model with a batch export pipeline.
Implementation Risk: The Technical Failure Modes
The five TOS implementation failure modes that the systems team needs to own:
1. Data migration underscoping
A live terminal with 10+ years of operational data has container histories, vessel records, customer profiles, and equipment maintenance logs distributed across a legacy TOS, a separate billing system, and almost certainly some Excel files. Migration scope discovery is a 4–8 week engagement on its own. Vendors who quote migration timelines in the initial proposal haven't done discovery.
2. EDI variant mismatch
EDIFACT message types are standardised. Implementations are not. BAPLIE from Maersk is not identical to BAPLIE from MSC. Shipping line-specific EDI variants require terminal-side mapping work. The number of live shipping line connections at your terminal is directly proportional to integration programme complexity.
3. Equipment PLC interface gaps
Legacy crane control systems (Siemens, ABB, Kalmar, Konecranes vintage pre-2018) often use proprietary PLC interfaces that are not documented in the TOS vendor's connector library. Custom driver development adds 3–6 months to the implementation programme.
4. Production cutover risk
Moving from a live legacy TOS to a new platform requires a cutover window. Parallel operation of two TOS platforms for a finite period is the only safe cutover model. Single-step cutover (old system off, new system on) carries full operational risk. The implementation programme must include a parallel operation phase with clear go/no-go criteria.
5. Hypercare cliff
Most TOS contracts include 6–12 months of hypercare support at implementation team density. After hypercare ends, the support model drops to a standard SLA. The technical team needs a knowledge transfer programme during hypercare that makes this transition functional, not a support gap.
The TOS Comparison Table (Technical Read)
| Platform | API maturity | Real-time yard API | AGV native integration | Update control | Edge support |
|---|---|---|---|---|---|
| Navis N4 | REST + EDI, mature docs | Yes, high-throughput | Yes (major manufacturers) | Staging env. available | Limited |
| CATOS | EDI-primary, REST limited | Partial | Limited | Manual approval | No |
| Tideworks Mainsail | REST + EDI | Yes | Yes | Staging env. available | No |
| TBA Group Autostore | REST native | Yes | Yes (Europe-focused OEMs) | Configurable | Partial |
| Intech Smart TOS | REST + EDI + proprietary | Yes | Yes, multi-manufacturer | Full staging env. | Yes |
Discussion
Would like to hear from port IT teams and system architects:
- What integration failure mode has caused the most pain in your TOS deployment?
- Has anyone successfully negotiated staging environment access into a cloud TOS contract?
- What's your approach to managing legacy crane PLC interfaces that predate the current TOS?
Full technical and procurement guide (17-minute read):
https://theintechgroup.com/blog/tos-buyers-guide-terminal-operating-system/
Top comments (0)