The Ultimate Guide to Migrating from a Legacy Business Process Management Suite (BPMS)

Learn the benefits, key considerations, and technical steps to transition from a BPMS successfully.

Guide to Achieving a Legacy BPMS to Camunda Migration

When organizations first set out to automate business processes, many may have purchased a traditional business process management suite (BPMS). In time, teams find that these products are not suited to the modern world of process automation, which requires agility, scalability, and openness. With the rise of cloud infrastructure, containers and microservices-based application development, the inflexibility of legacy BPMS becomes a blocker to development teams’ progress and innovation. When left unchecked, this technology can also translate into ineffective or delayed customer experiences. 

Why? Legacy BPMS, which are also known as iBPMS, rely on closed architectures and a proprietary approach to development, which limits business agility and makes it difficult and expensive to make changes. These systems can’t scale dynamically in response to business demand, which means they often cause performance issues that negatively affect customers. And they don’t provide the tools teams need to continuously improve processes.

A modern approach to process automation gives development teams the open, API-first architecture to use the tools they want, on their terms. Rather than locking in to proprietary development methodologies, this approach makes it easier and faster to design processes, using a widely known process modeling standard called BPMN. Once the processes are modeled, a universal orchestration layer “drives” even the most complex processes in production – across people, systems and devices. Process orchestration is built to support both short- and long-term business processes that run for hours, days, weeks, or even months.

So, if your organization is using a legacy BPMS, what are the most important considerations to make before migration? How do you get started with migrating to a modern process orchestration solution like Camunda? This guide will walk through the steps to achieving a successful migration, including both the cultural and technical aspects of this facet of digital transformation. Let’s dive in.

Key considerations for BPMS replacement

For many organizations, overcoming inertia can be the biggest issue in replacing a legacy BPMS. The time and effort required to migrate might seem too much to take on. And, it may seem difficult to interrupt complex, long-running processes to move them to a different platform. But the temporary process of modernization almost always outweighs the risks of doing nothing. 

Download Whitepaper: Replacing Legacy BPM: Solution Selection Factors

Throughout this guide, we’ll look at practical examples of companies that have successfully completed their migrations. You’ll find that many of these organizations were running their processes on decades-old, monolithic systems that slowed down the development lifecycle. One company, Deutsche Telekom, was facing 12+ month timelines to develop new features into production for customers, and found themselves limited by their legacy vendor’s inflexibility. Across the board, the forcing function for migration was to not just keep up with development timelines, but meet and exceed sky-high customer expectations.

With that said, it’s important to evaluate the features and benefits of a new process automation and orchestration solution. Here are some of the most critical considerations for these technology providers. 

Source: PeerSpot, Replacing Legacy BPM, Solution Selection Factors, 2021.

Speed for designing and deploying processes

Rather than having to wait months or years to design and deploy a new process, a new solution should empower development teams to move quickly, and enable industry best practices around continuous delivery. In fact, when evaluating a process automation and orchestration solution, you should be able to quickly set up a proof of concept (PoC) to evaluate its efficacy – even within a few days to a week, depending on the process’ complexity. We’ll cover more about the PoC process later. From there, it should be easier to understand how to migrate your existing processes (if possible), or remodel them to work effectively in a new environment. 

Simplicity with BPMN and DMN

Look for a solution that supports open standards such as BPMN and Decision Model and Notation (DMN). These standards add simplicity to defining processes, rules and workflows – making these concepts easier to understand across both IT and line-of-business stakeholders. A platform should also allow for continuous process improvement, making it easy to identify bottlenecks in your processes and quickly resolve them. 

This simplicity helps with getting started, change management, and maintenance. Ideally, a new system should empower existing teams, and should not require proprietary expertise to run. In fact, the total cost of ownership (TCO) of the new solution should be much lower than legacy BPMS, thanks to its ease of use.

Flexibility and collaboration

With a rise in remote work and distributed teams, flexibility and collaboration capabilities become especially important. Using the BPMN and DMN standards, teams should be able to collaborate, share logic about process rules, and more regardless of their location or level of expertise. From there, process orchestration tools should work seamlessly within developers’ existing toolchains, including a preferred IDE or version control system like Git. Ideally, these solutions should fit neatly within a modern, agile software development lifecycle (SDLC). 

Open, API-first architecture

When selecting a new solution, developer friendliness is key. Beyond the open modeling standards mentioned above, a platform should support software communication protocols and standards such as JSON and open APIs. APIs represent a fast and easy-to-change approach to headless process automation. In addition, they make a platform extensible with the tools developers prefer to use. Look for a modular design that can run on public, private, or hybrid cloud, and that works with modern technologies such as Kubernetes and Kafka.

Prepping your organization for a BPMS migration

