Neues aus der Produktentwicklung: ScriptRunner für Jira Data Center zu OpenProject migrieren

Viele Organisationen, die vom Jira Data Center zu OpenProject wechseln, stellen dieselbe Frage: Was passiert mit unseren ScriptRunner-Skripten? Eine kurze Antwort darauf gibt es nicht. ScriptRunner ist keine einzelne Funktion, sondern eine ganze Toolbox, und jeder einzelne Bestandteil verdient eine eigene Antwort. In diesem Beitrag teile ich unseren aktuellen Standpunkt dazu, wie sich ScriptRunner migrieren lässt – und warum ich der Überzeugung bin, dass das meiste, was ScriptRunner leistet, ins Kernprodukt gehört und nicht in ein Plugin oder Skript.

Darüber hinaus vertrete ich die Ansicht, dass der gesamte Lebenszyklus eines Skripts – von der Entwicklung über das Testen und Verteilen bis hin zur Wartung – so komplex ist, dass er mehr verdient als ein Webformular, in das man lediglich einige Skripte einfügen kann. Am breiteren ScriptRunner-Ökosystem lässt sich erkennen, dass dort versucht wird, all die Werkzeuge nachzubilden, die in einer gewöhnlichen Softwareentwicklungsumgebung verfügbar sind: vom Logging über das Testen bis zur Verteilung. Ich bin nicht der Ansicht, dass OpenProject sämtliche Werkzeuge für die Softwareentwicklung enthalten sollte. Vielmehr sollten wir uns darauf konzentrieren, die Kernfunktionalität von OpenProject zu erweitern.

Um diese Überzeugung auf die Probe zu stellen, habe ich ein kleines Produktexperiment durchgeführt: Ich habe ein OpenProject-Plugin gebaut, mit dem man Ruby-Skripte in ein Webformular einfügen kann – genau wie Groovy-Skripte in ScriptRunner. Was ich dabei gelernt habe, war ziemlich aufschlussreich und bestätigt meinen ursprünglichen Verdacht.

Warum Organisationen Jira Data Center verlassen

Atlassian bezeichnet die lokal installierte Version von Jira als „Data Center“, und diese wird schrittweise aus dem Programm genommen. Seit dem 30. März 2026 können Neukunden sie nicht mehr erwerben. Ab dem 30. März 2028 können Bestandskunden keine Erweiterungen, Upgrades oder neuen Apps mehr kaufen. Am 28. März 2029 laufen die Data-Center-Abonnements und alle darauf betriebenen Marketplace-Apps aus und werden schreibgeschützt. (The Register)

Atlassian rät seinen Data-Center-Kunden, zu Atlassian Cloud zu wechseln. Dadurch geraten viele Organisationen in eine schwierige Lage. Einige sind in stark regulierten Branchen wie dem Finanzwesen, der Verteidigungsindustrie oder dem öffentlichen Sektor tätig, in denen die Nutzung einer fremden Cloud keine Option darstellt. Andere möchten schlicht die volle Hoheit über ihre Daten behalten und die Abhängigkeit von einem einzelnen Anbieter vermeiden.

Aus diesem Grund wenden sich Unternehmen aus aller Welt an uns, um von Jira Data Center auf OpenProject On-Premises umzusteigen. Projekte, Vorgänge, Nutzer und Anhänge von Jira nach OpenProject zu übertragen ist eine ziemlich klare Aufgabe. Aber die Migration von ScriptRunner ist eine ganz eigene Herausforderung und kommt in vielen Kundengesprächen früher oder später zur Sprache.

ScriptRunner ist ein Werkzeugkasten, keine Funktion

Viele Unternehmen, die Jira einsetzen, nutzen auch ScriptRunner für Jira. Damit können sie das Standardverhalten von Jira an ihre spezifischen Anwendungsfälle anpassen. Diese Anwendungsfälle lassen sich typischerweise unterteilen in:

• Spezifische Workflows, die an die tatsächlichen Arbeitsweisen eines Teams oder einer Abteilung angepasst sind.
• Integrationen mit den übrigen Systemen der IT-Landschaft, etwa mit Beschaffungs- oder Rechnungsstellungssystemen.

