Cloud-Achterbahn: Höhen, Tiefen, Erfolg!

Migration in die AWS-Cloud

Ausgangslage und Zusammenfassung

Ein Kunde aus dem Bereich öffentlicher Verkehr, dessen Website von meinem Arbeitgeber gehostet wird, beauftragte uns mit der Migration in die AWS-Cloud (IaaS). Nachdem die Anforderungen gemeinsam abgestimmt und validiert wurden, startete das Team mit der Umsetzung. Weil das Projekt zunächst nur schleppend vorangegangen war, übernahm ich nach einigen Monaten die Projektleitung, um organisatorisch zu unterstützen und neue Impulse zu setzen. 

Durch die iterative Umsetzung wurde das Projekt in kurze, überschaubare Sprints aufgeteilt. Dies hat eine schrittweise Umsetzung ermöglicht, wobei regelmäßige Überprüfungen und Anpassungen während der Sprints durchgeführt wurden. Scrum hat ermöglicht, schnell auf Änderungen zu reagieren, die während des Umzugs aufgetreten sind (z. B. unerwartete technische Herausforderungen). Einführung von regelmäßigen Sprint-Plannings, Sprint-Reviews, tägliche Stand-up-Meetings sowie Retrospektiven hat die Kommunikation im Projekt vielfach verbessert. 

Die Migration brachte sehr viele technische Herausforderungen mit sich, da im Team nur begrenzte Erfahrung im Zusammenspiel von Cloud-Infrastruktur und TYPO3 bestand. Durch einen iterativen Ansatz und regelmäßige Abstimmungen im Team konnten wir aber schnell erste Fortschritte erzielen, die wichtigsten Hürden erfolgreich meistern und das Projekt abschließen

Die genaue Vorgehensweise siehst du bei Klick auf "Mehr erfahren". Weiter unten befinden sich die wichtigsten Eckpunkte des Projekts. 

Problemdefinition

  • Die Webseite liegt auf einem Hetzner Server und hat somit die festgelegte Hardware-Ressourcen. Sobald der Traffic plötzlich ansteigt, können die zusätzlichen Ressourcen kurzfristig nicht beschaffen werden, was zu Down-Times führt.
  • Die 100% die Ausfallsicherheit ist nicht gegeben.
  • Updates, Backups und Sicherheitsmaßnahmen müssen manuell durchgeführt werden und erfordern viele Ressourcen
  • Langsame Geschwindigkeit der Webseite in den Spitzzeiten.

Projektziel

  • Erhöhung der Ausfallsicherheit und automatische Skalierbarkeit.
  • Reduzierung der Kosten auf lange Sicht: Langfristige Senkung der Betriebskosten durch effiziente Ressourcennutzung und Automatisierung.
  • Automatische Updates der Webseite zur Verbesserung der Performance und Steigerung der Kundenzufriedenheit.
  • Die Latenzzeit muss minimiert werden, sodass die Ladegeschwindigkeit der Webseite auch in Spitzenzeiten unter 2 bis 3 Sekunden bleibt.

Die Laufzeit für das Projekt: 1.4.22-30.10.22

Meine Rolle als PO

  • Koordination des Migrationsprojekts mit dem DEV-Team innerhalb des vorgegebenen Zeitplans. 
  • Sicherstellung einer reibungslosen Datenmigration ohne Betriebsunterbrechung. 
  • Zielsetzung der Erfolgskriterien, Risiko-, und Budgetmanagement.
  • Abstimmung mit Stakeholdern, um technische und geschäftliche Anforderungen zu definieren. 
  • Überprüfung der Anforderungen nach der Entwicklung und Abnahme der Umsetzung.

Organisatorische 
Herausforderungen

  • Change Management: Ein Umzug in die Cloud ist eine große Veränderung, die gut kommuniziert und begleitet werden muss.
  • Kostenmanagement: Der Umzug in die AWS-Cloud erfordert eine detaillierte Planung der Budgets, da die Abrechnung in der Cloud oft auf Basis der Nutzung erfolgt (Pay-as-you-go).
  • Ressourcenmanagement: Die Ressourcen für den Umzug (wie Personal und Tools) müssen richtig geplant und eingeplant werden.
  • Mangelnde Kommunikation im Team.

Technische 
Herausforderungen

  • Sehr komplexe Datenmigration (Datenstrukturen von Maria DB)
  • Auswahl der richtigen AWS-Dienste (EC2, RDS, S3, CloudFront, etc.)
  • Effiziente Skalierung der Cloud-Ressourcen, insbesondere bei wechselnden Besucherzahlen. 
  • Die Konfiguration des Servers auf AWS (z.B. EC2) muss sicherstellen, dass alle Komponenten korrekt und optimal für Typo3 eingerichtet sind.

Methoden & 
Tools

Methoden: Scrum, BPMN, Use Cases, Kano-Modell, Brainstorming, Risikomatrix

Tools: Jira, Confluence, Advanced Road Maps, bpmn.io, draw.io

Ergebnisse und Impact

Durch die Migration in die Cloud konnten Ausfallsicherheit und Skalierbarkeit der Website deutlich verbessert werden,  inklusive automatischer Anpassung an Lastspitzen. Die Performance wurde spürbar optimiert (Latenzzeit < 2 Sek.), was die Nutzerzufriedenheit deutlich erhöhte. Gleichzeitig profitiert das Unternehmen von langfristigen Kosteneinsparungen und das Dev- sowie DevOps-Team konnte seine Kompetenzen im Bereich moderner Cloud-Technologien erheblich erweitern.

Sicherstellung der Ausfallsicherheit

