The Situation
A business-critical workflow was running on a legacy BPM platform that had quietly become a problem. The process logic was scattered across components only a small group of people fully understood. Extending it required scarce external expertise, with lead times and costs that made every change harder to justify than the last. Internally, the team needed to move faster and understand the process better — but the platform was not letting them.
A new seasonal business requirement made the situation urgent. The affected workflow had to be updated before the seasonal sales period, and missing that window would have had a direct revenue impact. Continuing on the legacy platform meant accepting whatever timeline and price the external specialists could offer. That was no longer acceptable.
My Role
From the start, the project had a clear constraint: deliver the seasonal change without continuing on the legacy platform. That direction shaped everything that followed — the choice of Camunda as the new engine, the decision to migrate now rather than absorb another expensive change request on the old platform, and the operating principle that whatever was built had to be something the internal team could own afterwards.
From there, my contribution moved across operations, process analysis, technical coordination and cloud enablement. I maintained and analysed the original BPM solution, reverse-engineered the existing workflow and translated the logic into BPMN models that could be reasoned about openly. Together with a colleague from the process team, I helped optimise and extend the workflow against the new business requirements rather than mechanically copying the old behaviour.
I prepared the Azure environment for the new Camunda-based solution, supported deployment, tested the implementation and validated process behaviour against expected outcomes. The external development partner was learning parts of the Camunda and BPMN model during the project, so I actively reviewed, corrected and tested the workflow to keep the implemented behaviour aligned with the business process — not just with the partner’s interpretation of it.
A significant part of the work was integration. I configured routing in the service bus layer so the legacy BPM platform and the new Camunda solution could coexist during the transition. The role required connecting layers that often live in different teams: business requirements, BPMN modelling, legacy platform behaviour, integration routing, Azure deployment and operational testing.
The Problem
The surface problem was technical: a business-critical workflow on a legacy BPM platform that had become difficult to maintain, extend and operate.
The deeper problem was ownership. A core process had quietly drifted into a state where the organisation could not change it on its own terms. Lead times, cost and direction were effectively set by external specialists with the relevant legacy expertise. New requirements had to be negotiated, scheduled and paid for at someone else’s pace.
A business cannot afford to lose ownership of a business-critical process.
The challenge was not only to deliver the seasonal change in time. It was to use the migration as an opportunity to bring the process — its models, its behaviour, its operational knowledge — back inside the organisation.
Architecture Decisions and Trade-offs
The decision was to migrate from the legacy BPM platform to Camunda, deployed on Azure, using a deliberately pragmatic approach rather than a clean-slate rewrite.
Reverse-engineer before replacing. The existing workflow had to be understood before it could be safely changed. The process was analysed, reverse-engineered and translated into clearer BPMN models — which became the working artefact for everything that followed.
Optimise the process, do not copy it. The goal was not to recreate the legacy workflow one-to-one. Together with the process team, the workflow was reviewed, simplified and extended against the new business requirements. A migration is a rare opportunity to question what the process should do, not just where it should run.
BPMN as a shared language. Camunda allowed BPMN to be treated as an executable model, not just documentation. That changed the conversation between business analysis and implementation: the diagram and the running process were the same artefact.
Parallel run over big-bang migration. Active process instances were allowed to finish on the legacy platform. New and changed flows started on Camunda. Routing logic in the service bus directed each request to the correct engine based on process identifiers. This avoided unnecessary migration of in-flight instances and reduced the risk of disturbing live business operations during a tight delivery window.
Internal ownership over supplier dependency. The team accepted a learning curve with a new platform instead of continuing to depend on external specialists for every major process change. This created short-term delivery pressure but gave the organisation control over future changes.
Pragmatic delivery over perfect implementation. The seasonal deadline was not negotiable. The project prioritised a working, testable solution over a slow, ideal migration. Minor issues surfaced during rapid development, but they were identified, corrected and stabilised before the platform settled into long-term operation.
What Made It Work
Treating BPMN as the source of truth. Once the workflow was modelled clearly enough to be executed, conversations between business and IT became sharper. Disagreements pointed at specific elements in the diagram rather than at vague descriptions of “the process.”
Reviewing the partner’s work, not just receiving it. Rapid delivery with a partner still learning the new platform meant the implementation needed active correction during the project, not just acceptance testing at the end. Catching issues early kept the timeline realistic.
Keeping both engines running on purpose. The temptation in any migration is to rush every instance onto the new platform. Letting active instances finish on the legacy engine reduced risk, simplified testing and let the team focus on getting the new solution right rather than on edge cases of in-flight migration.
The Outcome
The migration was completed within roughly half a year, with the most intensive development phase compressed into a few months. A business-critical workflow moved from a difficult-to-maintain legacy BPM platform to a Camunda-based solution running on Azure. The new platform made the process easier to understand, modify, test and deploy.
The result was not only cost avoidance, although the cost picture changed significantly. The bigger outcome was ownership. The internal team gained working knowledge of the BPMN models, process behaviour, integration flow and operational requirements. Future changes were no longer gated by the availability of scarce legacy specialists.
The project also demonstrated the practical value of BPMN as a shared language. Once the process was modelled clearly and executed through a standards-based engine, the organisation could reason about the workflow more transparently and make changes with greater confidence.
What I Took From It
A BPM migration is rarely just a platform replacement. The technical move from one engine to another is the visible part. The valuable part is the recovery of process knowledge, internal ownership and delivery capability — all of which had quietly been outsourced along with the platform itself.
The parts worth doing differently next time: more focused load testing under realistic seasonal traffic, and stricter discipline on keeping integration patterns simple. The implementation worked, but some of the routing and integration logic carried more complexity than the process actually required — a consequence of rapid delivery rather than deliberate design. Holding the line on simplicity, and questioning each layer of integration against what the workflow really needed, would have produced a cleaner result without adding effort.