In beiden Fällen ermöglicht ScriptRunner, eine Lösung zu entwickeln, die ohne den Betrieb eines weiteren Systems funktioniert. ScriptRunner lässt sich über das Plugin-Konzept in Jira integrieren und erweitert dessen Kernfunktionalität, sodass sich Jira „verbiegen“ lässt, um erweiterte Anwendungsfälle und Produktivitätsoptimierungen abzudecken.

Es gibt keine einzelne ScriptRunner-Funktion. Es handelt sich um eine Reihe von Tools, die Jira in vielerlei Hinsicht erweitern, beispielsweise:

• On-Demand-Skripte: einmalige Ausführungen über die Skriptkonsole, zum Beispiel eine Massenaktualisierung von Status.
• Ereignisgesteuerte Skripte: Listener, die auf Ereignisse reagieren, beispielsweise das Hinzufügen von Beobachtern, wenn ein Vorgang erstellt wird.
• Geplante Skripte: Jobs, die in Intervallen laufen, zum Beispiel das Schließen veralteter Vorgänge.
• Workflow-Erweiterungen: selbstdefinierte Bedingungen, Validatoren und Post-Funktionen bei Übergängen.
• Skriptfelder: Felder, deren Werte anhand einer selbstdefinierten Logik berechnet werden.
• Änderungen an der Benutzeroberfläche: Funktionen, die Felder in Formularen ein- oder ausblenden oder zur Pflicht machen, sowie Skriptfragmente, die Elemente der Benutzeroberfläche hinzufügen.
• Suche: Erweiterte Suche mit zusätzlichen JQL-Funktionen.
• Selbstdefinierte REST-Endpunkte: Schnittstellen zur Integration externer Systeme.

Bei der Migration zu OpenProject müssen wir jede dieser Dimensionen einzeln betrachten. Einige davon sind bereits im Kern von OpenProject enthalten, andere stehen auf unserer Roadmap, und einige lassen sich besser auf andere Weise lösen.

Das gilt unabhängig davon, wohin Sie migrieren. Selbst bei der Migration in Atlassians eigene Cloud ist der Umstieg nicht einfach. Im Data Center werden Skripte innerhalb der JVM von Jira ausgeführt und verfügen über uneingeschränkten Zugriff auf die Java-API von Jira. In Jira Cloud werden Skripte außerhalb von Jira ausgeführt und kommunizieren über die REST-API mit Jira, wobei Berechtigungsbereiche und asynchrone Webhooks anstelle von synchronen Ereignisbehandlungsroutinen zum Einsatz kommen. Eine 1:1-Portierung gibt es nicht. Jede Migration erfordert ein Überdenken Ihrer Skripte; daher lohnt es sich, sich zu fragen, welche davon überhaupt als Skripte existieren sollten.

Die tatsächlichen Kosten von Skripten

Skripte sind leistungsstark, doch diese Leistung hat ihren Preis. Dies zeigt sich in drei Bereichen: Sicherheit, Wartung und laufender Betrieb.

Sicherheit

ScriptRunner-Skripte verfügen über uneingeschränkten Zugriff auf die Java Virtual Machine (JVM), in der Jira ausgeführt wird, und folglich auch auf deren Datenbank. Im Grunde erweitern diese Skripte Jira um weiteren Code. Meiner Meinung nach sollten Administratoren diesen Code wie echte Software behandeln, denn er kann Sicherheitslücken einführen. Dieser Code muss wie jeder andere Code in der Produktion entwickelt, versioniert, geprüft und getestet werden.

Aus sicherheitstechnischer Sicht würde ich ScriptRunner als Code-Injection by Design bezeichnen. Code-Injection ist eine ganze Kategorie von Sicherheitslücken. Sicherheitsforscher werden gut dafür bezahlt, Wege zu finden, um Schadcode in Webanwendungen wie Jira oder OpenProject einzuschleusen. ScriptRunner öffnet diese Tür bewusst: Jeder, der über die entsprechenden Administratorrechte verfügt, kann beliebigen Code auf einem Jira-Server ausführen. Das finde ich für Unternehmenssoftware überraschend, und ich frage mich, wie das entsprechende Sicherheitsaudits besteht.

