Migration von Appway zu Camunda (mit CIB seven): Best Practices & Migrationsstrategien

Einleitung
Willkommen zur dreiteiligen ONLU-Blogserie „Migration von Appway zu Camunda (mit CIB seven)“. Wir liefern wir Ihnen fundiertes Expertenwissen – von den Beweggründen über die technische Umsetzung bis hin zu praxiserprobten Best Practices.

Inhaltsverzeichnis

1. Teil 1: Einführung & Motivation
2. Teil 2: Architektur & Integration
3. Teil 3: Best Practices & Migrationsstrategien

Best Practices für eine erfolgreiche Migration

Die Migration von Appway zu Camunda/CIB7 sollte gut geplant und schrittweise erfolgen. Aus Erfahrung haben sich folgende Best Practices bewährt, um Risiken zu minimieren und einen reibungslosen Übergang zu gewährleisten:

1. Early Feature Freeze des Altsystems: Sobald die Entscheidung zur Ablösung gefallen ist, empfiehlt es sich, einen Feature-Freeze für das Appway-System zu verhängen. Es sollten nur noch kritische Fehler behoben, aber keine neuen Features mehr dort implementiert werden. Jede Neuerung würde doppelte Arbeit bedeuten – einmal in Appway und einmal in der neuen Camunda-Welt – oder den Cut-over verzögern. Durch den Freeze schafft man ein stabiles Ziel, auf das man hinarbeitet. Gleichzeitig können Fachbereiche auf das neue System vorbereitet werden, ohne sich auf Änderungen im alten einstellen zu müssen.
2. Schrittweises Vorgehen und Parallelbetrieb: Vermeiden Sie einen „Big Bang“-Umstieg, bei dem an einem Stichtag Appway abgeschaltet und alles auf Camunda umgestellt wird. Sinnvoller ist eine selektive, inkrementelle Migration von Prozessen. Identifizieren Sie zunächst einen oder wenige Pilot-Prozesse, die auf Camunda neu umgesetzt werden. Diese sollten möglichst entkoppelt von anderen Abläufen sein und einen hohen Mehrwert bringen. Neue Instanzen dieser Prozesse können dann bereits im Camunda-System gestartet werden, während alle anderen Workflows weiterhin in Appway laufen. Dieses Parallelbetriebs-Modell reduziert das Risiko erheblich – sollte es Probleme geben, sind nur einzelne Prozesse betroffen, nicht die gesamte Prozesslandschaft (mehr Infos: camunda.com) . Wichtig ist eine Routing-Logik, die entscheidet, welche Plattform für neu eingehende Prozessstarts genutzt wird. Beispielsweise kann man anhand des Prozess-Typs oder bestimmter Kriterien unterscheiden. Der Parallelbetrieb erfordert zwar etwas Aufwand (Überwachung zweier Systeme, Datenabgleich, Schulung der Nutzer in beiden Tools) sehe: camunda.com, aber er erlaubt einen gestaffelten Rollout. Nach und nach können weitere Prozesse migriert werden, bis Appway keine neuen Vorgänge mehr erhält und nur noch Alt-Fälle abarbeitet. Im Endzustand – wenn alle aktiven Vorgänge abgeschlossen und alle neuen auf Camunda gestartet sind – kann Appway deaktiviert werden. Dieses iterative Vorgehen minimiert Ausfallrisiken und erleichtert das Rollback im Fehlerfall (da das alte System bis zur endgültigen Ablösung unverändert weiterläuft).
3. Gründliche Prozess-Analyse und Neumodellierung: Nutzen Sie die Migration als Chance, Ihre Prozesse auf den Prüfstand zu stellen. Oft hat man in Appway über Jahre hinweg gewachsene Modelle, evtl. mit Workarounds aufgrund von Tool-Limitierungen. Vor der Umsetzung in Camunda sollten die Prozesse gemeinsam mit den Fachabteilungen analysiert, optimiert und in BPMN 2.0 neu modelliert werden. Camunda zwingt dazu, jeden Prozess sauber zu definieren – dabei kommen manchmal Redundanzen oder unnötige Schritte zutage, die man eliminieren kann. Achten Sie darauf, prozessrelevante Regeln möglichst in DMN-Tabellen auszulagern und Prozesse schlank zu halten. Kleine Proof-of-Concepts können helfen, knifflige Prozessbestandteile (z.B. Parallelitäten, Eskalationen, Benutzerzuweisungen) frühzeitig in Camunda nachzubilden und zu testen, bevor man den ganzen Prozess baut.
4. Geschäftslogik ins Backend verlagern: Wie bereits bei den Herausforderungen erwähnt, sollte man das Ziel haben, wenig Code im Prozessmodell selbst zu haben. Statt lange Skript-Tasks in BPMN zu schreiben, verlagern Sie die Logik in fachliche Services (z.B. Microservices oder modulare Java-Klassen), die dann vom Prozess aufgerufen werden. Camunda-Prozesse rufen diese Services z.B. via REST oder Java Delegate auf. Dadurch erzielt man eine klare Trennung: Camunda orchestriert was passiert wann, die Services implementieren wie es passiert. Diese Trennung erleichtert Testing und Wartung enorm. Bei der Migration heisst das konkret: Code, der bislang in Appway-Prozessen eingebettet war (z.B. Java/Groovy-Skripte), wird identifiziert und in eigenständigen Komponenten nachimplementiert. So entsteht am Ende eine saubere Schichtenarchitektur mit Camunda als Steuerungs-Layer und Business-Services als Ausführungs-Layer.
5. Testen und schulen: Planen Sie ausreichend Zeit für Tests aller migrierten Prozesse ein. Ideal ist es, die Ergebnisse zwischen altem und neuem System zu vergleichen, wo möglich. Beispielsweise können bestimmte Ablaufpfade sowohl in Appway als auch in Camunda durchgespielt werden, um sicherzustellen, dass die Resultate (Daten, Entscheidungen) übereinstimmen. Automatisierte Tests (JUnit für Camunda-Modelle, Integrationstests der Services etc.) sollten fester Bestandteil der Migration sein, um Regressionen zu vermeiden. Ebenso wichtig ist die Schulung der Endanwender und Administratoren: Camunda und das neue Frontend werden anders zu bedienen sein als Appway. Frühzeitige Trainings, gute Dokumentation und vielleicht eine Phase, in der beide Systeme nebeneinander genutzt werden, erleichtern den Übergang für alle Beteiligten.
6. Enges Stakeholder-Management: Eine BPM-Migration betrifft Prozesse, die oft geschäftskritisch sind. Binden Sie daher früh die Facheigner und Entscheider mit ein. Transparente Kommunikation über Ziele, Fortschritte und Änderungen verhindert Akzeptanzprobleme. Zeigen Sie in Demos, wie Prozesse in Camunda modelliert sind, um Vertrauen aufzubauen. Ein solches Projekt ist auch eine gute Gelegenheit, lange gewünschte Verbesserungen umzusetzen (z.B. kürzere Durchlaufzeiten durch Parallelisierung, bessere Prozess-Transparenz durch Monitoring), was den Fachbereichen direkt Nutzen bringt. So wird die Migration nicht nur als technisches IT-Projekt gesehen, sondern als gemeinsame Initiative zur Prozessverbesserung.

