Die 5 kritischsten IX25 Breaking Changes

Die Zahlen sind klar: Intrexx 12 Support endet am 31.12.2027. Ab 2028 gibt es keine Security-Patches, keine Bugfixes, keinen technischen Support mehr. Für ca. 80% aller Intrexx-Installationen mit Custom Code bedeutet das: Sie müssen migrieren – und es wird nicht trivial.

IX25 ist kein Drop-in-Replacement. Die neue Version bringt fundamentale Architektur-Änderungen: Groovy 3.0, BPMN 2.0, neue Java APIs, OAuth 2.0 Pflicht. Was unter Intrexx 12 lief, bricht unter IX25 – manchmal spektakulär, manchmal subtil.

In diesem Artikel zeige ich Ihnen die 5 kritischsten Breaking Changes, die fast jede Installation treffen – und wie Sie sie meistern. Mit Praxis-Beispielen, Code-Snippets und einer Migration-Checkliste zum Download.

1 Groovy 3.0: Neue Syntax-Regeln brechen alte Scripts

Was sich ändert

Intrexx 12 nutzte Groovy 2.5. IX25 setzt auf Groovy 3.0 – und das ist ein Breaking Change, kein Backward-kompatibles Update. Die Groovy-Entwickler haben den Parser komplett überarbeitet und Syntax-Regeln verschärft.

Konkrete Beispiele, die brechen:

// Array-Zugriff mit falscher Syntax
def users = ["Max", "Anna", "Tom"]
println users[1]  // FEHLER in IX25!

// Non-static inner class
class Outer {
    class Inner {  // FEHLER in IX25!
        def doSomething() { }
    }
}

// Implizite Closures ohne explizite Parameter
list.each { println it.toUpperCase() }  // FEHLER in IX25!

// Array-Zugriff mit korrekter Syntax
def users = ["Max", "Anna", "Tom"]
println users.get(1)  // OK in IX25

// Static inner class
class Outer {
    static class Inner {  // OK in IX25
        def doSomething() { }
    }
}

// Explizite Closure-Parameter
list.each { item -> println item.toUpperCase() }  // OK in IX25

Warum das ein Problem ist

Scope: Ca. 60-70% aller Intrexx-Installationen nutzen Custom Groovy-Scripts für Datenbank-Abfragen, Workflows, REST-Integrationen oder Business Logic. Ein durchschnittliches Mittelstands-Unternehmen hat 20-50 Groovy-Scripts im Einsatz.

Impact: Nach der Migration auf IX25 schlagen diese Scripts fehl – mit kryptischen Fehlermeldungen wie groovy.lang.MissingMethodException oder java.lang.ClassCastException. Workflows stoppen, Integrationen brechen, Geschäftsprozesse stehen still.

So lösen Sie es

Praxis-Beispiel: CRM-Integration

Szenario: Ein Maschinenbau-Unternehmen nutzt ein Groovy-Script, das Kundendaten aus Intrexx in ein externes CRM (Salesforce) synchronisiert. Das Script läuft seit 5 Jahren stabil unter Intrexx 12.

Problem: Nach der Migration auf IX25 schlägt das Script fehl: groovy.lang.MissingMethodException: No signature of method: java.util.ArrayList.get() is applicable

Lösung: Array-Zugriff von customers[0] auf customers.get(0) umstellen. Closure-Parameter explizit machen: customers.each { c -> syncToSalesforce(c) }. Nach der Anpassung: Script läuft wieder.

Zeitaufwand: 2 Stunden Analyse, 1 Stunde Code-Anpassung, 1 Stunde Testing = 4 Stunden pro Script.

2 BPMN 2.0: Alte Workflows sind inkompatibel

Was sich ändert

Intrexx 12 nutzte eine proprietäre Workflow-Engine. IX25 wechselt zu BPMN 2.0 – dem internationalen Standard für Business Process Modeling. Das klingt nach Fortschritt – ist aber ein Breaking Change.

Was das bedeutet

• Alte Workflows laufen NICHT automatisch weiter: Die proprietäre Engine wird abgeschaltet. Workflows, die unter Intrexx 12 liefen, werden unter IX25 nicht erkannt.
• Neu modellieren erforderlich: Jeder Workflow muss in BPMN 2.0 neu modelliert werden. Ein 1:1-Import ist nicht möglich.
• Neue Syntax: BPMN 2.0 nutzt XML-basierte Prozessdefinitionen statt der alten Intrexx-Workflow-Notation.
• Neue Tools: Der alte Workflow-Designer wird durch einen BPMN 2.0 Modeler ersetzt (Camunda Modeler).

