Migration from Appway to Camunda (with CIB seven): Best Practices & Migration Strategies

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. Part 1: Introduction & Motivation
2. Part 2: Architecture & Integration
3. Part 3: Best practices & migration strategies

Best practices for a successful migration

The migration from Appway to Camunda/CIB7 should be well planned and gradual. From experience, the following best practices have proven to minimize risks and ensure a smooth transition:

1. Early feature freeze of the legacy system: As soon as the decision to replace the system has been made, it is advisable to impose a feature freeze for the Appway system. Only critical bugs should be fixed, but no new features should be implemented there. Every new feature would mean double the work – once in Appway and once in the new Camunda world – or delay the cut-over. The freeze creates a stable target to work towards. At the same time, specialist departments can be prepared for the new system without having to adapt to changes in the old one.
2. Step-by-step approach and parallel operation: Avoid a “big bang” migration, where Appway is switched off on a key date and everything is converted to Camunda. A selective, incremental migration of processes makes more sense. First identify one or a few pilot processes that will be converted to Camunda. These should be as decoupled as possible from other processes and provide high added value. New instances of these processes can then be started in the Camunda system while all other workflows continue to run in Appway. This parallel operation model significantly reduces the risk – if there are problems, only individual processes are affected, not the entire process landscape (more information: camunda.com). It is important to have a routing logic that decides which platform is used for new incoming process starts. For example, a distinction can be made based on the process type or certain criteria. Although parallel operation requires some effort (monitoring of two systems, data synchronization, training of users in both tools) see: camunda.com, it allows a staggered rollout. Further processes can be gradually migrated until Appway no longer receives any new processes and only processes old cases. In the final state – when all active processes have been completed and all new ones have been started on Camunda – Appway can be deactivated. This iterative approach minimizes the risk of failure and makes it easier to roll back in the event of an error (as the old system continues to run unchanged until it is finally replaced).
3. Thorough process analysis and re-modeling: Use the migration as an opportunity to put your processes to the test. In Appway, you often have models that have grown over the years, possibly with workarounds due to tool limitations. Before implementation in Camunda, the processes should be analyzed, optimized and remodeled in BPMN 2.0 together with the specialist departments. Camunda forces you to define each process cleanly – this sometimes reveals redundancies or unnecessary steps that can be eliminated. Make sure to outsource process-relevant rules to DMN tables where possible and keep processes lean. Small proof-of-concepts can help to simulate and test tricky process components (e.g. parallelism, escalations, user assignments) in Camunda at an early stage before the entire process is built.
4. Move business logic to the backend: As already mentioned in the challenges, the aim should be to have little code in the process model itself. Instead of writing long script tasks in BPMN, move the logic to business services (e.g. microservices or modular Java classes), which are then called by the process. Camunda processes call these services via REST or Java Delegate, for example. This creates a clear separation: Camunda orchestrates what happens when, the services implement how it happens. This separation makes testing and maintenance much easier. During migration, this means that code that was previously embedded in Appway processes (e.g. Java/Groovy scripts) is identified and re-implemented in independent components. The end result is a clean layered architecture with Camunda as the control layer and business services as the execution layer.
5. Testing and training: Allow sufficient time for testing all migrated processes. It is ideal to compare the results between the old and new system where possible. For example, certain process paths can be run in both Appway and Camunda to ensure that the results (data, decisions) match. Automated tests (JUnit for Camunda models, integration tests of the services, etc.) should be an integral part of the migration to avoid regressions. Equally important is the training of end users and administrators: Camunda and the new front end will be different to Appway. Early training, good documentation and perhaps a phase in which both systems are used side by side will make the transition easier for everyone involved.
6. Close stakeholder management: A BPM migration affects processes that are often business-critical. Therefore, involve the business owners and decision-makers at an early stage. Transparent communication about goals, progress and changes prevents acceptance problems. Use demos to show how processes are modeled in Camunda to build trust. Such a project is also a good opportunity to implement long-awaited improvements (e.g. shorter processing times through parallelization, better process transparency through monitoring), which directly benefits the specialist departments. In this way, the migration is not just seen as a technical IT project, but as a joint initiative for process improvement.

Selective migration instead of complete system replacement in one fell swoop

As indicated above, a selective migration in stages is usually preferable to the “all at once” approach. In the case of a complete migration (“big bang”), all running process instances would have to be transferred from Appway to Camunda – including all possible process states and data. This approach requires the mapping of all wait states and variables between the systems as well as migration scripts to feed the Camunda engine with these instantiated processes (more on: camunda.com). The complexity and risk of errors are very high. In addition, there is hardly any fallback level in the big bang scenario if problems occur after the switchover – the old system is then no longer available.

In contrast, a step-by-step migration minimizes the risk: individual processes or function blocks are migrated, tested and put into production, while the rest continues to run unchanged for the time being. If problems occur, this only affects the new parts and, if necessary, the traffic for this process can be redirected back to the old system. Another advantage of the selective method is that you learn from each migration wave and can use this knowledge for the next waves – both technically (performance, interfaces, modelling guidelines) and organizationally (training, support issues).

In practice, the following procedure has often proved successful:

• Prioritize the processes to be migrated according to business impact and complexity. Start with a medium-complexity process that offers enough added value but is not the most critical.
• Implement this process completely in the new architecture (Camunda, new UI, services) and carry out a pilot.
• Introduce parallel operation (old vs. new) for this process and observe for a while whether everything runs stably.
• Iterate: Carry out the next process. If necessary, several less complex processes can also be migrated together in a second wave.
• Gradually deactivate the old functions in Appway as soon as their counterpart in Camunda is live. In this way, the old system will be rolled back bit by bit.
• In the end, some processes may remain that are not migrated for the time being for cost-benefit reasons (e.g. because they will soon be obsolete). These could theoretically remain on Appway, but the aim is usually to replace them completely in the medium term so that the system can be decommissioned.

It is important not to run on two tracks for too long, but to have a clear roadmap for decommissioning Appway as soon as the core processes in Camunda are running stably. Running in parallel for too long ties up resources and can cause confusion for users. However, with clear communication – which processes will be moved and when – and tight project management, this can be mastered.

Conclusion: Successful replacement with planning and a sense of proportion

The migration from Appway to Camunda (possibly with the support of CIB seven/CIB flow) is undoubtedly a challenging undertaking, but it offers great opportunities. By switching, a company regains technological freedom – away from a proprietary suite and towards an open, standards-based process platform. The advantages are greater flexibility in the event of changes, modern architecture (microservices, events) and cost savings due to the elimination of license fees (see blog about CIB fork from Camunda on onlu.ch) At the same time, process flows can be optimized and adapted to new requirements.

Key success factors are a step-by-step approach, careful planning and the involvement of all stakeholders. Best practices such as a feature freeze of the legacy system, iterative migration of individual processes and the relocation of logic to the backend reduce risks and ensure that ongoing operations are not jeopardized. The decision to use Kafka and modern frameworks in the new solution also pays off in terms of future-proofing and scalability.

Finally, it is advisable to consult experienced partners who know both Appway and Camunda for such a migration. In this way, pitfalls can be recognized early on and proven migration tools can be used. With a realistic schedule, sufficient testing and a clear vision of the target architecture, the replacement can succeed – and your company will benefit from a powerful, flexible process platform that can handle future requirements with ease.

• 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