Migration from Appway to Camunda (with CIB seven): Introduction and motivation

1. Introduction
   Welcome to the three-part ONLU blog series “Migration from Appway to Camunda (with CIB seven)”. We will provide you with in-depth expert knowledge – from the reasons behind the migration to the technical implementation and tried-and-tested best practices.

Table of contents

1. 1. Part 1: Introduction & Motivation

1. 1. Part 2: Architecture & Integration

1. 1. Part 3: Best practices & migration strategies

Background: Why switch from Appway to Camunda?

Appway has been regarded as one of the leading BPM platforms for years, particularly in the financial sector – especially for digital onboarding processes in banks. However, it is a proprietary solution whose customization and further development is heavily dependent on the manufacturer. Such monolithic automation platforms often require extensive customization, which encourages vendor lock-in and technical debt. In other words, the more special logic is implemented in Appway, the greater the dependency on the manufacturer and the more difficult it is to replace it at a later date. In addition, extensive customization projects can slow down the delivery of new functions and limit flexibility.

Camunda offers a modern alternative here. As an open BPM platform based on the ISO standard BPMN 2.0, Camunda enables transparent, standardized mapping of processes – without proprietary modelling. BPMN models are available as XML, which allows for a vendor-independent exchange. In principle, models can be transferred from one tool to another without having to remodelcamunda.com. This avoids vendor lock-in at process levelcamunda. com. In addition, Camunda is open source (Community Edition) and can be operated on-premise. The CIB seven fork in particular provides a long-term supported open source version of the Camunda 7 engine, without license costs and with full digital sovereignty for the operatoronlu.ch. This openness and standard conformity increase future security: processes can also be reused or exchanged in other BPMN systems if required.

Another aspect is the modern architecture: Camunda can be easily integrated into microservice landscapes (e.g. as an embedded engine in Spring Boot Services) and scales flexibly. This contrasts with older BPM suites such as Appway, which often come as a comprehensive suite with its own UI framework, workflow engine and data management – which makes changes to individual components more difficult. In summary, vendor lock-in, flexibility requirements and the desire for a modern, cloud-capable architecture are motivating many companies to switch from Appway to Camunda.

Camunda as a BPMN engine and CIB seven as a supplementary component

Camunda is characterized as a lean BPMN workflow engine that can both orchestrate automated processes and control human tasks (user tasks). Important features such as BPMN 2.0 support, a DMN decision engine for business rules and open REST/Java APIs for integrations are available out-of-the-box. Camunda thus focuses on the role of the orchestrator in the backend – the process logic is made centrally executable, while business logic is connected in the form of services. In comparison, Appway included functions such as integrated case management flows and document management in addition to pure workflow management. These additional functions may have to be replaced by other systems or components in the event of a replacement.

CIB seven, a fork of Camunda 7 developed by the company CIB, plays an important role in the migration. CIB seven is a further development of the engine that is fully compatible with Camunda 7 and will be maintained as an open source project from the end of 2024 onlu.ch. For users, this means that existing Camunda 7 processes, APIs and models will continue to run unchanged onlu.ch. CIB seven particularly addresses the long-term support of the Camunda engine (keyword Camunda 7 EoL) and already offers additional functions and a modern interface in the prospect of onlu.ch. In addition, there is CIB flow, a low-code BPM platform from CIB, which is based on CIB seven onlu.ch. CIB flow provides a web-based interface for modeling and execution, including a form designer, predefined connectors to third-party systems and UI modules (Tasklist, Admin, Monitoring) onlu.ch. In combination, this creates a user-friendly complete solution that uses the Camunda engine in the background, but offers an integrated modeling and presentation layer similar to Appway.

In practice, a migrated system can look like this: Camunda/CIB seven invisibly takes over the execution of the BPMN processes, while CIB flow or an individual front end represents the user interface and form logic. Companies have the choice here of either relying on a low-code platform (such as CIB flow) in order to make faster progress, or developing their own frontend (e.g. in Angular) that communicates with the engine via Camunda’s REST APIs. Both approaches break up the previous Appway “all-in-one” stack into a more flexible layered architecture: the Camunda process orchestrator on the one hand, and freely selectable UI and service components on the other.

Challenges in the migration from Appway to Camunda