Selektive Migration statt kompletter Systemablösung auf einen Schlag

Wie oben angedeutet, ist eine selektive Migration in Etappen meist dem „Alles-auf-einmal“-Ansatz vorzuziehen. Bei einer Komplettumstellung („Big Bang“) müssten sämtliche laufenden Prozessinstanzen aus Appway in Camunda überführt werden – inklusive aller möglichen Prozesszustände und Daten. Dieser Ansatz erfordert das Mapping aller Wartezustände und Variablen zwischen den Systemen sowie Migrationsskripte, um die Camunda-Engine mit diesen instanzierten Prozessen zu füttern (mehr auf: camunda.com). Die Komplexität und das Fehlerrisiko dabei sind sehr hoch. Zudem gibt es im Big-Bang-Szenario kaum eine Rückfallebene, wenn nach Umschaltung Probleme auftreten – das alte System steht ja dann nicht mehr zur Verfügung.

Demgegenüber minimiert eine schrittweise Migration das Risiko: Es werden einzelne Prozesse oder Funktionsblöcke migriert, getestet und in Produktion genommen, während der Rest vorläufig unverändert weiterläuft. Treten Probleme auf, betrifft das nur die neuen Teile, und man kann notfalls den Traffic für diesen Prozess zurück zum Altsystem lenken. Ein weiterer Vorteil der selektiven Methode ist, dass man aus jeder Migrationswelle lernt und diese Erkenntnisse für die nächsten Wellen nutzen kann – sowohl technisch (Performance, Schnittstellen, Modellierungsrichtlinien) als auch organisatorisch (Schulung, Supportfragen).