Durch den Wechsel in die Cloud-Umgebung konnte eine deutlich höhere Ausfallsicherheit erreicht werden. Redundante Systemarchitekturen und automatische Wiederherstellungsmechanismen sorgen dafür, dass im Falle von Störungen oder Ausfällen der Betrieb der Website ohne längere Unterbrechungen weitergeführt werden kann. Damit wurde das Risiko ungeplanter Downtimes signifikant reduziert.

Verbesserung 
der Skalier-barkeit 

Die neue Infrastruktur ermöglicht eine bedarfsgerechte, automatische Skalierung der Ressourcen. Dadurch kann die Website Lastspitzen, etwa bei hohem Nutzeraufkommen oder besonderen Ereignissen, zuverlässig und ohne Leistungseinbußen bewältigen. Die Einführung einer lastenabhängigen Skalierung sorgt für eine stabile Performance unabhängig vom Nutzungsverhalten.

Erhöhung der Kundenzufriedenheit 

Die Migration und Optimierung führten zu einer deutlichen Verbesserung der Ladezeiten und der allgemeinen Systemreaktion. Insbesondere die Reduzierung der Latenzzeit auf unter zwei Sekunden trägt wesentlich zur positiven Nutzererfahrung bei und stärkt die Zufriedenheit der Endkunden spürbar.

Entwicklung des Dev- und DevOps-Teams

Das Projekt erwies sich auch intern als wertvoller Impulsgeber: Das Entwickler- und DevOps-Team erlangte durch die enge Zusammenarbeit und die technischen Herausforderungen umfassende Kenntnisse in modernen Cloud-Technologien, Infrastrukturautomatisierung und Continuous Deployment. Das ist eine spürbare Weiterentwicklung der technischen Kompetenzen und Teamfähigkeiten.

Lessons Learned

Die vertragliche Festpreisvereinbarung stand im Widerspruch zur explorativen Vorgehensweise des Projekts. In Kombination mit fehlendem technischen Know-how erwies sich dieser Ansatz als äußerst risikobehaftet und schwer steuerbar.

Festpreisvertrag als Projektrisiko

Fehler: Im vorliegenden Projekt erwies sich der Festpreisvertrag als ungünstig, da Aufwand und technische Herausforderungen zu Projektbeginn kaum abschätzbar waren. Die Migration in die Cloud brachte viele Unbekannte mit sich, für die keine Flexibilität im Budget vorgesehen war. Dadurch entstand hoher wirtschaftlicher Druck mit Risiken für Qualität, Termin und Teambelastung.  

Lesson Learned: Bei Vorhaben mit hoher technischer Unsicherheit, wie der Migration in eine neue Cloud-Infrastruktur  ist ein Festpreisvertrag ungeeignet. Zukünftig sollte bei Projekten mit hohem Explorationsanteil eine flexiblere Vertragsform gewählt werden.

 

PO als kritischer
Erfolgsfaktor

Fehler: Zu Projektbeginn fehlte eine aktive Product-Owner-Rolle, was zu Unklarheiten bei Prioritäten, Anforderungen und Entscheidungswegen führte. Dadurch wurden frühzeitig wichtige Weichenstellungen versäumt. Die Erfahrung zeigt: Gerade in technisch komplexen Projekten ist ein klar verantwortlicher Product Owner entscheidend für Orientierung und Steuerung.       

Lesson Learned: In komplexen technischen Projekten ist eine frühzeitig besetzte und aktiv agierende Product-Owner-Rolle entscheidend, um Anforderungen zu priorisieren, Entscheidungswege zu steuern und das Team inhaltlich auszurichten. Fehlt diese Rolle zu Projektbeginn, entstehen Unklarheiten und Verzögerungen, da strategische Entscheidungen nicht rechtzeitig getroffen werden.

Projektstruktur in Phasen

Fehler: Im vorliegenden Projekt wurde nicht in klar abgegrenzte Phasen gearbeitet. Analyse, Konzeption und Umsetzung verliefen teilweise parallel oder unscharf getrennt, wodurch wichtige Entscheidungen unter Zeitdruck getroffen wurden – ohne fundierte technische Grundlage. Diese Vermischung führte zu unrealistischen Erwartungshaltungen, unklarer Planungssicherheit und Mehraufwand in der Umsetzung.  

Lesson Learned: Eine Dreiteilung in klare Projektphasen – 1) Situationsanalyse und Konzeption, 2) Umsetzung und Test, 3) Go-Live und Dokumentation – hätte eine bessere Steuerbarkeit und Erwartungshaltung bei allen Beteiligten ermöglicht. Insbesondere die Trennung von Analyse und Umsetzung ist essenziell, wenn der Projektumfang und die Risiken noch nicht vollumfänglich bekannt sind.

Hybrider 
Ansatz 

Fehler: Im Projekt wurde von Beginn an eine vollständige Re-Architektur angestrebt, obwohl Budget, Zeitrahmen und technisches Know-how für diesen Ansatz nicht ausreichend vorhanden waren. Diese ambitionierte Strategie führte zu hoher Komplexität, langsamen Fortschritten und zunehmender Überforderung im Team.

Lesson Learned: Hybrider Ansatz als Migrationsziel wäre hier wegen dem Budget am besten geeignet. Es ist eine Mischform. Nicht alles wird sofort neu gebaut, sondern bestehende Teile werden selektiv modernisiert oder in die Cloud überführt. Dies ist oft ein strategischer Kompromiss zwischen Lift & Shift und vollständiger Re-Architektur. Guter Mittelweg bei begrenztem Budget oder Zeitrahmen. Kritische Komponenten können stabil bleiben, während einzelne Teile (z. B. Medien, Caching, Auth) modernisiert werden. Ermöglicht schrittweises Lernen und Wissenstransfer im Team

©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.