Once you’ve decided to undertake a BPMS migration, it’s important to prepare for both the cultural and technical changes that are about to take place. Typically, there are many different stakeholders involved in process automation, including developers, enterprise architects, IT decision-makers, and line of business leaders. As a result, this type of project requires IT and business stakeholder alignment. 

For Indiana Farm Bureau Insurance, stakeholder buy-in was a critical first step to kicking off their migration. The development team had worked extensively with the previous BPMS, and originally had a, “If it’s not broken, don’t fix it” mentality. To change the developer mindset, it was important to clearly communicate the big picture business benefits to this team. For example, experienced senior developers wanted to know their work would be valuable, and that they’d be delivering something beneficial for the business end user. 

Next, with the help of a consultant, the team dove into their first process design PoC. A PoC should help your team: 

• Verify that a specific approach or tool works within your scenario
• Showcase an example that gets internal stakeholders to buy into a larger automation effort
• Work through granular questions before kicking off a larger effort.

Read more: Doing a Proper PoC

Jarvis Ka, enterprise architect at Indiana Farm Bureau Insurance, stressed the importance of setting expectations with the development team on the time required to get an end-to-end process automation system into production. This involves adjusting expectations at both the scrummaster and project manager levels. Many of these manager-level stakeholders may be resistant to change, so it’s important to explain how existing processes will transition to the new system. For example, a line of business manager might be concerned about how the user experience (UX) might change for the end-user when filing a new mobile insurance claim. 

To cut down on resistance and demonstrate these changes, Ka and his team highlighted BPMN diagrams created during the PoC phase, and annotated them with more information describing each task in the process. From there, they created PDFs and sent them to each business stakeholder. This cut down on the number of meetings required by giving them a visual representation of process workflows in the new process automation and orchestration system. 

Often, process automation migrations are a part of a larger IT modernization effort. Depending on the size of the company, the migration process may either be handled by a larger Center of Excellence (CoE) or just a few IT stakeholders, such as an enterprise architect and a small team of developers. Either way, it’s critical for a focused team to drive the migration process, ideally by starting small with a PoC. From there, this team’s role is to:

• Equip the larger development team to use the system
• Help line-of-business leaders understand that processes might look different (including UIs and process flow)
• Enable relevant teams to use the automated processes and request changes if needed.

Technical steps to completing a BPMS migration

The guide below is intended for organizations migrating from a legacy BPMS system to Camunda, which uses the BPMN 2.0 standard for process definition and deployment. If you’re migrating from a BPMN-based system to Camunda, your journey will be much easier than if you’re using proprietary BPMS process definitions. Even so, this general framework should serve as a good foundation for the migration process. 

Step 1: Migrate process definitions

Typically, it’s better to remodel existing processes, rather than completing an automated conversion. Often, the number of process definitions is limited. That means it often takes less time to remodel processes than to create and test an automated conversion. Typically, modeling one process at a time (e.g. completing the process for a PoC) can give you a better feeling of how much effort it takes to migrate process definitions in your environment, with the talent you have.

By remodeling processes, you can also leverage the full power of BPMN 2.0, and improve upon existing processes that may not have been revised in years. 

In some cases, it may make sense to use the tools Camunda’s consulting team has created to migrate process flows from IBM BPM, IBM Blueworks Live, Oracle, Pega, and TIBCO. These migration shortcuts can be found here on GitHub. To be clear, none of these tools are intended to be a “silver bullet” that will transform applications from one vendor to another at the click of a button. 

Typically, these tools will generate a BPMN file that attempts to retain the fidelity of the original process diagram. The Camunda migration tools make extensive use of the Camunda Model APIs to create the BPMN file. Having the source code available will enable you to extend the tools, as needed.

Depending on the vendor you’re migrating from, you’ll still need to add the components (code, scripts, etc.) to make the process executable. 

Read more: Migrating processes from Pega to Camunda 

Migrating process BPMN from IBM BPM to Camunda

Step 2: Migrate process instances

Migrating process instances (or the data contained within them) is unavoidable if you have long-running processes – as some of these processes continue to run at any given time. Getting the data out of the existing BPMN platform is the hard part. There are two basic approaches to migrating process instances:

1. Parallel Operation: With this approach, you keep operating the old solution until no process instances are left there. Meanwhile, you start new process instances on Camunda. To do this, you have to implement switching logic to route traffic from incoming requests to the old or new system. Bear in mind that you need to take care of operating both systems in parallel, e.g. checking failures, calculating KPIs or performing instance counts.

   PRO: Because you do not need to migrate running process instances, you’ll save effort on this step. Also, going live with Camunda is typically less risky, as the old system is still in place and operating.

   CON: Operating two systems in parallel for a longer time requires additional effort. The switching logic normally is not easy to implement and test for all corner cases. Also, the team’s motivation could be at risk, as people may be eager to discard the old system and move on.

