Why Logistics Digitisation Stalls, and What Actually Works
Most logistics transformations fall short, and the software is rarely the reason. The frontline, the legacy system and the order you do things in decide the result. Here is what works.

The short version: Logistics digitisation projects stall mainly because of people and integration, not technology. Gartner's survey of 306 logistics professionals found that 76% of logistics transformations never fully succeed, missing budget, timeline or KPI targets, and that internal resistance did more damage than outside pressure. Two causes keep coming back. The people who capture the data at the frontline are brought in too late, so the new tool adds work for them and workarounds appear. And the new system has to talk to older ones, which is underestimated. What works is smaller than most plans: pick one workflow that hurts today, start with the people who do it, plug the new capability in alongside the systems you already run, and prove one measurable gain before you widen the scope. Replace a core system only when it is the thing blocking you.
IN THIS ARTICLE
- What does logistics digitisation actually mean?
- Why do so many projects stall?
- What happens at the frontline?
- What do the projects that stick have in common?
- Should you replace your system or plug something into it?
- When does replacing make sense?
- What does a soft integration look like on a wharf?
- What is a sensible first step?
- What else do people ask?
What does logistics digitisation actually mean?
Logistics digitisation means replacing manual, paper-based or email-based steps with structured data that systems can use. It is narrower than digital transformation, which also changes processes, roles and business models. In practice it touches transport management systems (TMS), warehouse management systems (WMS), enterprise resource planning (ERP) software, terminal operating systems (TOS), and the people who feed all of them with data.
Why do so many logistics digitisation projects stall?
The industry does not lack ambition. In a Gartner survey of 306 logistics professionals at organisations with $500 million or more in annual revenue, run in November and December 2023 and published on 1 August 2024, 81% of logistics leaders said transformation is critical. Yet 76% of logistics transformations never fully succeed, meaning they miss critical budget, timeline or KPI targets.
The newer wave of AI projects shows the same pattern. The Loadstar and Raft report The State of AI in Supply Chain 2026 surveyed more than 200 supply chain executives and practitioners worldwide. Only 22.2% had tangibly deployed AI at scale, while 43.2% were still experimenting or had not started. The biggest blocker to scaling, at 53.8%, was a lack of in-house AI expertise and change management. Lack of integration with existing systems came second, at 48.7%. Raft is an AI software company, so read its conclusions with that in mind. The survey figures themselves are still a useful snapshot.

What happens at the frontline that the project plan misses?
In logistics, the data starts with a person. A checker on a wharf, a driver at a gate, a clerk keying a booking, a yard operator confirming a move. Every dashboard, forecast and emissions report downstream depends on what that person records, and on whether recording it is easier or harder than it was last month.
When a new tool adds steps for that person and returns nothing to them, workarounds start. A photo of a form is sent over messaging. A spreadsheet is kept on the side. The official system gets updated later, in a batch, by someone else. The project then reports a go-live, and the data that matters is still late and double-handled. Between companies the habit runs deep too. A Deep Current survey of freight forwarders, 3PLs and mid-sized carriers in Europe and the Middle East, run in the first half of 2025, found that 61% of logistics teams still depend on emails and spreadsheets to communicate with overseas partners. Deep Current sells workflow automation software and did not publish its sample size, so treat the figures as indicative.
Gartner's research points to a way through. Internal resistance to change did more to obstruct transformations than outside pressure did. Only 20% of logistics leaders used resistance as a resource, and effectively responding to team resistance and incorporating feedback raised the odds of success by 62%. An urgency-led approach built on directive leadership and limited stakeholder engagement cut the odds of success by 47%. Resistance at the frontline usually carries a real message: the tool does not fit how the work is done, connectivity is unreliable, or nobody explained what the person gets out of it.
What do the projects that stick have in common?
There is no formula, but the projects that hold up tend to share a handful of habits. The first three below are patterns from our own deployments and conversations rather than statistics. The last two are backed by the research cited.
- They start with a job someone already dislikes. Re-keying a delivery note, chasing a container status, rebuilding the same report every month. Pain that people already feel is the best adoption plan there is.
- They involve the frontline before the tool is chosen. The person doing the task walks through it, and the first design is tested in their conditions, including poor signal and gloves.
- They give something back to whoever captures the data. A faster handover, one fewer form, a clearer shift summary. If only head office benefits, adoption fades.
- They listen to resistance. Gartner found that responding to team resistance and building feedback into the plan raised the odds of success by 62%.
- They measure one thing. In the Loadstar and Raft survey, 62.8% of respondents had not measured the return on their AI investment or were unsure how to. A single measure agreed up front, such as the time from event to record, avoids that.
Notice what is missing from the list: a large, multi-year programme. The common thread is a small first step that someone can see working.
Should you replace your logistics system or plug something into it?
This is the question behind many stalled projects, and it is often answered too early and too broadly. A replacement feels decisive. It also puts everything connected to the old system at risk at the same moment. Panorama Consulting's guidance on TMS failure (May 2026) says that ERP-to-TMS and WMS-to-TMS integrations carry more implementation risk than almost any configuration decision, and that requirements gathered after a vendor is selected are retrofitted to a contract.
Operators appear to lean toward the lower-risk route. In the Deep Current survey, 49% preferred modular tools that plug into their existing systems, and 47% named integration with legacy systems as their biggest barrier. A 2026 paper on the Port of Trieste by Gallo and Borruso, “Process-Oriented Digitalization in Port Systems”, found that the port community system and terminal operating systems interoperated poorly, leaving duplicated tasks and manual work. The authors built a digital process orchestration tool designed as an intermediate layer of integration between existing systems. Applied to the access process for departing lorries, it reduced operational times and errors.
|
|
Plug something in |
Replace the system |
|---|---|---|
|
Fits when |
The system works, but one step is manual, late or invisible |
The system cannot support a workflow you need, or is near the end of its contract or support |
|
Main risk |
One more tool to maintain, and data that must map cleanly |
Migration and integration risk across everything connected to it |
|
Who it disrupts |
Mostly the team at that one step |
Everyone who touches the system |
|
How you know it worked |
One named measure improves at that step |
The old system is off and nothing broken |

