CASE STUDY
Replacing BizTalk in Production —
The Transdev Migration
Replacing BizTalk in Production —
The Transdev Migration
How to replace BizTalk without disrupting operations.
Transdev operates large public transport systems where vehicles, operational platforms and passenger services constantly exchange data.
In Sweden alone, thousands of vehicles depend on integrations running reliably behind the scenes.
Keeping that digital infrastructure stable is just as critical as keeping the buses running.
CLIENT: Transdev Sverige AB (www.transdev.se)
INDUSTRY: Public Transport & Mobility Services
SOLUTION SCOPE:
Integration platform transition |
BizTalk replacement
OUTCOME IN SHORT:
- 300+ BizTalk integrations transitioned in production
- 40+ connected systems kept running
- Phased transition with no disruptive cutover
- Reduced dependency on legacy middleware
THE BACKGROUND
When the backbone starts showing its age.
For organizations operating large-scale public transport systems, digital infrastructure is as critical as the vehicles themselves.
At Transdev, more than 40 connected systems exchange information across planning, ticketing, vehicle data, reporting and other operational processes.
For many years, BizTalk handled a large share of those integrations.
And it worked well.
Until the environment started showing the usual signs of age.
Changes became slower.
Deployments became heavier.
And the platform itself was approaching the end of its lifecycle.
With 300+ integrations running across a live transport operation, replacing BizTalk was not something you schedule for a quiet weekend.
Large integration environments rarely appreciate surprises.
THE CHALLENGE
When a big-bang migration is just too big a bang.
Integration environments have a habit of accumulating dependencies over time.
New systems appear.
Old integrations stay because they still serve a purpose.
Dependencies quietly multiply.
Some are well documented. Others introduce themselves the moment you try to change something.
At Transdev, replacing BizTalk meant changing integrations that were already part of a live operational environment. Real-time flows, vehicle platforms and business-critical systems all had dependencies that needed to keep working throughout the transition.
Moving everything in one cutover would have meant changing too much at once — making each step harder to validate, isolate and, if necessary, roll back.
And in public transport, operational disruption is not particularly abstract.
Passengers tend to notice.
The real challenge was therefore not simply replacing BizTalk.
It was how to evolve the integration architecture while operations continued as usual.
THE APPROACH
Replace the platform. Keep the operations.
Instead of replacing the platform in one step, Transdev adopted a controlled transition model.
Ghost Nodes was introduced alongside the existing BizTalk environment, allowing both platforms to run in parallel.
New integrations and automation flows were implemented in Ghost Nodes while existing BizTalk integrations continued operating.
This made it possible to move gradually:
- new integrations could be built without disturbing existing ones
- legacy flows could be redesigned and moved one by one
- each flow could be validated before traffic was shifted
- BizTalk remained available throughout the transition
Instead of rebuilding hundreds of integrations across 40+ connected systems at once, the architecture evolved step by step.
BizTalk remained operational throughout the transition — but as more flows moved to Ghost Nodes, fewer depended on BizTalk.
Around 70 % of the migration work was carried out by Transdev’s own IT team — not because they had to, but because they could.
Ghost Nodes allowed the team to move integrations step by step without depending on external consultants for every change.
That meant the transition did more than replace technology. It also moved more integration capability and ownership inside Transdev.
Eventually, BizTalk became less and less relevant to daily operations until the remaining dependencies could be retired.
Which is usually how infrastructure transitions work best: quietly.
THE RESULT
From big-bang risk to controlled transition.
The transition allowed Transdev to replace BizTalk gradually while keeping the operational environment running throughout.
Key outcomes included:
- 300+ BizTalk integrations transitioned in production
- Around 70 % of the migration work carried out by Transdev’s own IT team
- No disruptive big-bang cutover
- Reduced operational complexity across the integration layer
- Improved visibility and traceability across integration flows
- Faster implementation of new integrations and automation
- Less dependency on legacy integration infrastructure
The most important result was not simply that BizTalk could be replaced.
It was that the replacement could happen while the systems around it continued doing their jobs.
Passengers, drivers and control centers did not need to care which integration platform was handling the flows underneath.
Which, for a migration involving 300+ integrations, is rather the point.
Transdev demonstrated that replacing BizTalk does not have to mean putting hundreds of integrations — or the operations depending on them — through one high-risk cutover.
Replacing BizTalk rarely happens overnight.
The good news is that it doesn’t have to happen all at once either.
Planning a BizTalk replacement?
Does your environment look something like this?
- Hundreds of integrations
- Critical dependencies
- A platform that needs to go
- Operations that very much need to stay
Not convinced yet?
Have a look at some of our other case studies.