2. Big Bang migration: With this approach, you stop the old system and make sure all process instances have reached a wait state. Then, you migrate all instances to Camunda. This requires mapping all possible wait states from the old processes to the BPMN process definition, reading the data from the old system and running a “migration script” to create the process instances in Camunda in the correct state. After that, you fire up the new system.

   PRO: After the migration, you only have one system to operate, and you can test the migration beforehand to avoid any surprises.

   CON: Implementing and testing the migration script requires additional effort. Also, usually the run time of the migration scripts and possible additional health checks afterwards enforce some downtime.

In order to create process instances in the correct state, you do not want to trigger any service tasks or wait for human interaction on the way. Also, the desired state might even be somewhere down a hierarchy of sub-processes. This can make the task a bit more complex and require you to add elements to your process model solely for migration. With that said, if your use case is simpler, the Camunda API should be sufficient enough to migrate process instances in the correct state without the need for any extra elements.

Based on your exact situation, you’ll have to decide which approach is best for your organization. Concurrent operation is very specific to your architecture and technology. In contrast, the Big Bang migration always involves a “migration script,” which requires some knowledge of Camunda to implement. 

For more information on migrating your process instances to a new version, check out this Camunda best practices guide. 

Case Study: Migrating from Oracle to Camunda

In 2007, Deutsche Telekom built a monolithic system based on the Oracle BPEL engine to run BPM workflows and process automation. As time went on, this monolith created a number of issues that affected both the business and user experience, including:

• A lengthy time-to-market lasting more than 12 months
• Vendor lock-in limited the implementation of new features – it took five days to set up or make changes to environments
• Releases took an average of 1000 people-days, or roughly three months to realize
• Regression testing took around two days to process all test cases.

“We need to be on time. We can’t wait seven days to process an order or respond to something; we need to be always ahead and responsible,” said Willm Tueting, managing director, conology GmbH, who has worked with Deutsche Telekom IT for more than 10 years.

Laying the groundwork for change through process orchestration

In 2017, Deutsche Telekom IT took the first steps towards modernizing its processes by adopting a ‘partially agile’ development approach, working in three-month sprints.

“We created several processes to deliver small fixes faster, but it made life much more complex,” Tueting said.

All fixes had to be delivered together with larger change requests, which took considerable people-hours to accomplish. In addition, the organization was still struggling with the monolithic BPEL system, which didn’t allow for true agility.

That same year, Deutsche Telekom began investing in fiber optic cables. With this significant upgrade in hardware came the opportunity to revolutionize Deutsche Telekom IT’s outdated systems. The result was a complete change in both the operating system and DevOps approach, guided by three goals:

1. Speed up: Change development from BPEL to Java and modus operandi from waterfall to agile
2. Develop cross-functional teams: Change from skill-based teams to international cross-functional teams
3. Increase efficiency: Increase development efficiency by using Camunda, Spring and other state-of-the-art technologies.

From one vendor to 43 frameworks

With these three goals in mind, Deutsche Telekom IT implemented a microservices-based architecture in the cloud, with Camunda engines running within many microservices. According to Friedbert Samland, project manager IT application for Deutsche Telekom IT, the new system is comprised of:

1. Microservices: This approach partitioned the monolith and allows for cross-functional work. There is no GUI; instead it is now a pure BPMN system. “Inspired by Camunda Co-Founder Bernd Ruecker’s microservices workflow automation cheat sheet, we run Camunda Engines in many microservices, talking directly to a message broker,” Friedbert said.
2. Cloud: The power of the cloud dramatically reduces runtimes and enables a staged, fine-grained delivery approach. With no ready-made solution, Telekom IT designed its own Kubernetes-based approach.
3. SAFe agile framework: Introducing a new organizational framework with shorter end-to-end cycle-times has enabled flexibility and speed.
4. DevOps philosophy: Automation and self-service are key to Telekom IT’s DevOps philosophy, and ensure quality and speed.

Achieving process automation alignment

One of the greatest advantages of Deutsche Telekom IT’s Camunda revolution has been enabling ‘compliance-by-default.’ As a globally distributed business, with teams working across the world with multiple vendors and sensitive data, a highly automated solution was required. The resulting architecture now enables compliance-by-default and ensures data security.

Deutsche Telekom IT has also built its own internal process monitoring platform, inspired by the token concept employed in Camunda’s Cockpit, so users can see at-a-glance the progress of any process.

As well as supporting and operating a highly flexible DevOps philosophy, Camunda has enabled Deutsche Telekom IT to visualize complex logic in one place, easily align human and automated tasks, and use the same BPMN language for business and development.

For those who are thinking of following in Deutsche Telekom IT’s footsteps, Willm has sage advice: “Choose your stack wisely. Don’t start with a full stack; choose components that add the most benefits to your needs. Think big, start small, don’t try to get to the holy grail in the first attempt – evolve to where you want to be.”

