An Activiti-Camunda migration can be an interesting proposition to many companies. Especially, since it isn’t technically problematic and can offer substantial business benefits. How to carry out such a migration effectively? How does a Camunda vs Activiti comparison look?
Activiti is a fairly powerful BPM (Business Process Management) tool. Still, there are better alternatives, especially if you currently use one of the older versions of the platform. In this article, we’ll highlight the most important reasons for moving from Activiti to Camunda and the possible benefits such a migration may bring companies. We’ll also outline a migration strategy based on one of our projects.
This article focuses on migrating from older versions of Activiti to the free variant of Camunda 7. If you want to know more about Camunda, check our previous article on the subject: Camunda BPM – What is it, how to use it, and how does it compare with Activiti, Webcon and PowerApps?
There are a couple of main business benefits Camunda brings to the table:
- A new process engine – Camunda has a new process engine with a ready-made form editor, easier-to-use process editor, and more. You can get some of these featuresin Activiti, but it requires the installation of an additional plug-in (Eclipse).
- It’s easier to use – Camunda’s powerful workflow capabilities enable you to simplify BPM and make it more accessible, similar to how low-code/no-code platforms simplify software development (these are solutions that allow you to make applications from pre-made “building blocks”, minimizing the amount of coding required). Thanks to its powerful but user-friendly Modeler, Camunda is easier to use for business-oriented people, who can define processes and work with the platform themselves.
- It can be more secure – If your current BPM system is old, you’ll most likely achieve a better security level if you use a recent version of Camunda.
If you want a more detailed feature/options comparison of the two platforms we discuss in this article, check out the table below.
|Functionality||Description||Camunda (free version)||Camunda Enterprise||Activiti|
|Version History||Access the history of changes made to a BPMN process model||No||Yes||Yes, but without a dashboard|
|Token flow simulation||Process operation simulator||Yes||Yes||Yes|
|Tasklist front-end||Built-in web-based interface for user tasks, integrated with the Camunda Form Builder||Non-production usage only||Yes||No ready-made dashboard|
|Support SLA||Support team available 24×7||No||Yes||No|
|Run processes||Test run of processes to preview them||Yes||Yes||No|
|Run automated decisions||Launching automatic decision-making processes as part of tests||Yes||Yes||No|
|Product support||Get product help directly from our Technical Support team||No||Yes||No|
|Process models||Creating processes in the BPMN editor for the business user||Yes||Yes||No dedicated editor – process editor is based entirelly on development tools|
|KPI-based monitoring and alerts||Monitor specific KPIs by creating alerts based on performance reports||Non-production usage only||Yes||Yes|
|Integration Framework||A framework for connecting BE to any data source to expose it to the Connector||Yes||Yes||None, manual implementation in code|
|Inspect processes||Live preview of processes in the application||Non-production usage only||Yes||No ready-made dashboard|
|Inspect decisions||Live preview of decision model processes||Non-production usage only||Yes||No ready-made dashboard|
|Form Builder||Allows you to make simple frontend forms as part of creating BPMN processes to interact with the user. More information here.||Yes||Yes||No|
|Decision models||Allows you to add decision schemes to BPMN (detailed conditions on how the process should behave depending on the data entered by the user)||Yes||Yes||Yes|
|Custom training/professional services||Options for tailored training courses and other professional services from Camunda experts||No||Yes||No|
|Custom performance reports||Application usage reports||Non-production usage only||Yes||No reports|
|Custom dashboards||Dashboard with a preview of application usage statistics||Non-production usage only||Yes||No dashboard that could be expanded|
|Connectors||Allows you to create connections to a REST data source from the BPMN diagram||Yes||Yes||None. Manual implementation in code|
|BPMN element templates||Creating reusable process patterns||Yes||Yes||Yes|
There are some problems you might run into while migrating to the Camunda process automation solution.
- Custom forms might prove too complicated – If your workflow is based on many heavily customized forms, fitting everything into the free Modeler Camunda offers might be challenging or even impossible. This doesn’t mean you can’t migrate your system, but the semi-low-code nature of Camunda won’t be enough here – you’ll probably have to carry out a lot of additional development, and it’ll prolong the migration process, so keep that in mind. However, once you do this, your business users can reuse the created form templates without problems.
- The need for other upgrades – Depending on the version of Camunda you want to use and your overall technological debt, you might need to update other parts of your technology stack, such as Spring and Java. For example, in one of our projects, everything worked flawlessly with Camunda 7.9, but version 7.19 introduced an additional problem associated with the changes to the process blocking mechanism Camunda developers made in the update.
In this part of the article, we’ll introduce a potential migration strategy you can use. The information here is based on one of our projects and was created for a specific case, so remember that the strategy might not apply to your business without some fundamental changes. Still, it should, at the very least, give you a broad idea of how such a migration works and what is required to carry it out.
Gradual system migration
Our approach assumes that the system will be migrated gradually. The new system will initially support only one of the processes, so there will be no need to analyze and rebuild all of them. This way, we avoid a complete rewrite, which would require time-consuming analysis of all processes and integration.
Current processes will continue to be handled by the existing system until they are completed. While we migrate the old system to Camunda, we also slightly modernize its look to make it visually consistent with the new system. This will increase the satisfaction of users who will see that the system has been renewed. Moreover, visual consistency should help people adapt to the new solution more easily.
Rewriting the entire system would require much more time for analysis and implementation, which, in addition to the increased cost, would also mean that the implementation of the new system would take place much later. Dividing process migration into stages allows you to enjoy the new system much earlier, and subsequent changes and implementations would mean an increasing number of processes would be implemented in the new system.
Key migration steps
Here are the key steps in our Activiti-Camunda migration process:
1. Upgrading the current workflow process engine
Depending on the circumstances, the first step in your system upgrade may be to update the existing Activiti process engine to at least version 5.11. This is necessary to allow further steps – migration procedures to Camunda 7.5 were prepared for Activiti 5.11. Using these instructions, you can make the move relatively easy.
If you want to use Camunda 8.0, however, things are a bit more complicated. You will need to verify the workload when transferring processes. The authors of the migration instructions stipulate that this requires conversion of the current diagrams to the new version, and their modification may be required.
2. Introducing the new engine
Accessing the new process engine is one of the main reasons for the migration. Along with the new engine, we introduce Camunda’s easy-to-use, flexible, low-code Modeler, which allows users to design many business processes without coding or technical know-how. As long as the change doesn’t require modifications in the forms presented to the user, they can implement them using the low-code tool.
The new system will be created as an element operating in parallel with the existing process on the same engine. Some processes will be handled using the new application, and some using the old one. The user will dynamically switch between both applications in various circumstances (for example, by entering a process or screen from a new workflow or returning to the summary/configuration panel).
3. Migration of one of the processes
When the new automated workflow system is implemented, one process will be replaced. You should choose it in consultation with your software partner or inside development team.
Migrating one process will allow you to test the new system without impacting business operations (or with minimal impact on them) before implementing further changes.
4. Incremental migration of further processes
After that, introduce subsequent modifications to the process and implement forms incrementally to maintain existing processes in their current version.
This transfer of processes will also require you to move integrations to the new system – and it’s a great occasion to audit them and check which you actually use and which are unnecessary. If the workflow application has unused integrations in its code, they will make development and analysis of the system’s operation difficult, so only transfer the relevant ones.
5. Modernizing the front end
It’s highly probable that you’ll also need to modernize your front end to make it more compatible with the new engine and Modeler.
Currently, most businesses use frameworks that simplify programming work and unify the code structure. Thanks to this, a new person introduced to the project knows where individual classes and screens are located and how the application is built. It simplifies work and speeds up the onboarding of new people. It also helps reduce the risk of vulnerabilities because frameworks are updated frequently.
For this workflow system, we recommend using the Angular framework due to its high popularity and the availability of experienced programmers. Read more about this technology in our article about upgrading AngularJS to Angular.
6. Creating the documentation
Finally, the last crucial step is creating the post-project documentation, which will allow new people to easily implement the project and simplify the analysis of new changes to the system.
Depending on your circumstances, an Activiti-Camunda migration might be a worthwhile consideration for your company. The business benefits are easy to see – you can lower your licensing costs while introducing a more user-friendly solution that your non-technical employees can use effectively. Moreover, projects like these usually aren’t terribly complicated or time-consuming.
Of course, if you don’t have an in-house team that can do the work, you can always find a vendor who does. At Pretius, we have plenty of experience with Camunda, Activiti and other BPM solutions, and we’ll be happy to help you with the migration. Contact us at email@example.com (or using the contact form below) and describe your needs. We’ll get back to you within 48 hours and tell you how we can help.