Kundenanfrage und 
Zieldefinition

  • Der Kunde stellte im Rahmen interner strategischer Vorgaben die Anfrage, die bestehende Website in die AWS-Cloud zu migrieren. Als zentrales Ziel formulierte der Kunde die Migration der bestehenden Webanwendung von einem klassischen Hosting-Anbieter in die AWS-Cloud-Infrastruktur. 
  • Im internen Workshop hat das Team folgende Teilziele definiert
    • Verbesserung der Ausfallsicherheit, Skalierbarkeit, Redundanz, Performance, Sicherheit und Wartbarkeit durch die Nutzung cloudnativer Technologien und Services.
  • Auf Basis einer sehr groben Aufwandsabschätzung durch das Entwicklerteam hat die Kundenberatung ein Gesamtangebot für das vollständige Projekt erstellt und dem Kunden zur Verfügung gestellt.

Analysephase, Konzeption und Beginn der Umsetzung

  • Bestandsaufnahme: Eine detaillierte Analyse der aktuellen Infrastruktur der Webseite, einschließlich der verwendeten Technologien, Serveranforderungen, Datenbanken und Webanwendungen. 
  • Als Migrationsziel wurde die Re-Architektur gewählt, dessen Aufgabe war, die bestehende Anwendung grundlegend zu überarbeiten, um die Vorteile der Cloud optimal zu nutzen. Messbare Ziele für die Ausfallsicherheit, Skalierbarkeit, Performance und Sicherheit wurden festgelegt. 
  • Cloud Readiness Check: Was muss angepasst oder neu gedacht werden?
  • Proof of Concept / technische Spikes: Z. B. TYPO3 in AWS mit S3-Storage + RDS testen
  • Cloud-Zielarchitektur modellieren 
    • Must-have: Docker auf EC2, ALB, IAM, RDS, S3, VPC, CI/CD, Monitoring, Backups
    • Nice-to-have:  ECS/Fargate (alternativ zu EC2) und Terraform

PO Einstig und 
fundierte Planung

  • Einstieg Product Owner: in der Phase fand mein Einstieg in das Projekt statt. Das erste Ziel bestand darin, die Ursachen für den ausbleibenden Projektfortschritt zu identifizieren. 
  • Im Anschluss an die Analyse wurden gemeinsam mit dem Team die folgenden Planungsschritte definiert: 
    • Probleme und Ziele (inkl. qualitative) abstimmen und weitere gemeinsame Vorgehensweise definieren
    • Erfolgskriterien festlegen und Erwartungshaltung des Kunden
      • alle bekannten Use Cases nach dem Umzug müssen weiterhin funktionieren
      • Teilziele wie Ausfallsicherheit, Skalierbarkeit, Performance, Sicherheit messbar machen
    • Meilensteine (Best Case und Worst Case) und grobe Ressourcenplanung 
    • Risiken besprechen und festhalten  
    • Rollen und Verantwortlichkeiten: DevOps Engineer (Teilzeit), 2 Typo3 Backend Entwickler (Teilzeit), Lead Architekt (Teilzeit) und PO (Teilzeit)
    • Übertragen der definierten Themen als Epics, Aufteilung in die User Stories und Tasks in Jira, Abhängigkeiten zwischen ToDos transparent machen 
      • Zeitplan als Gant Diagramm erstellen: ca. 5 Monate Laufzeit
      • Einplanung der Sprints, Erstellung der regelmäßigen Termine

Umsetzung

  • Einrichtung der VPC, Subnets, NAT Gateway, RDS, S3, IAM-Rollen, ALB
  • Netzwerk- & Sicherheitskonfiguration: Erstellung von TLS-Zertifikaten für Staging-URLs, IAM-Rollen & Policies, Subdomains für Testumgebung
  • TYPO3-Container bauen (inkl. PHP, Nginx)
  • Anpassung der TYPO3-Konfiguration für S3, Redis, neue Datenbankverbindungen etc.
  • Aufbau der CI/CD-Pipeline: automatisiertes Deployment nach Dev/Staging/Prod
  • Migration der Inhalte: Datenbank-Migration (z. B. MariaDB → RDS), Medienübertragung nach S3
  • Sicherstellung der Datenintegrität: Überprüfung, dass alle Daten korrekt migriert werden und keine Daten verloren gehen.
  • Übertragung von Dateien: Sicherstellung, dass alle Webseiten-Dateien, Datenbanken, Medien und sonstige Assets in die Cloud migriert werden.
  • Datenbankmigration: Umzug von bestehenden Datenbanken (MySQL) auf Cloud-Datenbankdienste, inklusive möglicher Anpassungen
  • Durchführung von Lasttests, Failover-Tests, Performance Tests
  • Sicherheitskonfigurationen und Sicherheitstests: Implementierung von Sicherheitsrichtlinien, Verschlüsselung und Firewalls, um den Zugriff auf die Webseite zu schützen.