Natürlich verstehe ich die Attraktivität von ScriptRunner. Mit einem einzigen Plugin können Jira-Administratoren Lösungen selbst entwickeln und bereitstellen, anstatt Plugin-Entwickler zu beauftragen. Das ermöglicht organisatorische Abkürzungen. Der Administrator installiert einfach das ScriptRunner-Plugin und macht sich von allen anderen unternehmenstypischen Prozessen und Protokollen zur Softwarebereitstellung unabhängig. Es umgeht das Bürokratiemonster. Doch ist das eine gute Idee? Ich halte das für eine riskante Lösung für ein Problem, das eigentlich organisatorisch ist.

Wartung

Bei jedem größeren Release von Jira können Administratoren nicht sicher sein, dass ihre Skripte weiterhin funktionieren. Wenn sich interne APIs oder Datenstrukturen ändern, müssen die Skripte angepasst werden. Dies ist kein Problem, das ausschließlich ScriptRunner betrifft: Jede Erweiterung, die in die internen Abläufe eines Standard-Kernprodukts eingreift, steht vor dieser Herausforderung. Es ist ein bekanntes Problem vieler Plugin-Konzepte.

Diese Unsicherheit verlangsamt die Einführung neuer Jira-Versionen, einschließlich Sicherheitsupdates. Nach jedem Update müssen Administratoren sicherstellen, dass ihre Skripte weiterhin funktionieren. In der Praxis bedeutet das, eine Entwicklungs- oder Staging-Umgebung allein zum Testen von Skripten zu betreiben und das Upgrade so lange aufzuschieben, bis jedes Skript geprüft und gelegentlich angepasst wurde. Dies führt dazu, dass Kunden sich unveränderliche interne APIs und langfristigen Support (LTS) für bestimmte Versionen wünschen. Beides ist ein großes Hindernis für die kontinuierliche Produktverbesserung. Lassen Sie mich Ihnen folgende Frage stellen: Handelt es sich bei Ihrem iOS um eine LTS-Version, oder installieren Sie einfach jedes Update automatisch? OpenProject strebt bei Updates dieselbe Qualität an. Vor einem Update müssen Sie sich keine Sorgen machen. Sobald Sie jedoch eigene Skripte haben, werden Sie anfangen, sich Sorgen zu machen. Und dies ist nicht die Richtung, in die OpenProject Sie bewegen möchte.

Das Fazit: Die Entwicklung von Skripten und Plugins muss als vollwertige Softwareentwicklung betrachtet werden, die kontinuierliche und automatisierte Tests umfasst, anstatt nur einer einmaligen Überprüfung vor jedem Upgrade.

Operationen

Auf den ersten Blick wirkt ScriptRunner schlank. Es stellt Ihnen ein Webformular zur Verfügung, in das Sie Groovy-Code eingeben oder einfügen können. Bei genauerer Betrachtung bietet es Ihnen allerlei Werkzeuge, die für die normale Softwareentwicklung erforderlich sind. ScriptRunner protokolliert beispielsweise Skriptausführungen, damit Sie den Zustand eines Skripts prüfen können. Mit anderen Worten: Es versucht, Werkzeuge nachzubilden, die Softwareentwickler bereits haben.

Und dennoch gibt es auf Jira Data Center keine Sandbox um ScriptRunner herum: Ein Fehler in einem einzigen Skript kann die gesamte Instanz beeinträchtigen oder sogar lahmlegen.

Jedes Skript braucht dieselbe Sorgfalt wie jede andere Software, auf die sich Ihre Organisation verlässt: Jemand muss dafür verantwortlich sein, es dokumentieren, überwachen und beheben, wenn es ausfällt. Wenn die Person, die ein Skript geschrieben hat, die Organisation verlässt, geht dieses Wissen oft mit ihr verloren.

Wie in der üblichen Softwareentwicklung sollten Sie auch hier das Vier-Augen-Prinzip umsetzen. Code-Reviews verbessern die Wartbarkeit und Sicherheit des Codes. Sie mindern außerdem den „Truck-Faktor“. Für eine effiziente Diskussion über den Code benötigen Sie jedoch die richtigen Tools, wie beispielsweise GitLab oder GitHub. Ich bin nicht der Meinung, dass solche Tools in OpenProject gehören.

Der OpenProject-Ansatz: Integration in den Kern

