Migration

SuiteCRM 7 auf 8: Checkliste vor dem Umstieg

Der Wechsel von SuiteCRM 7 auf 8 ist für viele Organisationen alternativlos, sobald Support, PHP-Stack oder Produktstrategie das erfordern. Gleichzeitig ist er kein Routine-Patch. Offizielle Dokumentation und Migrationspakete machen klar: Es geht um einen strukturierten Übergang, nicht um „Installationsdatei überschreiben und hoffen“.

Dieser Text ist eine Vorbereitungs- und Entscheidungscheckliste. Er ersetzt kein Projektplan und keine verbindliche Aussage zu Ihrer konkreten Codebasis.

1. Architektur: warum sich 7 und 8 anders anfühlen

SuiteCRM 8 bringt eine modernisierte Anwendungsarchitektur und UI-Schicht mit; Legacy-Anteile und Migrationspfade sind Teil des offiziellen Modells. Für Entscheider heißt das praktisch:

• Erwartungen an Oberfläche, Navigation und Admin-Wege ändern sich.
• Customizations aus 7.x sind nicht automatisch 1:1 lauffähig.
• Betrieb (PHP-Version, Composer/Console-Schritte, Cache, Rechte) folgt enger den Release Notes der Zielversion.

Wer „nur Features vergleichen“ will, unterschätzt den Anteil an Migrationshandwerk.

2. Rahmen klären, bevor Technik startet

• Ziel-Release (z. B. konkrete 8.x-Linie) schriftlich fixieren – nicht „irgendwas Aktuelles“.
• Business-Treiber: Security, PHP-EOL, fehlende 7.x-Pflege, strategische UI – priorisiert.
• Wartungsfenster und Kommunikationsplan für Fachbereiche.
• Rollen: wer entscheidet Go/No-Go, wer testet fachlich, wer stellt den Host?
• Rollback-Bedingung: Ab welchem Fehlerbild wird zurückgerollt – und wie lange ist das Backup gültig?

3. Inventar – der Teil, den Teams am häufigsten unterschätzen

3.1 Packages und Custom Code

Listen Sie installierte Packages mit Version und letztem bekannten Stand. Markieren Sie: produktiv / optional / tot. Ergänzen Sie Logic Hooks, Scheduler-Jobs, Custom Modules und „Copy-Paste in custom/“, das nie ein Package war.

3.2 Integrationen

SSO, ERP, Marketing, Telefonie, Document Management, BI-Exporte: Jede Schnittstelle braucht einen Eigentümer und einen Testfall nach der Migration.

3.3 Datenqualität

Dubletten, kaputte Relationships, verwaiste Anhänge – Migration vergrößert bestehende Datenprobleme selten „von selbst“, sie macht sie sichtbar und verlangsamt Abnahme.

4. Staging: was „getestet“ heißen sollte

Eine leere Demo-Instanz beweist wenig. Mindestens:

1. Kopie mit realistischem Datenausschnitt oder Vollkopie – bewusst entscheiden und dokumentieren.
2. Migration nach offiziellem Pfad der gewählten Paketlinie (nicht „Gerüchte aus dem Forum“ als Runbook).
3. Testskript: Login, Rechte, ein Kern-Sales-Flow, Mail ein/aus, ein Report, ein kritischer Custom-Flow, Anhang öffnen.
4. Performance-Stichprobe an listenstarken Modulen – subjektiv, aber früh warnend.

Known Issues der Dokumentation (Rechte nach CLI-Befehlen, CSRF/Session nach erneuter Migration auf derselben URL, falsches Paket statt Migrationspaket) gehören in das Runbook, nicht in die Überraschung am Go-Live-Wochenende.

5. Daten, Dateien, Cutover

• DB- und Dateivolumen geschätzt; Backup-Dauer gemessen, nicht geschätzt.
• Anhänge: Stichprobe vor/nach – öffnen, nicht nur „Datei liegt da“.
• Cutover-Reihenfolge: Wartungsseite, finale Sync-Strategie, DNS/URL, Session/Cookies, erste Smoke-Tests.
• Hypercare: 3–5 Tage klarer Ansprechpartner, bekannte Workarounds, Eskalationsweg.

6. Go-Live-Kriterien (Vorschlag)

Definieren Sie vorher, nicht hinterher:

• Alle A-Prozesse grün auf Staging
• Keine offenen „unbekannten“ A-Packages ohne Plan
• Backup + Restore-Probe dokumentiert
• Fachliche Sign-offs der Prozessowner

Stundenersparnis und „Erfolgsquoten“ ohne Bezug zu Ihrer Codebasis wären spekulativ – deshalb fehlen sie hier absichtlich.

← Zurück zum Magazin