Warum das ein Problem ist

Scope: Ca. 50-60% aller Intrexx-Installationen nutzen Workflows für Genehmigungsprozesse, Dokumenten-Workflows, Eskalationen oder mehrstufige Freigaben. Ein durchschnittliches Unternehmen hat 10-20 Workflows im Einsatz.

Impact: Nach der Migration auf IX25 sind diese Workflows tot. Genehmigungsprozesse stoppen, Eskalationen laufen nicht mehr, Dokumente bleiben im Workflow-Limbo. Geschäftskritische Prozesse stehen still.

So lösen Sie es

Praxis-Beispiel: Urlaubsantrag-Workflow

Szenario: Ein Unternehmen mit 200 Mitarbeitern nutzt einen Intrexx-Workflow für Urlaubsanträge: Mitarbeiter beantragt → Vorgesetzter genehmigt → HR archiviert. Der Workflow läuft seit 8 Jahren stabil.

Problem: Nach der Migration auf IX25 ist der Workflow weg. Urlaubsanträge bleiben im Portal hängen, keine Genehmigungen mehr.

Lösung: Workflow in BPMN 2.0 neu modellieren:

• Start-Event: "Urlaubsantrag eingereicht"
• User Task: "Vorgesetzter prüft Antrag"
• Gateway (XOR): "Genehmigt?" → Ja/Nein
• Service Task: "E-Mail an Mitarbeiter senden"
• End-Event: "Workflow abgeschlossen"

Zeitaufwand: 1 Tag Dokumentation, 1 Tag Neu-Modellierung, 0.5 Tage Testing = 2.5 Tage pro Workflow.

3 Deprecated APIs entfernt: Custom Code bricht

Was sich ändert

IX25 räumt auf: Über 50 alte Java APIs, die seit Jahren als @Deprecated markiert waren, werden entfernt. Wenn Ihr Custom Code diese APIs nutzt, bricht er unter IX25.

Betroffene APIs (Auswahl)

Warum das ein Problem ist

Scope: Ca. 40-50% aller Intrexx-Installationen nutzen Custom Java-Code für komplexe Business Logic, externe Integrationen oder Performance-Optimierungen. Diese nutzen oft alte APIs.

Impact: Nach der Migration auf IX25 wirft der Code java.lang.NoClassDefFoundError oder java.lang.NoSuchMethodError. Custom-Module brechen, Integrationen schlagen fehl.

So lösen Sie es

Praxis-Beispiel: SAP-Integration

Szenario: Ein Produktions-Unternehmen nutzt Custom Java-Code, um Auftragsdaten aus Intrexx in SAP zu übertragen. Der Code nutzt IConnector.executeQuery() für Datenbank-Abfragen.

Problem: Nach der Migration auf IX25: java.lang.NoSuchMethodError: de.uplanet.lucy.server.connector.IConnector.executeQuery(Ljava/lang/String;)

Lösung: Code umschreiben auf neue API:

String sql = "SELECT * FROM orders WHERE status = 'open'";
IDataObject result = connector.executeQuery(sql);

String namedQuery = "getOpenOrders";
Map<String, Object> params = new HashMap<>();
params.put("status", "open");
IDataObject result = connector.executeNamedQuery(namedQuery, params);

Zeitaufwand: 1 Tag Code-Scan, 2 Tage Refactoring, 1 Tag Testing = 4 Tage für 10-15 betroffene Stellen.

4 OAuth 2.0 Pflicht: Basic Auth wird abgeschaltet

Was sich ändert

Intrexx 12 unterstützte Basic Authentication für REST APIs und externe Integrationen. IX25 schaltet Basic Auth ab – OAuth 2.0 wird Pflicht.

Was das bedeutet

• Keine Passwörter mehr im Klartext: Basic Auth sendet Username/Passwort Base64-kodiert (nicht verschlüsselt!) – unsicher.
• Token-basierte Authentifizierung: OAuth 2.0 nutzt Access Tokens (JWT) mit kurzer Lebensdauer (15-60 Minuten).
• Refresh Tokens: Für langlebige Integrationen müssen Refresh Tokens implementiert werden.
• Authorization Server: OAuth 2.0 erfordert einen Authorization Server (z.B. Keycloak, Azure AD, Intrexx-eigener OAuth-Server).

Warum das ein Problem ist

Scope: Ca. 60-70% aller Intrexx-Installationen nutzen externe Integrationen (REST APIs, SOAP Webservices, Drittsysteme), die per Basic Auth authentifizieren.