Bei OpenProject verfolgen wir einen etwas anderen Ansatz als Atlassian. Wenn ein Anwendungsfall für viele Kunden sinnvoll ist, integrieren wir eine entsprechende Funktion direkt in OpenProject. Idealerweise muss niemand ein Plugin oder Skript installieren. Deshalb sind unsere Integrationen mit Nextcloud, XWiki und GitLab fest eingebaut und werden nicht als Plugins bereitgestellt. Wir möchten, dass OpenProject sofort einsatzbereit ist.

Jede Funktion im Kern wird bei jeder Veröffentlichung getestet, dokumentiert und unterstützt. Administratoren müssen sie nicht separat finden, installieren, lizenzieren und aktualisieren, und sie müssen sich nicht fragen, ob sie nach dem nächsten Upgrade noch funktioniert.

Für Migrationen von Jira zu OpenProject bedeutet das: Die ScriptRunner-Funktionen, die lediglich die Kernfähigkeiten von Jira erweitern, werden direkt im Kern von OpenProject adressiert.

Wo eine Lücke bleibt, schließen wir sie im Kern. Ein gutes Beispiel hierfür ist die Erweiterte Suche von ScriptRunner. Sie erweitert JQL um Funktionen wie linkedIssuesOf, die alle Vorgänge auswählen, die mit den Ergebnissen einer anderen Abfrage zusammenhängen. Wir halten diesen Anwendungsfall für sehr sinnvoll, deshalb haben wir ihn in die OpenProject-Entwicklungsroadmap aufgenommen. Ein derart leistungsstarkes Werkzeug sollte nicht in einem Plugin versteckt sein.

Wenn Sie mehr als das brauchen, was wir entwickeln können

Egal wie gut unsere Produktrecherche ist, einige Organisationen werden OpenProject an ihre Bedürfnisse anpassen müssen. Vielleicht muss die Oberfläche geändert oder Datenstrukturen erweitert werden. OpenProject kann nicht für jeden spezifischen Anwendungsfall optimiert werden.

Wir möchten nicht, dass Organisationen ein Fork erstellen und ein komplettes OpenProject pflegen müssen, nur um eine einzige Funktion zu ändern. Deshalb haben wir OpenProject vor mehr als einem Jahrzehnt über ein Plugin-Konzept erweiterbar gemacht. Sie kümmern sich dann lediglich um die Pflege des Plugins und dessen Kompatibilität mit dem OpenProject-Kern.

Zwei Dinge sind hier wichtig zu wissen:

• Interne APIs ändern sich. OpenProject liefert jeden Monat neue Funktionen. Ein besseres, umfangreicheres Produkt zu liefern, das Organisationen Freiheiten verschafft, hat für uns Vorrang vor der Stabilität interner APIs.
• Die REST-API bleibt stabil. Wir achten sehr darauf, dass die darauf basierenden Integrationen weiterhin einwandfrei funktionieren. Das macht die REST-API gemeinsam mit Webhooks zur richtigen Grundlage, um OpenProject mit anderen Systemen in Ihrer IT-Landschaft zu verbinden.

Plugin-Betreuer bitten uns oft, ihre Plugins in den OpenProject-Kern zu integrieren, und das aus gutem Grund: Es bietet Nutzern und Administratoren die beste Erfahrung und nimmt ihnen die Last, das Plugin mit jedem Release synchron zu halten.

Dennoch ist es nicht bei jedem Plugin sinnvoll, es in OpenProject zu integrieren. Deshalb sind wir der Überzeugung, dass das OpenProject-Team einfache Lösungen bereitstellen sollte, mit denen Sie den Zustand Ihrer Plugins überwachen können. Wir diskutieren derzeit, wie wir Ihnen am besten CI/CD und den Bau von Docker-Images für Ihre privaten Plugins bereitstellen können. Falls das für Sie interessant ist, melden Sie sich gern!

Das Experiment: Skripte in ein Webformular einfügen

Manchmal braucht es nur eine echte Erfahrung, um die eigene Überzeugung zu ändern. Ich wollte mich selbst herausfordern und habe als Prototyp das gebaut, was ich eigentlich gar nicht in OpenProject aufnehmen wollte. Ich wollte wissen, wie es sich anfühlt, die Flexibilität von ScriptRunner in OpenProject zu haben. Wie fühlt es sich an, Ruby-Code in ein einfaches Webformular einzufügen, das OpenProject vollständig verändert? Mithilfe eines KI-Coding-Agenten habe ich ein OpenProject-Plugin namens „Scripts“ entwickelt, das genau das tut. Es ermöglicht Administratoren:

• Ruby-Skripte in den Administrationseinstellungen von OpenProject hinzuzufügen. Die Skripte laufen in den Hintergrund-Workern von OpenProject oder sogar innerhalb der aktuellen Webanfrage.
• Skripte bei ausgewählten Ereignissen auszulösen, etwa beim Erstellen oder Aktualisieren eines Arbeitspakets.
• Die Projekte auszuwählen, in denen ein Skript aktiviert ist.

Das Plugin ist nicht für den Einsatz in der Produktion gedacht. Es zu installieren ist sogar gefährlich, aus genau den oben beschriebenen Sicherheitsgründen. Doch dadurch konnten wir erleben, wie sich diese Art von Flexibilität anfühlt, sowohl als Skriptautor als auch als Administrator.

Was wir gelernt haben

1. Anfangs macht es Spaß. Die Freiheit, beliebigen Ruby-Code einzufügen und OpenProject einfach so anzupassen, macht süchtig. Wenn man es einmal hat, fällt es einem psychologisch schwer, es wieder herzugeben, ähnlich wie bei einem Stück guter Schokolade.
2. Es ist schwer, Anwendungsfälle zu finden, die wir nicht lieber direkt in OpenProject integrieren würden. Nehmen wir das Risikomanagement als Beispiel. Ein Skript könnte aus den beiden selbstdefinierten Feldern „Schweregrad“ und „Wahrscheinlichkeit“ ein Feld „Risikostufe“ berechnen. Es ist jedoch weitaus sinnvoller, das Risikomanagement direkt mit einer speziellen Benutzeroberfläche und integrierten Datentypen zu unterstützen.
3. Das Schreiben eines Skripts erfordert fundierte Kenntnisse der internen Abläufe von OpenProject. Sie müssen das interne Datenmodell, die Dienste und die Ereignisse kennen, in die sich ein Skript einbinden lässt. Ein Webformular kann nicht genügend Hinweise liefern, um Sie als Skriptentwickler zu unterstützen.
4. Skripting ist echte Softwareentwicklung. Ich möchte meine Ansprüche an handwerkliche Softwarequalität nicht senken. Ich möchte IDE-Unterstützung mit Code-Vervollständigung, Logging und einem Debugger. Ich möchte Peer-Reviews. Sich selbst ins Bein zu schießen ist sehr einfach (ja, das ist mir passiert), und ein Webformular ist nicht der richtige Ort, um dies zu vermeiden.
5. Ich wünsche mir Unterstützung durch KI. OpenProject-Skripte zu schreiben ist vielleicht nicht mein tägliches Geschäft, daher möchte ich Hilfe von meinem KI-Agenten. Dieser Agent braucht den Quellcode von OpenProject und idealerweise eine vollständige Laufzeitumgebung, um seine Ergebnisse zu validieren. Mit meiner IDE habe ich das. In einem Webformular nicht. Oft komme ich nicht weiter und weiß nicht, warum ein Skript einfach nicht funktioniert.
6. Ich möchte automatisierte Tests und CI/CD. Wenn mein Skript mit dem nächsten Release von OpenProject kaputtgeht, möchte ich automatisch benachrichtigt werden. Ich mag keine Überraschungen, und ich möchte ein OpenProject-Update nicht aufschieben müssen, nur weil ich unsicher bin, ob meine Skripte noch funktionieren. Meine Erweiterungen sollten ebenso wie der übrige Code von OpenProject durch automatisch ausführbare Tests abgedeckt sein. Eigentlich möchte ich, dass die Softwaretests parallel zur Entwicklung meiner Skripte erstellt werden. Dieses Experiment bietet das nicht. Und ich möchte das Experiment nicht so erweitern, dass es auch noch Softwaretests über ein Webformular umfasst.
7. Ich möchte nach wie vor eine Staging-Umgebung, die die Produktionsumgebung widerspiegelt, um meine Skripte zu testen. Ich würde ein Skript nicht zum ersten Mal in meiner Produktivumgebung ausführen wollen. Das setzt voraus, dass ich dieselbe Skript-Konfiguration schnell von einer Instanz auf eine andere kopieren kann.
8. Ich möchte, dass meine Skripte zentral gespeichert und versioniert werden, idealerweise in einem Git-Repository, beispielsweise auf GitLab. Ich müsste also eine Art Synchronisation mit einem Git-Repository aufbauen.

