An eAdaptor Next migration can be thoroughly planned, correctly scoped, and competently executed within your organisation — and still be unable to deliver a working integration because the systems on the other end have not been configured to connect through the new architecture.
The protocol and authentication shifts introduced by eAdaptor Next do not stop at your CargoWise environment. They affect both ends of every connection. SOAP to REST changes how two systems communicate. OAuth 2.0 changes how they establish trust. The per system EDI Client model changes the credential relationship between them. If the external system cannot support what the new architecture requires, the connection cannot operate — regardless of how ready your environment is.
Most migration plans address the internal workstreams comprehensively. The external dimension — the readiness of every system, vendor, and partner on the other side of those connections receives less structured attention.
Both ends of every connection must change
eAdaptor Next changes how external systems communicate with and authenticate to CargoWise. SOAP based messaging is replaced by REST based communication using HTTP and XML. For inbound connections to WiseCloud hosted CargoWise environments, certificate based OAuth 2.0 authentication is required. Each external connection requires its own dedicated EDI Client configuration and credentials.
But the changes required outside CargoWise depend on how each integration has been designed and who manages the connection.
Direct connections to CargoWise
Where an external application communicates directly through eAdaptor, the provider responsible for that application needs to update its integration.
For inbound connections to WiseCloud hosted environments, this includes supporting the required HTTP and XML messaging, certificate based OAuth 2.0 authentication, access token management, and the relevant EDI Client credential configuration.
The provider must be able to complete these changes and test its connection against the new environment within the migration timeline.
Connections managed through middleware
Some external partners exchange information with CargoWise through a middleware platform or managed integration service. In this arrangement, the middleware handles communication with CargoWise and may transform or route messages to the external partner using a separate interface.
The middleware provider may therefore be responsible for implementing the eAdaptor Next changes, without requiring the business partner to modify its own application.
The important distinction is who owns the CargoWise facing connection, rather than simply who sends or receives the information.
Outbound connections from CargoWise
Where CargoWise sends information to an external application, the receiving endpoint must be compatible with the new messaging approach. Authentication requirements depend on the outbound configuration and are not necessarily the same as those for inbound WiseCloud connections.
An external provider may need to update its receiving service, endpoint configuration or message handling before it can process the information correctly.
These differences matter because external readiness cannot be established through a general notification to every partner. Each affected connection needs to be understood in the context of its actual architecture and technical ownership.
The Providers Supporting Different Markets May Have Different Timelines
A regional customs integration may depend on a local technology provider whose development team is supporting several clients. A warehouse connection may be maintained by a third-party software vendor that requires a formal change request. A financial integration may have been developed by an implementation partner that is no longer involved in day-to-day support.
Each dependency presents a different question.
Who has the technical authority to make changes? Does the existing integration support the new requirements? Is development needed? Are there contractual approvals or additional charges? When can the provider make its environment available for testing?
The answers determine whether the integration can transition within the proposed migration schedule.
The migration schedule must account for the availability and readiness of the providers supporting those connections, not only the resources working inside the CargoWise environment.
When External Readiness Becomes a Commercial Cost
Depending on the connection's importance, it can affect the cost of delivery, the resources required and the business processes that rely on automated data exchange.
Three consequences deserve particular attention.
- Additional vendor costs and development work
An external provider may need to upgrade its connector, modify message handling or implement a different authentication method. That work may fall outside the provider's existing support agreement. New development fees, licensing costs or professional services charges can become necessary before the integration can be migrated.
If these requirements are only discovered during final testing, the organisation may need to secure additional budget and approvals while the migration is already in progress.
- Repeated testing and extended migration activity
Joint testing depends on both organisations having compatible configurations, available environments and technical resources at the same time. If an external provider cannot complete its changes within the agreed window, testing may need to be rescheduled. Technical teams may need to revisit configurations, repeat message validation or adjust the cutover sequence.
Where other integrations depend on the same service, delays can extend into additional workstreams.
- Extended operating costs and delayed business benefits
Where technically supported, legacy eAdaptor and eAdaptor Next connections may operate alongside each other during a phased migration. This provides flexibility, but maintaining both environments can extend monitoring, troubleshooting and support requirements.
More importantly, a delayed integration can postpone the operational benefits expected from the migration. If an affected connection cannot exchange data reliably, teams may need temporary manual procedures or additional reconciliation until it is restored or transitioned.
For a business managing high transaction volumes, those workarounds can carry a measurable productivity cost.
The implication is straightforward: an external dependency discovered early can be incorporated into the migration scope and commercial plan. One discovered late may require the business to revise both.
What an External Readiness Plan Must Establish
For organisations with multiple affected integrations, external coordination needs to be treated as a defined part of migration delivery rather than an activity left until testing begins.
Four areas require particular attention.
- Connection ownership and impact. Establish a complete view of the integrations using legacy eAdaptor, including the external systems involved, the middleware or integration services supporting them, and the party responsible for the CargoWise-facing connection. This determines who actually needs to make changes.
- Technical readiness and delivery commitments. Confirm which providers already support the required protocol and authentication configuration, which need additional development and when that work can be completed. Their delivery dates need to be incorporated into the overall migration schedule.
- Joint testing and acceptance. Agree on test environments, authentication configuration, message formats, test scenarios and escalation responsibilities. Testing should confirm that messages are received and processed correctly, including error handling and recovery. A successful technical connection alone does not establish that the business workflow is functioning as expected.
- Cutover sequencing and contingency arrangements. Business-critical integrations need clear cutover criteria. Where a provider is not ready, the organisation must determine whether a temporary legacy connection can be maintained, an alternative connection approach is feasible or the migration sequence needs to change. Any fallback must be technically supported and tested before it is relied upon.
Your Migration Plan Must Reflect the Full Integration Environment
For organisations operating across multiple entities, regions and technology providers, those external dependencies can be significant. They influence how integration testing is scheduled, how cutovers are sequenced and how the migration budget is established.
At SFL Tech, our eAdaptor Next migration services help CargoWise customers assess existing integrations, identify technical ownership and third-party dependencies, and plan the changes required to transition affected connections.
Our integration specialists support architecture assessment, connection configuration, development, partner coordination and end-to-end testing, helping customers establish a migration plan that reflects the full scope of their connected environment.
The January 2027 cutover date is set and it will not move. Every external connection that has not been assessed, configured, and tested against eAdaptor Next before that date becomes a remediation problem after it — resolved under operational pressure, at higher cost, and with direct impact on the business processes that depend on those integrations.
Preparing for eAdaptor Next? Speak with SFL Tech about assessing your integration dependencies and building a coordinated migration plan.
