January 2027. Legacy eAdaptor retires. Every CargoWise client running integrations through the legacy framework migrates to eAdaptor Next. The timeline is set, the cutover is happening, and every organisation in the CargoWise ecosystem is reacting.
eAdaptor Next is a full technical migration that enhances the entire CargoWise integration stack. Not a version upgrade. Not a configuration update. A structural shift in how your technology environment connects to every system and partner around it. Within this single migration, four areas of your integration architecture are changing at the same time: protocol, security model, credential architecture, and operational governance.
Most of the preparation happening across the market right now is focused on the first.
Here is why that is not enough.
SOAP to REST rewrites your interface layer, but the real question is what sits behind it
The protocol shift is the change the market has absorbed. Every integration endpoint, every outbound handler, every data exchange changes how it communicates with CargoWise. The entire interface layer rewrites. If this is what your preparation is built around, you are working on the right problem. You are just not working on enough of it.
But this is also where a false sense of progress takes hold. Organisations see the protocol shift, scope for it, and believe the migration is sized. What they have not accounted for is what sits behind those endpoints.
The code running your outbound handlers is almost always older than anyone assumes. It was built by third party vendors no longer in the picture. It is maintained by teams that did not write it. And it frequently does less than anyone expects. Until someone has actually opened it and read it, every estimate is a guess built on assumptions about a codebase nobody has examined.
That matters because the protocol shift forces a decision every organisation will face: do you patch the existing architecture to work with REST, or do you rebuild? The business logic inside your integrations — transformation rules, data mappings, operational shaping — is often the most valuable and reusable asset you have. The architecture surrounding it may not be. But you cannot make that decision without visibility. And you certainly cannot make it well while another shift is happening at the same time.
OAuth 2.0 replaces Basic Auth, and your middleware may not support it
Basic Auth goes away entirely. OAuth 2.0 with certificate based authentication takes its place. That is not a security enhancement layered onto what you already run. It is a fundamentally different authentication architecture with its own operational demands.
And here is the dependency that catches organisations late: your middleware stack may not support OAuth 2.0 natively. That compatibility cannot be assumed. It must be tested against your specific environment. When middleware fails that test and across the CargoWise ecosystem, the migration changes shape. New architectural components are needed. Cost increases. Complexity increases. And this surfaces after scoping is done, after the budget is committed, after the timeline is set. By the time it becomes visible, the options for absorbing it are narrow.
If your team cannot tell you today, with evidence, that your middleware has been tested for OAuth 2.0 compatibility, that is an unresolved dependency at the centre of your migration plan.
Each external system now needs its own EDI Client
Legacy eAdaptor allowed multiple external systems to share credentials. That flexibility shaped how most CargoWise integration estates were designed. eAdaptor Next removes it entirely.
Each external system requires its own dedicated EDI Client. Shared credentials are architecturally impossible. For a single entity environment, the increase is manageable. For multi entity environments, which is what most established CargoWise operations run, the EDI Client count multiplies across every entity and every external connection.
What looks like a contained scope on paper becomes a significantly larger programme when the real count is established. Resourcing changes. Testing timelines extend. Sequencing gets harder. And all of this is compounding — your interface layer is being rewritten, your authentication model is being replaced, your credential count is multiplying, and your business is still running live on the same integrations you are trying to migrate.
That live operation is not a footnote. It is the context in which this entire migration has to be planned and executed.
Your partners are affected too, and your timeline depends on their readiness
SOAP to REST and OAuth 2.0 affect both ends of every integration. Every middleware vendor, every third party system, every external partner that sends data to or receives data from your CargoWise environment needs to change alongside you. This is not something you can execute unilaterally.
Your migration timeline is not governed by how fast your internal team can work. It is gated by the readiness of every partner in your ecosystem. If a critical external partner has not started their preparation, you carry a dependency you cannot accelerate from your side. And right now, across the CargoWise ecosystem, many of them have not.
After cutover, the operating model shifts again. Certificate lifecycle management becomes continuous. Token administration becomes ongoing. EDI Client governance at scale becomes a discipline, not a one time setup. The way you operate your integration estate today is not the way eAdaptor Next requires you to operate it from January 2027 forward.
If your plan delivers a cutover but does not deliver an operating model for what comes after, you have solved the deadline without solving the shift.
The integration architecture you build now determines what you can leverage next
eAdaptor Next is not the end state. It is the foundation for what CargoWise is building next. AI driven workflows. Advanced automation. Enhanced platform capabilities through CargoWise Next. Every future enhancement that depends on clean, well governed, well structured integration architecture depends on what you build through this migration.
An organisation that patches its way to January 2027 will make the deadline. An organisation that uses this migration to build a properly documented, governed, visible integration estate — with clean credentials, tested authentication, structured operational ownership — will be positioned for every capability the platform delivers beyond it.
That is the difference between a compliance exercise and a strategic investment. The work is the same. What you choose to build through it is not.
Where does your preparation actually stand?
Can your team produce a complete inventory of every integration in your CargoWise estate? Have they read the code behind your outbound handlers? Has your middleware been tested for OAuth 2.0 compatibility? Has anyone mapped the EDI Client count across every entity and every external system? Does your plan include coordination with every external partner whose connections are affected? Is there a post cutover operating model designed for certificate governance, token management, and EDI Client administration at scale? Has anyone designed how all of this happens without disrupting the live operations your business runs on those same integrations?
If the answer to all of those is yes, you are ahead of most of the market.
If some of them are open, it needs to be a starting point now, not a discovery made mid programme when the scope has already been committed and the room to adjust is gone.
This is the first in a series that takes each of these areas apart in full. Watch out for the second article on: “SOAP to REST Rewrites Your Entire Integration Layer” next week!