Impact: Nach der Migration auf IX25 schlagen alle Integrationen mit HTTP 401 Unauthorized fehl. Daten-Synchronisationen brechen, externe Services sind nicht mehr erreichbar.

So lösen Sie es

Praxis-Beispiel: Mailchimp-Integration

Szenario: Ein Marketing-Team nutzt eine Intrexx-Integration, die Newsletter-Abonnenten automatisch an Mailchimp überträgt. Die Integration authentifiziert per Basic Auth (API Key).

Problem: Nach der Migration auf IX25: HTTP 401 Unauthorized – Mailchimp akzeptiert keine Basic Auth mehr.

Lösung: OAuth 2.0 Client Flow implementieren:

String apiKey = "your-api-key";
HttpClient client = new HttpClient();
client.setBasicAuth("user", apiKey);
String response = client.post("https://api.mailchimp.com/3.0/lists/...", data);

// 1. Token abrufen
String tokenUrl = "https://login.mailchimp.com/oauth2/token";
Map<String, String> tokenParams = new HashMap<>();
tokenParams.put("grant_type", "client_credentials");
tokenParams.put("client_id", "your-client-id");
tokenParams.put("client_secret", "your-client-secret");
String accessToken = oauthClient.getAccessToken(tokenUrl, tokenParams);

// 2. API-Call mit Token
HttpClient client = new HttpClient();
client.setBearerToken(accessToken);
String response = client.post("https://api.mailchimp.com/3.0/lists/...", data);

Zeitaufwand: 1 Tag OAuth 2.0 Setup, 1 Tag Code-Anpassung, 0.5 Tage Testing = 2.5 Tage pro Integration.

5 Java 17 LTS: Java 8 Code läuft nicht mehr

Was sich ändert

Intrexx 12 lief auf Java 8 (Release: 2014). IX25 wechselt zu Java 17 LTS (Release: 2021) – ein Sprung von 7 Jahren. Java 8 wird nicht mehr unterstützt.

Was das bedeutet

• Neue Module-System: Java 9+ führte das JPMS (Java Platform Module System) ein – alte Code-Strukturen brechen.
• Entfernte APIs: Java EE APIs (JAXB, JAX-WS, CORBA) wurden aus Java SE entfernt – müssen explizit als Dependencies hinzugefügt werden.
• Neue Garbage Collectors: G1GC statt CMS – andere Performance-Charakteristiken.
• Deprecated Features entfernt: Z.B. sun.* Packages, interne APIs, alte Security-Algorithmen.

Warum das ein Problem ist

Scope: Ca. 30-40% aller Intrexx-Installationen nutzen Custom Java-Code, der auf Java 8 optimiert ist – nutzt alte APIs oder interne Packages.

Impact: Nach der Migration auf IX25 bricht der Code mit java.lang.NoClassDefFoundError (fehlende Java EE APIs) oder IllegalAccessError (JPMS-Restriktionen).

So lösen Sie es

Praxis-Beispiel: XML-Verarbeitung (JAXB)

Szenario: Ein Unternehmen nutzt Custom Java-Code, um XML-Daten von einem externen ERP-System zu parsen. Der Code nutzt JAXB (Java Architecture for XML Binding).

Problem: Nach der Migration auf IX25: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext – JAXB existiert in Java 17 nicht mehr.

Lösung: JAXB als externe Dependency hinzufügen:

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.1</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>2.3.1</version>
</dependency>

Zeitaufwand: 0.5 Tage Dependencies hinzufügen, 0.5 Tage Testing = 1 Tag.

Empfohlene Migration-Timeline

So gehen Sie die IX25-Migration strukturiert an:

Häufig gestellte Fragen (FAQ)

Starten Sie jetzt mit Ihrem IX25 Readiness Check

Wir analysieren Ihre Intrexx-Installation, identifizieren alle Breaking Changes und erstellen einen konkreten Migration-Plan – inklusive Aufwandsschätzung und Timeline.

Kostenloser IX25 Readiness Check (Wert: 2.000€)
Nur für die ersten 10 Unternehmen, die bis 31.03.2026 anfragen.

🔒 Unverbindlich | ✓ Keine Zahlungsdaten erforderlich | 📧 Antwort in 24h

Weitere Artikel zur IX25-Migration

• IX25 Migration: Zero-Downtime in 4 Wochen
• Groovy Scripts nach IX25 migrieren (Coming Soon)
• IX25 Performance-Optimierungen (Coming Soon)
• Intrexx vs. Power Apps vs. Mendix