Replacing a legacy Appway system brings with it various technical and organizational challenges. Below are the most important points and how they can be addressed:

• • Legacy interfaces (SOAP web services): Many Appway installations integrate external systems via SOAP APIs. Although Camunda primarily relies on REST, it can also address SOAP endpoints – for example via a connector or service task. For example, there is a ready-made SOAP HTTP connector in Camunda that can be used to execute SOAP requests (URL, payload, headers etc.) directly from a process docs.camunda.org. In migration practice, you should check which interfaces can be modernized (e.g. conversion to REST or messaging) and which must be connected via Camunda for the time being. Experience shows that it makes sense to first establish compatibility with existing interfaces during migration – i.e. to extend Camunda so that it uses the old SOAP services – and then to modernize the interfaces themselves in a second step (e.g. with new microservices).

• • Outsourced business logic: In Appway, business rules and logic can be partly in processes (e.g. as scripts) and partly “outsourced” in external Java components or database procedures. One challenge is to fully capture and re-implement this distributed logic when switching over. Best practice is to move as much of the logic as possible from the workflow itself to the backend. In concrete terms, this means that the Camunda process ideally only controls the workflow (sequence, assignment of tasks, calling of services), while the technical calculation takes place in external services or DMN decision tables. This keeps the process lean and changeable without having to be redeployed every time the logic is adapted. Scripts embedded in Appway must be transferred to Java services or rules. This decoupling requires some architectural work at the beginning, but pays off in the long term with better maintainability.

• • Rebuilding the front end: Appway comes with its own UI layer (e.g. screen tasks, forms and collaboration features within the platform). When switching to Camunda, you are faced with the task of completely rebuilding the user interface. Camunda does not provide any ready-made end user interfaces for processes – apart from technical admin tools (cockpit) and a simple task list for human tasks. As a rule, companies opt for modern web frameworks such as Angular or React to design the user experience according to their wishes. This means considerable effort: all appway dialogs, forms and user interactions have to be redeveloped. Alternatively – as mentioned above – a low-code approach can be chosen with CIB flow, where a form designer already exists onlu.ch. However, both approaches require the UI flows previously defined in Appway to be reconstructed. In practice, a UX concept should be created early on that analyzes the existing Appway interfaces and serves as a template for the new frontend. It is often a good idea to take the opportunity to modernize or standardize the frontend instead of rebuilding it 1:1.

• • Data transfer and ongoing processes: Not to be forgotten is the question of what happens to workflows and existing data that are already running. Appway processes that have not yet been completed at the time of the changeover cannot usually be continued in Camunda without further ado, as the models and internal IDs are different. There are two strategies here: either you let old cases expire in the Appway system (parallel operation, see best practices below), or you try to carry out a transparent migration of running instances. The latter is complex – you would have to extract the state of each Appway process and restore it in an equivalent Camunda process. Due to this complexity, a big bang with instance migration is often avoided in practice and parallel operation is used instead (see “selective migration” below). In addition, master data or documents from Appway (such as files stored in Appway’s internal DMS) must be migrated or connected to new systems. A thorough data analysis in advance is therefore essential to ensure that nothing is overlooked. Variant 3 is a big-bang approach with the completion of all process instances by the deadline. From the go-live date, all processes are handled exclusively via the new platform – the old system is thus completely switched off

In the next article , we will delve deeper into the architecture and show how Camunda and CIB seven can be integrated into modern microservice landscapes – including best practices for a smooth transition.

1. Part 1: Introduction & Motivation Part 2: Architecture & Integration Part 3: Best Practices & Migration Strategies

• • • • Appway background and takeover by FNZ fnz.com

• • • • Challenges of monolithic BPM platforms (vendor lock-in) camunda.com

• • • • BPMN standard prevents vendor lock-in camunda.com

• • • • Camunda vs. Appway – a comparison of functions softwaresuggest.com

• • • • CIB seven and CIB flow – Description of the components onlu.ch

• • • • CIB seven advantages (open source, compatibility) onlu.ch

• • • • Camunda SOAP integration (Connector) docs.camunda.org

• • • • Camunda & Kafka Interaction camunda.com

• • • • Event-driven orchestration with Camunda (example) medium.com

• • • • Migration strategies Parallel vs. big bang camunda.com