Pinned straw:
Discl: Held IRL 3.20%
Following @mikebrisy's straw, got Claude to spit out a bit more information about DSV’s Tango - see below. I added some slides from the preso below to help me crystallise the points Claude made, all of which made sense to me.
The DSV Capital Markets Day 2026 preso was very interesting as pages 28-42 was a huge upfront piece on the IT Strategy. To have this upfront in a Startegy Day for a non-IT company is quite telling.
My immediate thoughts, questions, uncertainties, coming from an IT Strategy perspective:
1. To have the IT Strategy piece upfront was very telling of DSV’s intent to be “A technology-driven transport and logisitics company”. This strategy makes sense, but the intent to insource everything IT systems end-to-end, when this is not the core business, is a really, really strange one, and flies against the face of conventional wisdom. Or is DSV actually intending to make IT a core part of its business moving forward, over and above IT being a critical business enabler?
2. Major focus on the Enterprise Data Platform - this thinking within corporations has been around for a while, but has mostly been a theoretical aspiration. Data is primarily created, retained and used in inidividual core enterprise systems within an organisation eg. SAP, TMS. That data is then copied into a secondary data platform as a 2nd step process, to enable the data to be used elsewhere - this became easier to do with improvements in data platforms, but the actual deployment of this is not a trivial exercise.
Wondering in DSV, how “true” is the Enterprise Data Platform today, meaning that is this the central database for ALL its IT systems already today? Or is this still aspirational as an end objective? Or have they taken the Tango database, called that the Enterprise Data Platform, then build all things around that Data Platform - I suspect this is what it, as building this from scratch is not an easy thing at all?
I am interested in this answer as it will drive timing of the CargoWise exit. The more established this Enterprise Data Platform is today, the faster they can get out of CargoWise vs this being mere aspirational and requiring time to build, before CargoWise can come across.
3. Ensuring/enabling scalability for future M&A is definitely a key driver. Another driver could be a future spin off of the IT Organisation to extract value from it. These are 2 clear risks to WTC in this:
- if DSV gobbles up another freight/logistics company who is a WTC customer, that customer will eventually be Tango-ed.
- I also wonder whether DSV is in the early stages of building WTC’s first real direct Cargowise competitor?
4. Both these potentially threatens the (1) extreme stickiness of customers and (2) the lack of direct competition of WTC and weakens the current strong moat. It has been conventional wisdom and a key part of the WTC thesis that customer insourcing of CargoWise and direct competition are virtually unthinkable - this DSV direction now challenges that thinking directly.
5. Following on from (4), has Richard already anticipated the possibility of the moat being threatened via DSV, accelerated by massive improvements in AI, when e2Open came about? The timing of the 2 would have been pretty much in the zone. We always knew that e2Open is absolutely about expanding WTC’s moat, but does the DSV exit provides more clarity as to why it is more important that meets the immediate eye?
6. Could this be an example of how AI is threatening deep-moated SAAS companies like WTC, like never before, as a (sort of) vibe coding example? I think not as DSV is not building a CargoWise-equivalent from scratch. It is using Tango as a very strong functional base from DB Schenker as the replacement platform - that would have been built over years and years. AI just massively accelerates the development effort to make a CargoWise exit endeavour like this now distinctly possible vs being the non-starter it would have been 1-2 years ago from the sheer development effort.
7. Will it succeed? The intended exit from CargoWise is part of not only a huge consolidation/rationalisation of DSV’s IT systems across the entire group, but also a platform rebuild, in parallel almost. There looks to be massive overlap and redundancy across all its IT platforms. The business case makes sense. This is a massive endeavour and will take time. But the strategic intent and the trajectory is clear. Will it succeed remains to be seen.
8. Tango looks to have already been deployed to areas of DSV which have not been on CargoWise - 25% of air/sea volumes. This makes sense to embed Tango into DSV’s operations and prove that it is fit for purpose. But the exercise to migrate CargoWise functionality will be fascinating to keep tabs on. They will need to build the CargoWise interfaces and connectors in Tango first, then migrate over logical process chunks of CargoWise into Tango, then use those interfaces and connectors to keep Tango and CargoWise in synch while it is all in a half-here-half-there state - this could run for years. Ouch, very, very painful operationally potentially. The complexity of this exercise and the disruption risk to DSV’s operations is staggeringly massive from an IT execution standpoint. It is no wonder that the rollout plan is still not locked in. That planning is massive because a stuff up could end up causing a lot of operational grief which can directly hurt DSV as a company.
9. This “inhouse all software” is a massive business risk to DSV. If they stuff it up or it does not work, getting themselves out of that scenario back into external software would be another massive reversal exercise that could cause a lot of business disruption and cost. Would be interesting to monitor DSV’s IT cost in the coming years to see (1) the benefits of the consolidation/rationalistion come through (2) the cost benefits from reducing the use of external IT solutions (3) the ongoing R&D and run cost - this could provide clues as to whether this strategy is working out of faltering, and then extrapolate that to its CargoWise exit.
SUMMARY
I am still working out whether this is the start of the breaking down of the WTC thesis ie. THE global logistics platform, highly sticky, exiting is neigh impossible etc. And thus, bail.
OR this will take years to play out, during which DSV’s approach might falter, change course and they remain entrenched in CargoWise, thus wait and see.
@mikebrisy , would be keen to understand your thoughts on this development and on the above.
-------------------------------------------------------------------------------------------------------------------------------------------------
This is very timely — DSV's Capital Markets Day just happened on May 13, 2026 (yesterday), where they formally confirmed the Tango strategy. Here's a comprehensive breakdown:
DSV & Tango: What It Means and Why It Matters
Background: What Is Tango?
Tango is not a standalone acquisition in the traditional sense — it is the proprietary Transport Management System (TMS) that DSV inherited when it acquired DB Schenker (completed in 2025). Schenker had built and operated Tango as its in-house Air & Sea TMS. DSV now owns the platform outright, including the code, data, and development roadmap.
What Tango Replaces
DSV has historically relied heavily on CargoWise, the TMS product of WiseTech Global (the dominant third-party freight software vendor). DSV has already transitioned roughly 30% of its operations away from CargoWise onto Tango, with further roll-out underway. At DSV's Capital Markets Day (May 13, 2026), the company laid out a "count-to-one" technology strategy, built around reducing third-party software dependency and consolidating onto internally controlled systems. DSV presented a target systems architecture slide showing its Air & Sea division transitioning from "2 TMSs" to "1 TMS", with "CargoWise One → Tango" shown explicitly.
Strategic Benefits
1. Ownership & Control With Tango, DSV owns the code, the data, and the processes. If something doesn't work, it's because of their own actions, not external and unpredictable factors. This eliminates dependence on a vendor's strategic direction and gives DSV full control over its data architecture — critical as data becomes a competitive differentiator.
2. Negotiating Leverage & Vendor Independence Industry sources note DSV doesn't want to be a "hostage" to a vendor's strategy. A tech specialist said: "Even the largest forwarder in the world needs leverage. Jens [Lund] is a smart guy, and in the end it's about negotiation power."
3. AI & Data Platform Foundation DSV is developing a broader data foundation, describing its shift towards an "Enterprise Data Platform" designed to support greater automation and analytics across operations. Alongside this, the group has built an internal "AI Factory" as part of its wider digital agenda, including "Customs AI" and efforts to drive "booking digitalisation." Tango is the operational spine on which all of this sits.
4. Future M&A Scalability In the long term, if DSV plans to acquire more freight forwarders, onboarding will be more predictable, while change management and decision-making are left to DSV itself and not dependent on a vendor's strategy.
Cost Savings
The financial logic is compelling and now quantified:
- Bernstein analysts estimated DSV's CargoWise costs at around DKK 500m (~$78m) a year, potentially rising above DKK 800m once Schenker volumes are fully migrated.
- By 2030, DSV is expecting to generate a further DKK 9bn in savings on top of the DKK 9bn already generated through the DB Schenker takeover synergies. DKK 6bn (~$870m) of this would be derived through leveraging AI and migrating to the Tango and Star TMS systems.
- DSV stated the transition to Tango would deliver "substantial savings" and "significant cost improvement."
IT Consolidation Dividend
Tango is part of a broader rationalisation effort. DSV has consolidated more than 40 acquired data centres into three DSV-operated data centres, and has closed more than 5,000 applications. Tango fits within this "simplify and consolidate" ethos — fewer systems, unified data, lower overhead.
How the Migration Is Being Executed
The approach is deliberate rather than dramatic — a "baby-step" strategy using modern API architecture to migrate gradually and avoid operational disruption, initially deploying Tango in regions where DSV was not already running CargoWise. Approximately 25% of Air & Sea volumes were already running on Tango as of the Capital Markets Day, with the broader rollout beginning in 2027 after further upgrades this year.
The Bigger Picture: A Platform Play
Industry observers suggest DSV isn't simply recreating CargoWise — it is focusing on a "data-first application layer" and then layering on AI, building what some describe as a "headless platform." Rather than rebuilding a traditional monolithic ERP, DSV may be separating its core data architecture from front-end systems, creating a modular platform on which AI and operational applications sit independently.
This is a significant strategic shift: Tango is not just a cost-saving TMS migration, it is the foundation of DSV's ambition to become a technology-driven logistics company rather than a logistics company that uses technology.
@jcmleng that's a great write-up and I think you have grasped the key issues - and the big questions.
At this stage, I am not extrapolating the DSV-Tango risk across the industry, however, I now perceive it as much more of a risk than I did a few months ago. Over the last couple of decades, many if not most of the logistics service providers and transportation companies, have decided that software development is not their thing, and we've seen the development of a vast ecosystem of IT system providers, who over time have largely embraced cloud solutions.
But to challenge this assumption, I've recently done a deep dive into this topic (assisted by BA) and the summary findings are included at the bottom of this post, below the dashed line.
My sense from the research is that across the logistics and supply chain services industry has pretty much every conceivable combination across the spectrumfrom "pure in-house" through "hybrid" to "pure outsourced" of core software architectures. Of course, it is wrong for me to frame this as a one-dimensional continuum, as there is a large universe of business processes that have been systematised, and many, many systems and collections of system and modules, with various integrations. Arguably, the system architecture of every operator is as unique as each fingerprint!
But looking at some of the names in the summary below (some of whom are CargoWise customers) led me to conclude that operators as a collective have retained more systems development capability that I had hitherto considered was the case.
The DSV case is therefore imformative. DSV acquired DB Shenker, who had developed Tango in-house. After a few years, they've have made the decision to roll out Tango to DSV, and not deploy Cargowise from DSV into DB Shenker. With that direction apparently now set, you are right to point out that should they acquire future CargoWise customers, then Tango would be similarly deployed into them. Given the continuing industry consolidation, it is only a matter of time before DSV does the next acquisition. And so one part of the $WTC thesis is under threat. That part of the thesis was that, CargoWise, as the dominant system for Global Freight Forwarders would expand its industry share, as the larger, and more successful firms acquired other firms, and replace their legacy systems with CargoWise.
DSV, as well as some of the other firms identified below, have clearly retained sufficient software development capabilities that they will no doubt also benefit from reduced software maintenance and development costs enabled by AI. Will they be as good as integrating AI agents into their platforms and software specialists like $WTC? Perhaps not, but I can't say for sure.
Not all logistics players will have the strategic option available to DSV. Many - in fact - most, have been "hollowed out" in terms of software development capabilities. Coming back from this would be a journey years in the making, should they decide to, even in an AI age. More generally, I think any overall trends in the industry from outsourced to insourced software development is going to evolve over years, and possibly decades. How much AI and Agentic AI proves to accelerate any potential change remains to be seen.
However, this case has been an orange flag for me. You see, information is what enables logistics and supply chain services firms to function. The more firms can leverage information across the supply chain, the better and more value-adding services they can offer customers. Given this, it should come as no surprise that several logistics and supply chain firms have retained in-house software development capabilities, and spent decades developing their own systems.
My Current View on $WTC
With the recent upheaval in the SaaS sector, I have made major changes in my RL portfolio, and I now have a very small position in $WTC (less than 1%)
Disc: Held (less than 1%)
----------------------------------------------------
Summary of Research (by ChatGPT, edited by Mikebrisy)
A review of publicly-available sources shows that genuinely proprietary, operationally material systems do exist among major logistics companies, but they are less common than marketing language about “digital platforms” might suggest.
The clearest large-scale cases are C.H. Robinson’s Navisphere, Expeditors’ internally designed technology platform now surfaced as EXP.O NOW and related applications, J.B. Hunt’s J.B. Hunt 360°, UPS’s ORION family, Delhivery’s CoreOS logistics operating system, Yamato’s Yamato Digital Platform, Nippon Express’s proprietary WMS/DCX WMS, DP World’s CARGOES suite and Zodiac terminal operating system, and CJ Logistics’ proprietary WMS / end-to-end logistics IT stack. DHL Global Forwarding’s myDHLi and Kuehne+Nagel’s myKN are also important, but for those firms the public sources reveal the customer-facing layer more clearly than the full internal operating backbone.
The strongest evidence comes where official sources explicitly use terms such as proprietary, self-developed, in-house, or connected to our own TMS. Under that standard, Delhivery, C.H. Robinson, Nippon Express, GEODIS, CJ Logistics, DP World, UPS and Yamato disclose the most direct language. Expeditors sits slightly differently: its 2023 annual report says the platform is “designed, coded, tested and implemented” by Expeditors’ logistics and technology personnel, while also noting that the stack includes proprietary, third-party and open-source technologies; that still qualifies as an internally built operating platform rather than an outsourced freight-forwarding package.
A second major finding is that “proprietary” rarely means “isolated.” Even the strongest in-house platforms are built to interoperate with customer TMSs, partner networks, APIs, EDI, middleware, devices, and sometimes external financial or customs ecosystems. The differentiator is not total technical isolation; it is whether the logistics company owns and controls the operational core, the data model, the workflows, and the roadmap for the principal activity. That pattern is especially visible at C.H. Robinson, J.B. Hunt, GEODIS, Kuehne+Nagel, Delhivery, Nippon Express, DP World and CJ Logistics.
A final analytical point is that many leading firms have evolved from a first generation of quote-book-track portals into a second generation of broader operational systems that add analytics, carbon reporting, visibility, optimization, AI, and partner collaboration. The best-documented examples are myDHLi, myKN, IRIS 3.0, J.B. Hunt 360°, Navisphere’s recent Lean AI expansion, Delhivery’s CoreOS, and UPS’s progression from ORION to UPSNav and Dynamic ORION.
OK, so I put this through Claude to follow up from my previous straw:
Can you extract as much as possible on the history of Tango under DB Schenker. Am interested in how long it took to build it, the effort and cost of the build, the scope of functionality, how long it has been operational etc. I am trying to establish what the effort and elapsed time might look like if another global freight forwarder wanted to build a Tango-like solution, then use that to exit out of WTC's CargoWise.
It is a sobering read and probably explains why DSV HAS to make something out of Tango ... My takeaways:
- This is pretty much what I expected to read in terms of length of time, complexity and cost, but going back to 2005's was still a bit of a shocker
- Another Tango wannabe is not likely - it will be insane to try, even with current AI agent dev capability - it is the complexity that will kill
- Migrating out of CargoWise is not a done deal - there is almost no precedent of something like this happening, firstly, and ending well, secondly
- With Tango's history, the complexity of the CargoWise exit and the DSV Enterprise Data Platform concept just went up several notches - databases and software that was built in the 2010's are not quite wired up for seamless operations in today's cloud-based world. There will need to be a core body of work to bring it up to current open data standards in an operational environment, before any specific CargoWise work can begin. This will be sped up with AI, for sure, but it still needs to be done first.
- I won't be investing in DSV, given the sort of risk it is taking with Tango ...
With this insight, I am going to continue to HOLD WTC at my current 3%-ish allocation, but not add at this stage.
-----------------
The History of Tango Under DB Schenker — and What It Means for Others Wanting to Follow Suit
Origins: A Failed First Attempt, Then a Clean-Sheet Build
At the dawn of the new millennium it had already become evident that the IT used for DB Schenker's transport management would not be sustainable in light of growing volumes and requirements. The company planned and launched a project to modernise the complex system landscape. During the implementation, DB Schenker commissioned Capgemini to conduct an audit — which resulted in the immediate stop of the ongoing modernisation and the development of a completely new solution approach. Featuredcustomers
This is a crucial piece of history. Schenker's first attempt failed and was abandoned. As Schenker CIO Peter Schumann put it at the time: "Following our first attempt on the cheap, for TANGO we now decided on the BMW." Featuredcustomers
The clean-sheet rebuild — what became Tango — was started from scratch with Capgemini as the primary development partner, following the failed first attempt in the early 2000s.
The Name and Scope
The new solution received the name "TANGO", short for "Transport Application for Air and Ocean Freight Network and Global Operations." TANGO replaces more than 32 legacy systems and, as the single, central system worldwide, supports the harmonised processes of the air and ocean freight business. The solution covers the entire end-to-end process of transport transactions — from order to invoice generation. In addition, it enables a consistent analysis of the transport chain in terms of costs, revenues and process quality. Featuredcustomers
The Build: Team Size, Partners, and Architecture
The Capgemini case study is the most concrete public source on build effort:
The project team implementing TANGO included up to more than 300 employees, 100 of them from Capgemini alone. The latter were responsible for large shares of the software development, while the definition of requirements was delivered by DB Schenker. The software developers of Capgemini worked from five locations in Germany, Poland and India — an onshore/nearshore/offshore model Capgemini calls its "Rightshore" approach. Special project tasks also involved companies such as DB Systel (operations) and Sogeti (acceptance tests). Featuredcustomers
Sustainable software architecture was one of the high-level requirements. Based on QUASAR, Capgemini developed a sophisticated application architecture with clearer demarcation between responsibilities and functional components. This client/server architecture helped make TANGO independent of third-party products. TANGO was developed with modern methods and technologies including Java 6 and platforms such as Linux and Oracle WebLogic, designed to deliver high performance 24x7. Featuredcustomers
Timeline: When Was It Built and How Long Did It Take?
The documentary trail gives us good triangulation points:
Early 2000s: First modernisation attempt begins and is abandoned after Capgemini audit.
Mid-2000s (estimated ~2005–2008): Second attempt begins — the clean-sheet TANGO build — with Capgemini. The Capgemini case study was copyrighted in 2012, indicating the project was substantially complete around that time.
2009: The TANGO System Navigation document carries an original revision date of 31 July 2009, indicating the system was being deployed and trained out by that year. The document shows a copyright of "Schenker AG 2009/2022" confirming the original system dates to 2009. Slideshare
2012: Capgemini publishes its case study, suggesting the major development phase wrapped around this period. After project completion, TANGO was projected to be available to about 12,000 concurrent users in nearly 130 countries. Featuredcustomers
2022: TANGO System Navigation documents show active training and deployment continuing (February 2022 versions).
2023: LinkedIn evidence from a DB Schenker implementation team member confirms TANGO was still being rolled out to air operations in the US in 2023, describing joining the "TANGO Air Implementation Team" for a system "rolling out in 2023." LinkedIn
Bottom line on timeline: From initial concept (early 2000s) to functional global deployment, Tango took approximately 15+ years — factoring in the failed first attempt, the clean-sheet rebuild (~5–7 years of core development), and an extended global rollout phase that wasn't fully complete until the early 2020s. Even from the successful second attempt alone, the core build phase was roughly 7–10 years.
Functional Scope
Based on the navigation documents and case study materials, Tango's functional scope is comprehensive:
The system covers: Purchase Orders, Shipping Orders, Air Import/Export shipments (Master and House), Ocean Import/Export shipments, Gateway/Hub-oriented shipment overviews, land shipments (outside normal Air/Ocean), report generation, and EDI-submitted orders. Slideshare
The Navigation Area includes: workflow/landing page management, master data maintenance (countries, external partners, departments), document archive (O&DM), a Rate & Contract Management module (RCM) for buying and selling rates, and financial management for shipments including incoming vouchers and accumulated vouchers. Slideshare
In short: it is a full-featured global TMS covering bookings, documentation, customs, financials, rates management, and reporting across air and ocean freight worldwide.
The "Tango 2018–2020 Problem" and Subsequent Revival
An industry source noted: "Everyone remembers Tango in 2018–2020" — a period when the system was apparently struggling or underperforming — "but few saw the enormous work done since late 2021, when the company was starting to prepare for the sale." The implication is that significant reinvestment and re-engineering happened from 2021 onwards, specifically as DB Schenker prepared itself for divestiture from Deutsche Bahn, making Tango more attractive to a potential acquirer. The Loadstar
This is a significant detail. Tango was reportedly in a difficult patch before being actively rebuilt and modernised in anticipation of the sale process.
What It Would Take for Another Forwarder to Replicate This
The Schenker/Tango story is actually part of a sobering industry pattern of in-house TMS builds. In-house solutions have a poor track record in freight forwarding. Panalpina, Nippon Express and DHL Global Forwarding each lost over a hundred million dollars in failed builds, before writing them off and resorting to CargoWise instead. The ultimate cautionary tale was DHL, which is thought to have spent $1bn on its failed system. Its consultant IBM tried to build a fully functioning modern forwarding environment on top of SAP, but this proved impossible. The write-down was taken in November 2015, and DHL immediately signed up with CargoWise. By May 2017 it was beginning its CargoWise rollout, with global completion taking another four to five years. Substack
For another global forwarder wanting to build a Tango-equivalent from scratch today, the evidence suggests:
The Key Insight for Any Forwarder Considering This Path
DSV didn't build Tango — it acquired it via the Schenker deal, getting a battle-tested, decade-old, globally deployed system as part of a €14.3bn transaction. The "build your own TMS" strategy has a near-perfect failure rate in this industry at scale. The smarter framing of what DSV achieved is not "build vs. buy from WiseTech" — it is "buy a company that already built it over 15 years." That is a fundamentally different proposition from any competitor attempting a greenfield equivalent today.