Unser Fazit

1. Funktionen, die allgemein sinnvoll sind, gehören in den OpenProject-Kern. Die meisten Tools von ScriptRunner erweitern lediglich den Jira-Kern, obwohl sie eigentlich von vornherein Teil davon hätten sein sollen. Für OpenProject bedeutet das: Wenn eine Funktion allgemein sinnvoll ist, sollte sie Teil von OpenProject sein und kein Plugin, das separat hinzugefügt und verwaltet werden muss.
2. Echte Funktionsänderungen erfordern echte Softwareentwicklungswerkzeuge. Wenn Sie das Verhalten von OpenProject wirklich ändern müssen, ist die Änderung zu komplex, um sie einfach in ein Webformular zu tippen. Selbst erfahrene OpenProject-Entwickler hätten damit Schwierigkeiten und würden sich bessere Werkzeuge wünschen. Wir sind der Ansicht, dass wir es stattdessen einfacher gestalten sollten, eine Umgebung für die Entwicklung und Pflege von Plugins einzurichten. Bitte sagen Sie uns Bescheid, wenn Sie dabei Hilfe brauchen.
3. Skripte machen die Wartung von Unternehmenssoftware zu anfällig. Wir bei OpenProject sind stolz darauf, dass Administratoren Updates einfach durchführen können und sicher sein können, dass das Update reibungslos verläuft. Mit Skripten gilt das nicht mehr. Auch die Qualitätssicherung wird schwieriger, weil die professionellen Werkzeuge fehlen.

Was dies für Ihre Migration bedeutet

Wenn Sie planen, von Jira Data Center zu OpenProject zu wechseln, empfehlen wir, Ihre ScriptRunner-Skripte einzeln nacheinander zu überprüfen:

1. Verschaffen Sie sich einen Überblick. Über die Registry von ScriptRunner können Sie alle Skripte als ZIP-Datei exportieren, die die Groovy-Quelldateien, deren Konfiguration sowie eine zusammenfassende CSV-Datei enthält. Finden Sie damit heraus, welche Skripte noch aktiv sind, wer für jedes einzelne verantwortlich ist und ob es noch benötigt wird. Skripte, die niemand mehr braucht, lassen sich am leichtesten migrieren.
2. Prüfen Sie zunächst die Kernfunktionen. Viele Anwendungsfälle werden durch die Workflows, selbstdefinierte Felder, selbstdefinierte Aktionen oder Abfragen von OpenProject abgedeckt. Wenn etwas fehlt, aber für viele Organisationen sinnvoll ist, sagen Sie uns Bescheid, damit wir es in unsere Roadmap aufnehmen können.
3. Nutzen Sie die REST-API für Integrationen. Verbindungen zu Beschaffungs-, Rechnungsstellungs- oder anderen Systemen sollten über die stabile REST-API und die Webhooks von OpenProject erfolgen und nicht in OpenProject hinein.
4. Prüfen Sie, ob der MCP-Server von OpenProject Ihre Anforderungen bereits erfüllt. Es ist 2026. OpenProject hat einen MCP-Server, Jira Data Center nicht. Vielleicht können Sie Ihre Anpassungen in Zeiten von KI anders lösen?
5. Entwickeln Sie für den Rest ein richtiges Plugin. Wenn Sie das Verhalten von OpenProject wirklich ändern müssen, entwickeln Sie ein Plugin mit Versionskontrolle, Tests, CI und einer Staging-Umgebung. Wir helfen Ihnen gern bei der Einrichtung.

Wir möchten von Ihnen hören

Das sind unsere aktuellen Überlegungen, und wir freuen uns auf Ihre Meinung. Pflegen Sie derzeit ScriptRunner-Skripte? Wie sähe die ideale Erfahrung für Sie aus? Und wo liegen unsere blinden Flecken? Teilen Sie gern Ihre Gedanken mit der Open Source Community von OpenProject in diesem Arbeitspaket.