When does replacing the core system make sense?
Sometimes it is the right call. The contract is ending, the vendor can no longer support what you need, or the data model makes a required workflow impossible. If any of those is true, replace it.
Even then, the order matters. If clean, structured data is already being captured at the frontline by a layer that sits outside the core system, the migration has better data to move and the people on the ground do not have to change how they work on cutover day. Plugging in first can make the later replacement easier. That is our judgement rather than a rule, and it depends on your systems, but it is worth testing before committing to a big-bang switch.
What does a soft integration look like on a wharf?
CaDi is a data layer for low-carbon logistics. It captures an operational event once, calculates what that event means, and distributes the result to the systems that need it. It is built to sit alongside what an operator already runs, for example by pulling shipments from a customer's CargoWise instance through a scheduled file transfer or an API, rather than replacing it.

Three design choices matter here, and they apply to any tool you evaluate. Capture works offline and syncs when there is signal, because docks and yards often have poor connectivity. The person capturing the data sees the benefit in their own day. And the output goes to the systems people already trust, so reporting does not depend on anyone switching tools. Once the event is captured well, the same data can also feed emissions reporting, which is why CaDi exists, but the operational gain comes first.
What is a sensible first step?
Keep it smaller than feels ambitious.
- Pick one workflow. Choose the one where data is late, double-handled or reconciled by hand.
- Walk it with the person who does it. Ask what they do today, what slows them down and what they would never give up.
- Check what your current systems can already export. A file, an API or a scheduled report is enough to start.
- Agree one measure. For example, the time between something happening and it being recorded.
- Decide replace-or-plug-in after that, with evidence. By then you will know whether the core system is really the constraint.
What else do people ask about logistics digitisation?
Why do logistics digitisation projects fail?
Mostly because of people and integration rather than technology. Gartner found that 76% of logistics transformations never fully succeed, missing budget, timeline or KPI targets, and that internal resistance obstructed them more than outside pressure. Frontline staff are often brought in too late, and new systems have to connect to older ones.
How do you get frontline staff to adopt new logistics technology?
Involve the people who do the work before the tool is chosen, test the first design in real conditions such as poor signal, and make sure the person capturing the data gets something back, like a faster handover or one fewer form. Gartner found that responding to team resistance and incorporating feedback raised the odds of transformation success by 62%.
Should I replace my TMS or ERP, or integrate a new tool alongside it?
Plug in when the system works but one step is manual, late or invisible. Replace when it cannot support a workflow you need, or is near the end of its contract or vendor support. Plugging in disrupts one team rather than everyone connected to the core system, which is why it is usually the lower-risk first move.
What do successful logistics digitisation projects have in common?
They start with a job people already dislike, involve the frontline early, give something back to whoever captures the data, listen to resistance, and agree one measure up front. They also start small, with one workflow rather than a multi-year programme.
When does replacing a core logistics system make sense?
When the contract is ending, the vendor can no longer support what you need, or the data model makes a required workflow impossible. Even then, capturing clean data at the frontline before migrating can make the replacement easier.
What is a sensible first step in logistics digitisation?
Pick one workflow where data is late, double-handled or reconciled by hand. Walk it with the person who does it, check what your current systems can already export, agree one measure, and decide replace-or-plug-in afterwards, with evidence.
Does digital data capture work where connectivity is poor, such as ports and yards?
Yes, if it is designed offline-first: events are captured on the device and synced when a connection returns. CaDi works this way, and at JVPS in Papua New Guinea container movements are captured offline at the wharf.
Bring one workflow and a sample export
If you want to see how this works on your own data, we can walk through one workflow with you, using a sample export from the systems you already run. No replacement, no rip-out, and no commitment beyond the conversation.