Qualitätsmanagement und
Anpassung

Tests wurden auf funktionale und  technische Tests unterteilt.

Eine Check-Liste für die Tests vorbereiten, ToDos erstellen und den dafür zuständigen Mitarbeiter zuweisen.

  • Smoke Tests (Basis-Funktionalität): Manuell prüfen, ob die Anwendung grundsätzlich funktioniert, TYPO3-Frontend aufrufbar, Backend-Login möglich, Navigation, Formulare, Suche, Content Rendering funktionieren
  • Datenintegritätstests: sicherstellen, dass Datenbank und Inhalte vollständig migriert sind, Verknüpfungen zwischen Datensätzen korrekt (z. B. Seitenstruktur, Bilder), Medien (z. B. Bilder, PDFs) erreichbar, Uploads funktionieren
  • Performance-Basisprüfung: Ladezeit der wichtigsten Seiten im Frontend, Time to First Byte (TTFB) liegt im akzeptablen Bereich (< 500ms), Backend-Reaktionszeiten für Redakteure prüfen

Weitere Tests

  • Sicherheitstest (Basisniveau): HTTPS aktiv für alle Domains (inkl. Weiterleitungen von HTTP), IAM-Rollen korrekt konfiguriert (z. B. kein öffentlicher Zugriff auf S3), Offene Ports nur dort, wo notwendig (z. B. via ALB), Zugriffsschutz für Backend (z. B. Rate-Limiting, sichere Passwörter)
  • Auto Scaling Smoke-Test: prüfen, ob sich neue Instanzen oder Tasks bei erhöhter Last automatisch starten, Health Checks greifen korrekt (ungesunde Instanzen werden ersetzt), ALB verteilt Anfragen korrekt auf neue Ressourcen
  • Failover-Test: Simulation eines Server- oder Container-Ausfalls, sicherstellen, dass Ausfall kompensiert wird (z. B. durch ALB, neue Task), kein Nutzer darf durch den Ausfall Fehler erhalten (Zero Downtime Ziel)

Vorbereitung auf den 
Livegang l

Check-Liste für den Livegang vorbereiten: technische und organisatorische Aspekte

  • Die letzten Tests vor Go-live abschließen
  • Finales Deployment vorbereiten
    • Letzte Container-/Code-Version bauen und in Produktion deployen
    • CI/CD Pipeline für Produktivumgebung testen
    • Konfigurationsdateien (TYPO3 .env, Datenbank-Hosts, S3-Buckets, Redis etc.) für Prod prüfen
    • Backup vor Live-Schaltung erstellen (DB, Medien, Konfiguration)
  • DNS-Umschaltung planen
    • TTL frühzeitig reduzieren (am Tag vor dem Go-live auf 300 Sekunden-5 min)
    • DNS-Einträge für Domains auf neuen Load Balancer oder CloudFront zeigen lassen: Infos dem Service-Anbieter zur Verfügung stellen
    • HTTPS-Zertifikat (über ACM) aktiv und geprüft
    • DNS-Wechsel außerhalb der Kernzeiten einplanen (Mittag) 

Vorbereitung auf den 
Livegang ll

  • Monitoring & Logging aktivieren
    • CloudWatch Alarme (z. B. CPU, Memory, 5xx Errors)
    • Fehler-Logging im TYPO3-Backend prüfen
    • Logs zentral speichern und auswertbar machen (CloudWatch Logs, S3 )
    • Dashboard einrichten (AWS Console)
  • Disaster Recovery-Plan 
    •  Erstellen eines Plans, wie die Webseite im Falle eines Ausfalls schnell wiederhergestellt werden kann.
  • Rollback-Strategie vorbereiten
    • Backup aller produktiven Daten und Konfigurationen vorhanden
    • Möglichkeit zur DNS-Rückschaltung vorbereitet
    • Downtime-/Fallback-Plan dokumentiert 
    • Zugang zur alten Infrastruktur/Umgebung für Notfälle erhalten
  • Kommunikation & Teamkoordination
    • Alle Beteiligten informieren (Entwicklung, Betrieb, Kundenteam)
    • Eskalationswege klären und dokumentieren (wer reagiert bei Problemen?)
    • Go-Live-Zeitfenster abstimmen
    • Team steht bereit für Live-Support (Teams)

Livegang

  • Die Webseite live stellen und stichprobenartig testen
  • Post-Go-Live-Monitoring (erste 24–72 Stunden)
    • Dashboard aktiv überwachen (Fehler, Last, Performance)
    • Regressions-Tests durch Redakteure/Endnutzer möglich machen
    • Frühzeitige Auswertung der Logs & Nutzerfeedback
    • Fehler oder Unregelmäßigkeiten sofort analysieren und beheben

©2025 Evgeniya Vigil Presa. Alle Rechte vorbehalten.    

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.