Kostenlos · Interaktiv · Druckfreundlich

Checkliste: Migrationsbereitschaft Legacy-Systeme

Haken Sie jeden Punkt ab, der auf Ihr System zutrifft. Geben Sie am Ende Ihre E-Mail-Adresse ein — Sie erhalten dann die offenen Punkte zugeschickt, also die Lücken, die eine Migration am häufigsten blockieren.

0 von 29 abgehakt

Risikostufen: Hoch = Migrationsblocker oder Vertragsstrafen-Risiko   Mittel = erheblicher Aufwand erforderlich   Niedrig = mit Planung handhabbar

1. Laufzeitumgebung & Betriebssystem

  • PHP-Version wird offiziell unterstützt (php.net/supported-versions)PHP 8.1 EOL: Dez. 2025 · PHP 7.x: bereits EOL · PHP 5.x: EOL seit 2018 Hoch
  • Betriebssystem erhält SicherheitsupdatesSuSE SLES, CentOS, Debian — EOL-Daten beim Hersteller prüfen Hoch
  • Alle Laufzeit-Abhängigkeiten (Python, Node, Java etc.) sind auf unterstützten Versionen Mittel
  • Das System kann ohne manuelle Schritte neu aufgesetzt werdenOder: Gibt es ein Runbook, das den Neuaufbau vollständig dokumentiert? Mittel
  • Keine selbstkompilierten Binärdateien ohne dokumentierte Build-Anleitung Hoch

2. Versionskontrolle

  • Gesamter Anwendungscode ist in Git (oder einem anderen VCS) gespeichertFTP-Deployments, direkte Server-Edits und ZIP-Archive sind Warnsignale Hoch
  • Die Commit-Historie spiegelt die tatsächliche Entwicklung der Codebasis widerNicht nur ein einzelner „Initial commit“ mit allem drin Mittel
  • Shell-Skripte und Automatisierungen sind gemeinsam mit dem Anwendungscode versioniert Mittel
  • Konfigurationsdateien (ohne Secrets) sind versioniert; umgebungsspezifische Werte nutzen Env-Variablen oder einen Secrets-Manager Mittel
  • Das Produktivsystem entspricht exakt dem Stand im RepositoryKeine „Hotfixes“ direkt auf dem Server, die nie committed wurden Hoch

3. Abhängigkeitsmanagement

  • PHP-Abhängigkeiten werden über Composer mit committed composer.lock verwaltet Hoch
  • Alle Drittbibliotheken sind auf Versionen, die die Ziel-PHP-Version unterstützen Hoch
  • Keine manuell gepatchten oder im Repository eingecheckten Bibliothekskopien Mittel
  • Externe Dienste und APIs, von denen das System abhängt, sind dokumentiertDatenbanken, Message Queues, Monitoring-Agenten, LDAP, Zahlungs-Gateways Mittel
  • System-Integrationen (z. B. CheckMK, Monitoring-Agenten) sind mit dem Ziel-OS kompatibel Mittel

4. Deployment & CI/CD

  • Deployments sind automatisiert und reproduzierbarKein manuelles Datei-Kopieren, kein „nur Klaus weiß, wie man deployed“ Hoch
  • Eine CI-Pipeline läuft bei jedem Merge/PushMindestens: Syntax-Check und einfacher Test-Lauf Hoch
  • Rollback-Verfahren ist dokumentiert und getestet Mittel
  • Staging- oder Testumgebung bildet Produktion ausreichend ab, um Integrationsprobleme zu erkennen Mittel
  • Deployment erfordert keine Downtime (oder geplante Wartungsfenster sind formal definiert) Niedrig

5. Testabdeckung

  • Automatisierte Tests für die zentrale Geschäftslogik sind vorhandenSelbst einfache Unit-Tests erkennen Regressionen bei PHP-Versions-Upgrades Hoch
  • Kritische Nutzerflüsse sind durch Integrations- oder End-to-End-Tests abgedeckt Mittel
  • Tests laufen in CI und ein fehlgeschlagener Test blockiert das Deployment Mittel
  • Code-Coverage wird gemessen (auch wenn kein Schwellenwert erzwungen wird) Niedrig

6. Dokumentation & Wissenstransfer

  • Architektur ist dokumentiert: was das System tut, wie es aufgebaut ist, was von was abhängt Hoch
  • Datenbankschema ist dokumentiert oder selbstbeschreibend (Migrationen, ER-Diagramm) Mittel
  • Nicht-offensichtliche Shell-Skripte sind kommentiert oder in einem Runbook erklärt Mittel
  • Mindestens zwei Teammitglieder verstehen das System gut genug, um selbständig Änderungen vorzunehmen Hoch
  • Zugangsdaten und Secrets werden in einem Secrets-Store verwaltet (nicht hardcodiert oder in einer Textdatei auf dem Server) Hoch

7. Monitoring & Observability

  • Fehler werden geloggt und zentralisiert (nicht nur in Server-Logdateien, die niemand liest) Mittel
  • Alerting ist für Systemausfälle und kritische Fehler eingerichtet Mittel
  • Monitoring-Agenten (z. B. CheckMK) sind mit der Zielplattform kompatibel und die Konfiguration ist versioniert Mittel
  • Anwendungsperformance-Baseline ist bekannt (Antwortzeiten, Durchsatz) zur Validierung nach der Migration Niedrig

Ergebnisse per E-Mail erhalten

Geben Sie Ihre E-Mail-Adresse ein und wir schicken Ihnen die offenen Punkte — die Lücken, die vor dem Migrationsstart geschlossen werden sollten.

Wenn mehrere Hoch-Punkte offen sind, braucht Ihr System zunächst Stabilisierung, bevor eine Migration beginnen kann. Genau dafür ist das Migrations-Audit konzipiert.

Zu den Auftragsarten →