A migration estimate built around the number of existing CargoWise integrations can look reasonable until the EDI Client requirements are mapped.
The applications may be unchanged. The integration logic may be retained. Yet the number of connections requiring configuration, authentication, testing, and ongoing management can be considerably greater than the original estimate suggests.
This is particularly relevant for multi entity CargoWise environments, where shared middleware, regional system deployments, and legacy authentication arrangements can conceal the true scope of the integration architecture.
The question is no longer simply how many integrations are in use. It is how many distinct EDI Client configurations are required to support them under eAdaptor Next.
That distinction has direct consequences for migration cost, delivery sequencing, and the resources needed to complete the transition.
Why the existing integration inventory may understate the scope
eAdaptor Next requires individually managed EDI Client configurations and credentials for each external connection. For inbound connections to WiseCloud hosted environments, the configuration must also support certificate based OAuth 2.0 authentication.
The significance of this change becomes apparent when existing connections are mapped against the new architecture.
An integration inventory may record a single warehouse management platform or customs provider at group level, while the underlying configuration includes separately deployed regional instances, independent endpoints, or connections maintained by different external vendors. Conversely, a central middleware platform may support several entities and numerous downstream integration flows through a common connection.
The number of legal entities does not automatically determine the EDI Client count. Nor does the number of external applications accurately represent the testing effort.
The migration scope must reconcile three things:
- the external systems in operation,
- the EDI Client configurations they require,
- and the integration flows that depend on those connections.
In multi entity environments, those numbers can differ substantially. Until that mapping is completed, the estimate remains dependent on assumptions about how the existing architecture will transition — and assumptions at this level of the programme tend to surface as scope changes once the work is underway.
The commercial exposure is in the work behind each connection
An additional EDI Client is not necessarily a significant cost in isolation. The cumulative delivery requirements are what matter.
Each separately configured connection introduces work around authentication, endpoint settings, associated organisations, and the validation of affected message flows. For WiseCloud inbound connections, certificate generation, exchange, and authentication testing must also be coordinated with the relevant system or middleware provider — on their timeline and within their capacity, which your organisation does not control.
Once the complete connection scope is established, its implications extend into the wider migration programme.
Configuration and development. Additional EDI Client configurations may require middleware changes, revised connection settings, authentication development, and specialist technical resources beyond those included in the original estimate.
Integration testing and partner coordination. Each affected flow must be validated against the intended configuration. Message handling, routing, acknowledgements, and failure scenarios need to be tested, often with external vendors whose availability must be coordinated. A compatibility issue in one connection can delay testing across several dependent flows.
Delivery sequencing. Dependencies between shared middleware, individual EDI Clients, and downstream integrations influence which connections can be migrated together. A late change to this architecture can require revisions to testing windows, resource allocation, and cutover plans.
Post migration support. Individually managed connection configurations, certificates, and endpoints introduce operational responsibilities that continue indefinitely. Each certificate has a defined lifecycle, and when it expires, the integration it secures stops working — not degrades, stops. Ownership, renewal arrangements, monitoring, and incident support need to be established as part of the future operating model, designed for the actual EDI Client count rather than the estimated one.
These requirements have a direct bearing on the project's total cost. A migration budget approved against an incomplete EDI Client inventory may exclude substantial configuration and testing effort, external provider involvement, and recurring support obligations.
The commercial concern is not that eAdaptor Next introduces more explicit connection management. That is a deliberate part of the platform's modernisation.
The concern is committing to a delivery estimate before the full extent of that work has been established.
Solution design must precede the final migration estimate
For a complex CargoWise environment, the EDI Client inventory needs to be supported by a documented migration design.
That design should establish the relationship between existing integrations and their proposed eAdaptor Next configurations, with enough detail to determine the work involved in each transition.
The essential documentation includes:
- Current state architecture. Existing integrations, middleware dependencies, endpoints, message directions, relevant entities, and technical ownership.
- Future state architecture. The proposed eAdaptor Next connection design, identifying which connections will be retained, reconfigured, or separated.
- EDI Client configuration register. Required EDI Client records, system associations, organisation mappings, endpoints, and authentication settings.
- Certificate management workflow. Certificate request, generation, exchange, deployment, renewal, and ownership procedures for applicable connections.
- Integration test specifications. Message scenarios, expected outcomes, exception handling, partner responsibilities, and cutover dependencies.
The current state architecture establishes what exists. The future state design establishes what must change. The EDI Client register translates that design into configuration requirements, while certificate workflows and test specifications determine the resources and coordination needed to implement it.
Together, they provide the basis for a more accurate estimate of development effort, partner involvement, testing capacity, and delivery timelines. They also establish the technical reference that support teams will need once the integrations are operating through eAdaptor Next.
Without that detail, a project can have an approved timeline and budget while still lacking a complete definition of the work it needs to deliver.
An accurate estimate starts with the actual connection scope
For organisations managing complex CargoWise environments, the EDI Client assessment should inform the migration plan before its budget and delivery commitments are finalised.
An accurate eAdaptor Next migration estimate must reflect the connections that need to be configured, the integration flows that must be validated, and the ongoing responsibilities created by the new architecture. Without that level of detail, the approved migration scope may not represent the programme the organisation ultimately needs to deliver.
The gap between an application level inventory and the actual connection architecture is one of the most consistent findings in eAdaptor Next migration assessments. Closing it before commitments are made is not additional work. It is the work that determines whether the commitments are reliable.
The next article in this series addresses the dimension of the eAdaptor Next migration that extends beyond your own organisation: why every external partner is affected, and why your delivery timeline may depend on their readiness as much as your own.
