Most of the market conversation about SOAP to REST treats it as a protocol swap. Change the protocol, update the endpoints, move on.
It is not a protocol swap. Your CargoWise environment delivers outbound data to every connected system: customs platforms, accounting systems, warehouse management tools, logistics partners, through a service that is entirely SOAP based. Every outbound handler, every data transformation, every delivery mechanism was purpose built for SOAP, within the architectural constraints of the legacy platform, including a single outbound endpoint through which all data had to route regardless of how many systems it was destined for.
eAdaptor Next retires that entire environment. REST replaces SOAP. Per system channels replace the single endpoint. OAuth 2.0 replaces Basic Auth. The architectural constraints your outbound layer was built around will no longer exist.
But a protocol change does not remove the business logic, dependencies, and operational decisions embedded in the existing integrations.
And until those are understood, nobody can reliably determine what should be adapted, what needs rebuilding, or what the migration will actually cost.
This is where the SOAP to REST transition becomes a much bigger conversation than replacing an interface.
Your outbound estate contains two things. Only one of them carries forward.
The outbound handlers delivering data from your CargoWise environment were almost always written by a third party vendor during the original implementation, years ago, when the integration requirements were simpler and the number of connected systems was smaller. The people maintaining them today did not build them. Documentation is incomplete when it exists at all.
Inside that code, two things are interleaved.
The first is business logic : the transformation rules, field mappings, validation routines, and conditional routing that determine how data moves between your CargoWise environment and every connected system. This logic was refined through years of live operation. It handles edge cases discovered in production. It reflects how your business actually runs, not how a specification says it should. This is the most valuable asset in your integration estate and it carries forward in every migration scenario.
The second is SOAP specific architecture : the message handling, connection management, error routines, and structural patterns that were designed to make that business logic work within the legacy platform. Well designed for its time. But that time is ending. Every architectural assumption in that structural code is tied to SOAP, to the single outbound endpoint, to Basic Auth — platform realities that eAdaptor Next removes entirely.
Until these two are separated, your migration plan cannot tell the difference between what you are preserving because it has operational value and what you are carrying forward simply because nobody has looked closely enough to know it should not come with you.
How much you carry forward determines what this migration actually costs
This is the decision at the centre of the protocol shift. It is not a binary. It is a spectrum, and where you sit on it depends on what your outbound estate actually contains.
Carrying more SOAP architecture forward is faster and cheaper upfront. The structural code is adapted to work within REST. But every SOAP era decision comes with it — connection patterns, error handling, endpoint workarounds — all running inside a platform they were never designed for. Over three to five years, maintaining adapted SOAP architecture inside a REST environment often costs more in ongoing maintenance and workarounds than addressing it during the migration would have.
Addressing more during the migration is a larger initial investment. But the business logic is preserved and the architecture around it is designed for the environment it will actually operate in — not carried over from one that no longer exists. The result is an integration layer that works with the platform rather than around it, and that does not need to be rearchitected the next time CargoWise evolves.
Most organisations will land somewhere between the two. What determines where you sit on that spectrum:
- The size and condition of your integration estate
- The complexity and quality of your transformation logic
- The number of connected systems and external dependencies
- What your organisation needs from its integration architecture over the next three to five years — not just over the next three months
But it is a total cost of ownership decision. And it can only be made with full visibility of what you are carrying. Any organisation that commits to a path without that visibility is not making a strategic choice. It is making a bet on legacy architecture it has not examined, against a timeline it cannot control.
What to verify before your scope is committed
If your eAdaptor Next migration plan was built without examining your outbound integration estate in detail, the plan is not wrong. It is unverified.
Before scope and budget are locked, three things need to be established:
- What does your outbound handler code actually contain today? Not what it was originally built to do. What it does now — what business logic is embedded in it, what is SOAP specific, and what has accumulated over years of change that may no longer serve a purpose.
- Has the business logic been separated from the SOAP architecture? If everything is being treated as one block to migrate, the plan cannot tell the difference between operational value and legacy structural cost being carried forward by default.
- Is your scope based on what the code contains, or on assumptions? If nobody has examined the outbound codebase, every downstream estimate — timeline, resourcing, budget, risk — inherits that gap.
Clear answers mean your migration is in a strong position. If the answers are not there yet, this is the starting point — and the time is before commitments are made, not after.
Next in the series: the shift from Basic Auth to OAuth 2.0, and the middleware dependency most organisations have not tested yet.