In der Praxis hat sich oft folgendes Vorgehen bewährt:

• Priorisieren Sie die zu migrierenden Prozesse nach Business-Impact und Komplexität. Starten Sie mit einem mittel-komplexen Prozess, der genug Mehrwert bietet, aber nicht der aller kritischste ist.
• Implementieren Sie diesen Prozess vollständig in der neuen Architektur (Camunda, neues UI, Services) und führen Sie eine Pilotierung durch.
• Führen Sie den Parallelbetrieb (Alt vs. Neu) für diesen Prozess ein und beobachten Sie eine Weile, ob alles stabil läuft.
• Iterieren Sie: Nehmen Sie den nächsten Prozess vor. Ggf. können auch mehrere weniger komplexe Prozesse in einer zweiten Welle gemeinsam migriert werden.
• Deaktivieren Sie sukzessive die alten Funktionen in Appway, sobald deren Pendant in Camunda live ist. So wird Stück für Stück das Altsystem zurückgefahren.
• Am Ende verbleiben eventuell einige Prozesse, die man aus Kosten-Nutzen-Gründen vorerst nicht migriert (z.B. weil sie bald obsolet sind). Diese könnten theoretisch auf Appway verbleiben, aber meist strebt man mittelfristig eine vollständige Ablösung an, um das System stilllegen zu können.

Wichtig ist, nicht zu lange zweigleisig zu fahren, sondern einen klaren Fahrplan für die Stilllegung von Appway zu haben, sobald die Kernprozesse in Camunda stabil laufen. Ein zu langer Parallelbetrieb bindet Ressourcen und kann Verwirrung bei Nutzern stiften. Mit klarer Kommunikation – welche Prozesse wann umziehen – und straffer Projektsteuerung lässt sich das jedoch meistern.

Fazit: Erfolgreiche Ablösung mit Planung und Augenmass

Die Migration von Appway zu Camunda (ggf. mit Unterstützung durch CIB seven/CIB flow) ist zweifellos ein anspruchsvolles Unterfangen, aber es bietet grosse Chancen. Durch den Umstieg gewinnt ein Unternehmen technologische Freiheit zurück – weg von einer proprietären Suite hin zu einer offenen, standardbasierten Prozessplattform. Die Vorteile zeigen sich in höherer Flexibilität bei Änderungen, moderner Architektur (Microservices, Events) und in der Kostenersparnis durch Wegfall von Lizenzgebühren( sehe Blog über CIB fork von Camunda auf onlu.ch) Gleichzeitig können Prozessabläufe optimiert und an neue Anforderungen angepasst werden.

Wesentliche Erfolgsfaktoren sind ein schrittweises Vorgehen, sorgfältige Planung und Einbindung aller Stakeholder. Best Practices wie ein Feature-Freeze des Altsystems, iterative Migration einzelner Prozesse und das Verlagern von Logik ins Backend reduzieren die Risiken und sorgen dafür, dass der laufende Betrieb nicht gefährdet wird. Auch die Entscheidung, in der neuen Lösung Kafka und moderne Frameworks einzusetzen, zahlt auf Zukunftssicherheit und Skalierbarkeit ein.

Abschliessend lässt sich empfehlen, für eine solche Migration erfahrene Partner hinzuzuziehen, die sowohl Appway als auch Camunda kennen. So können Fallstricke früh erkannt und bewährte Migrations-Werkzeuge eingesetzt werden. Mit einem realistischen Zeitplan, ausreichenden Tests und einer klaren Vision der Zielarchitektur kann die Ablösung gelingen – und Ihr Unternehmen profitiert von einer leistungsfähigen, flexiblen Prozessplattform, die zukünftige Anforderungen mit Leichtigkeit bewältigt.

• Appway Hintergrund und Übernahme durch FNZ fnz.com
• Herausforderungen monolithischer BPM-Plattformen (Vendor Lock-in) camunda.com
• BPMN-Standard verhindert Vendor Lock-in camunda.com
• Camunda vs. Appway – Funktionen im Vergleich softwaresuggest.com
• CIB seven und CIB flow – Beschreibung der Komponenten onlu.ch
• CIB seven Vorteile (Open Source, Kompatibilität) onlu.ch
• Camunda SOAP-Integration (Connector) docs.camunda.org
• Camunda & Kafka Zusammenspiel camunda.com
• Event-getriebene Orchestrierung mit Camunda (Beispiel) medium.com
• Migrationsstrategien Parallel vs. Big Bang camunda.com