Migrating a major financial services firm step by step

Consulting firm Doculabs works with many large financial services organizations to modernize their IT systems. Many of these firms build their own process automation platforms based on legacy BPMS. As they grow with time, these platforms become brittle and difficult to change.

Read More: Why You’re Struggling with Your BPM Suite

One major financial services firm wanted to overhaul both their front office (e.g. opening new accounts, moving money) and back office (e.g. compliance) process workflows. Ideally, they wanted to move these to a cloud-based process automation and orchestration platform, with the proper security and governance controls in place.

The first step in this process was inventorying each of the business processes across the firm, and bucketing them into “Small,” “Medium,” or “Large” categories. Determining these process sizes meant defining the rules, decision points, integrations and number of reports involved in moving workflows (as well as the approximate cost of each workflow). The team decided that the biggest initial wins would come from rebuilding the highest volume process types from scratch. It took the most time and effort to migrate the processes used day in and day out. While these processes were not the highest volume, it was important to migrate them to the new platform as soon as possible. Dormant processes with little to no volume were retired. 

From there, the Doculabs team built a business case for migrating from the legacy BPMS. They positioned the migration as a part of a larger modernization effort, and discussed the benefits of a modern business process automation platform for both the end user (consumers) and employees at the company. With the new system, the team would be able to modify and change how the firm serviced customers, reduce manual work, and complete workflows faster. After gaining initial buy-in from the firm’s leadership, the Doculabs team planted PoCs throughout the organization to prove that the new approach could work.

Doculabs worked to understand their process inventory, dissected and prioritized each workflow, and moved each process to the new environment by rank order of priority. Using their PoC process, they experimented with pulling workflows from the legacy system and migrating them to the new platform. Early signs were positive. Doculabs also re-engineered and modified certain workflows before they made their way to the new environment. 

As a general rule, their worked as follows: 

• If the process is broken or the technology is inadequate, re-engineer and recreate it
• If the process is working, but the technology is inadequate, recreate it (simplify, standardize, and reuse it wherever possible)
• If a process is working and the technology is adequate, move it “as is” (whenever possible). 

Once the Doculabs team had migrated the firm’s processes from the legacy BPMS to the new cloud-based platform, they saw an immediate improvement in collaboration between business and technical teams. Using BPMN as a common language and communication tool, both teams could easily see how processes worked, and how they could change for the better. On the new system, the financial services firm can now orchestrate human systems and automated processes together in a cohesive way. 

Lessons from a successful legacy BPMS to Camunda migration

Swiss Reinsurance Company (Swiss Re) successfully migrated from a legacy BPMS to a microservices-based orchestration platform using Camunda. Here are some of the key lessons they learned from their migration:

• Be persistent. It’s not enough to share information about the migration during a single advisory board session and expect people to understand everything. The goal is to get all of the key stakeholders to understand the dependencies and timelines associated with the migration. That happens with persistent communications.
• Try to understand the priorities of business stakeholder teams. Every team has its own projects and priorities. Aligning them at the outset of the migration process helps with the planning process.  
• Be optimistic about trusting the development team. Let go of old paradigms and assumptions. Trust that your team can transition to new ways of working. In Swiss Re’s case, dedicated BPM developers transitioned to Camunda, and were eager to learn new cloud-native development skills. 
• Be pessimistic about planning. Swiss Re’s migration was stalled by the Covid-19 pandemic, as well as some personal health matters with the team. In other words, expect the unexpected.
• Be realistic about limitations. That means setting priorities for what can happen right now, and what needs to happen in the future. For example, Swiss Re has built a future roadmap to self-heal applications, widen its user base, and allow superusers to create workflows in Camunda. In addition, they want to enhance reporting capabilities so users can understand where workflows need improvements. 

Conclusion

If you’ve made the decision to migrate from your legacy BPMS, congratulations! Modernizing these rigid systems to more flexible, developer-friendly, API-first platforms like Camunda can lead to better customer experiences, improved internal team productivity, faster development outcomes, and more. As you’ve seen from the examples above, successful organizations lay the groundwork in advance of a technical migration, and align their process automation strategy with leadership, IT and business stakeholders before taking on this significant shift.

From there, Big Bang migrations are often preferred over concurrently operating the legacy BPMS solution alongside Camunda. For Big Bang migrations, you have to remodel your processes into the proper BPMN 2.0 format, and migrate all existing process instances into the right state in Camunda, as described briefly above and in the Camunda Best Practices documentation. 

If you need some help along the way, reach out to the Camunda Consulting team. We’ve helped countless organizations migrate their processes from some of the most rigid, monolithic systems to Camunda. We’re happy to help steer your team through the entire migration process, from PoC to end product. 

Contact Camunda to learn more.