Your middleware may support REST and still be unable to authenticate with eAdaptor Next. That one compatibility gap can change your integration architecture, migration costs, and delivery timeline.
Your CargoWise integrations have been running reliably for years. The middleware connecting your environment to customs platforms, accounting systems, warehouse applications, and logistics partners was configured long ago and has performed consistently ever since. It is part of the technology estate that works, and because it works, it does not get questioned.
But eAdaptor Next introduces a requirement that years of reliable performance cannot answer. Can your existing middleware authenticate with eAdaptor Next using OAuth 2.0?
For inbound connections to WiseCloud hosted CargoWise environments, certificate based OAuth 2.0 authentication is mandatory. If existing middleware cannot support the required authentication process, the migration may involve additional development, a different connection architecture, and costs that were not included in the original estimate.
REST compatible does not mean OAuth 2.0 compatible
This distinction is critical and it is widely misunderstood.
eAdaptor Next changes this model. Alongside the transition from SOAP to REST based communication using HTTP and XML, inbound connections to WiseCloud hosted environments require certificate based OAuth 2.0 authentication.
These are two distinct capabilities.
REST determines how systems exchange information. OAuth 2.0 determines whether the connecting system is authorised to access CargoWise.
Under the new authentication model, middleware must use the required certificate credentials to obtain an access token and present that token when communicating with eAdaptor Next. It must also manage token validity, handle authentication failures, and support certificate renewal to maintain connectivity. Each certificate has a defined lifecycle, and when it expires, the integration it secures stops working — immediately, with no grace period and no fallback to Basic Auth.
If your middleware cannot authenticate, your integration logic is not the problem.
The business rules, data mappings, message routing, and exception handling your middleware performs may be perfectly sound — years of valuable operational logic that your business depends on daily. The gap is narrower than it appears: eAdaptor Next requires a specific certificate based authentication process before any data can be exchanged. If the middleware cannot complete that process, the connection to CargoWise is never established. The data handling capability is intact. The integration simply cannot connect.
There are proven ways to address this. The middleware may be upgraded. A compatible connector may be available. Or a proxy layer can be introduced to handle authentication on behalf of your existing middleware, preserving the integration logic inside it.
But each of these options introduces work that was not in the original migration plan — design, development, security configuration, testing, and in the case of a proxy layer, a permanent addition to your integration architecture that requires ongoing monitoring, certificate management, and support.
For organisations with multiple integrations using the same middleware infrastructure, this decision can affect much more than a single connection. Customer EDI messages, customs related data, financial transactions, and shipment visibility updates may all depend on the same integration architecture.
The technical solution may be manageable. The commercial consequences depend on how much of the original migration plan must change to accommodate it — and when that change is discovered.
One authentication gap. Three business costs.
A migration budget may already account for EDI Client configuration, protocol changes, integration testing, and cutover. But if middleware authentication was never validated, those estimates may not represent the full work required.
An incompatibility can introduce costs in three areas.
1. Additional development and implementation costs.
Middleware upgrades, custom OAuth 2.0 development, or a new proxy service may require specialist resources, security configuration, infrastructure, licensing, and additional testing. Work that was not included in the approved migration budget now needs to be funded and delivered.
2. Delivery delays and wider integration dependencies.
If several inbound integrations rely on the same middleware, a change to their shared authentication architecture can affect their testing and cutover schedules. External partners may need to be involved again. Previously planned activities may need to be resequenced. A compatibility gap discovered during testing can affect the delivery of multiple integrations rather than one isolated connection.
3. Ongoing operating costs and business exposure.
Where new middleware capabilities or an intermediary service are introduced, the costs continue beyond go live. Monitoring, certificate renewal, security maintenance, and technical support become recurring responsibilities. If a shared authentication component fails, dependent integrations stop exchanging messages — potentially halting customs processing, delaying financial reconciliation, or cutting shipment visibility to partners and clients until connectivity is restored. Under OAuth 2.0, every certificate has a defined lifecycle, and when it expires, the integration it secures stops working immediately with no grace period and no fallback to Basic Auth.
These costs are not necessarily avoidable. Some organisations will genuinely require changes to their integration architecture to support eAdaptor Next.
What is avoidable is approving a migration plan that does not account for them.
An authentication gap identified during initial assessment is a technical requirement that can be planned and costed. The same gap discovered during integration testing becomes an unbudgeted change to an active delivery programme.
What should be verified before the migration scope is approved
Start by identifying which connections are subject to the new authentication requirements. Inbound connections to WiseCloud hosted CargoWise environments require certificate based OAuth 2.0. Outbound connections and self hosted environments may support different authentication configurations.
For affected inbound connections, middleware readiness should be verified through testing, not assumed from platform specifications. Specifically:
- Can the middleware complete the required OAuth 2.0 authorisation flow and obtain access tokens?
- Can it manage token validity and handle token refresh automatically?
- Can it present the required certificate credentials correctly?
- Can it recover from an authentication failure without manual intervention?
- Can it successfully exchange messages through eAdaptor Next under conditions that reflect the production environment?
A successful initial connection alone is not sufficient. Certificate renewal, authentication recovery, and sustained connectivity under production conditions also need to be evaluated — because certificates expire, and when they do, the only thing that prevents an outage is a governance process that was designed before it was needed.
Ownership also needs to be established clearly:
- Who owns each middleware component and who is responsible for making changes?
- Where a third party provider develops, hosts, or supports the integration, what are their capabilities, commercial terms, and development timelines for compatibility work?
- Who will be accountable for certificate lifecycle management and authentication monitoring after cutover?
The outcome of this assessment should establish whether the existing middleware can be retained as is, needs modification, or requires an intermediary authentication component. Each path carries different implications for cost, testing, delivery dependencies, and ongoing support — and those implications need to inform the migration estimate before the organisation commits to a final architecture and timeline
Build the migration plan around verified compatibility
Before your migration scope is approved, you should have in hand:
- A documented test confirming whether your middleware can authenticate with eAdaptor Next under production conditions
- A clear architectural path — retain, modify, or introduce a proxy — with each option costed against your specific environment
- Defined ownership of certificate lifecycle management and authentication monitoring for the post migration operating model
- An updated migration estimate that reflects the actual authentication architecture, not an assumption about it
That is the difference between a migration plan built on verified ground and one carrying a dependency that has not been tested. The first gives you control over the architectural decision and its cost. The second leaves both to be determined by when the gap surfaces.
Next in the eAdaptor Next series: why your EDI Client count could be larger than your migration estimate, particularly across multi entity CargoWise environments.
