Legacy carrier integrations
Carrier APIs change, legacy integrations get retired and shipping workflows need to keep running.
Warsash Software Engineering helps logistics businesses, courier resellers, fulfilment providers, e-commerce platforms and bespoke software owners maintain, modernise and migrate carrier API integrations without losing sight of live labels, collections, tracking and operational edge cases.
This is practical migration delivery: discovery, mapping, build, test, cutover and post-go-live support for shipping systems that are already embedded in day-to-day operations.
Published carrier transition dates have now passed, but older integrations can still surface in inherited platforms, dormant account paths and operational workflows that were never fully migrated. These pages now focus on identifying and replacing that legacy risk safely.
DHL eCommerce UK / UKMail
Relevant to older UKMail and DHL eCommerce UK integrations embedded in booking portals, warehouse systems, dispatch flows and bespoke logistics software.
DHL's published legacy migration deadline was 30 June 2026. Its current technical update also says Cloud API endpoints will change in the near future, with the go-live date still to be confirmed.
FedEx Web Services
Relevant to systems still using FedEx SOAP or Web Services for rating, shipping, labels, tracking, address checks and international shipment data.
FedEx's current guidance says Web Services moved to maintenance-only support from 1 July 2026. Existing integrations may continue temporarily, but general troubleshooting and development support has ended and future capability is API-first.
TNT ExpressConnect / TNT services
Relevant to businesses still using TNT ExpressConnect or other legacy TNT integrations for booking, labels, tracking or international shipping flows.
FedEx has been moving TNT services and accounts in phases. Migration timing can be account-specific, but the technical replacement route often means mapping TNT workflows to FedEx REST APIs.
Warsash Software Engineering can help when a carrier API migration touches production workflows that have grown around the original integration over time.
Carrier API migration is rarely a straight swap. The work usually spans old business rules, internal assumptions, label formats, operational timing and production handoffs.
Review the existing carrier integration, credentials, workflows, business rules and operational dependencies.
Identify which legacy operations need to be replaced and map them to the equivalent modern carrier API flows.
Implement the replacement integration while keeping the current live workflow stable until the new slice is ready.
Exercise rating, shipment creation, labels, tracking, service rules, failure responses and operational edge cases.
Agree a controlled migration window, switch live traffic and monitor early production behaviour closely.
Provide post-migration support and keep a path open for future carrier API changes.
Warsash Software Engineering is run by Chris Buckle, a software engineer with deep experience in parcel, courier and logistics platforms.
Chris co-founded Parcel Monkey and has worked with shipping systems involving DHL, FedEx, DPD, TNT, Evri and other carrier integrations since 2006. That matters when a migration is tied to live labels, account rules, tracking events, warehouse processes or customer-facing checkout.
This is not generic API work. The objective is to preserve the operational workflow and reduce migration risk, not just move traffic to a new endpoint.
Share a short outline of the carrier integration, the legacy dependency or operational risk, and which workflows need to keep running.
Typical enquiries include DHL eCommerce UK / UKMail migration, maintenance-only FedEx Web Services, TNT ExpressConnect to FedEx migration, legacy SOAP integrations, label generation risk, tracking problems and bespoke logistics platform support.
If you prefer email first, contact [email protected].
Go straight to the DHL, FedEx or TNT service page if the carrier change is already known.
