Der Auslöser ist meistens ein Termin: Der Rechenzentrumsvertrag läuft aus, die Hardware ist am Ende, die Virtualisierungslizenz wird plötzlich dreimal so teuer. Ich plane und begleite den Umzug nach AWS, mit einer Kostenrechnung, die vor dem Umzug steht, und einem geprobten Rückweg für jeden Schritt.
Bestandsaufnahme und Kostenmodell als abgeschlossenes Zwei- bis Vier-Wochen-Mandat. Migration danach in Wellen, nach Risiko sortiert.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Migrationen scheitern selten an der Technik. Sie scheitern daran, dass niemand vollständig weiß was eigentlich läuft: welche Anwendung von welcher Datenbank abhängt, welcher Cronjob seit acht Jahren nachts etwas Wichtiges tut, welche Firewall-Regel warum existiert. Diese Karte entsteht sonst erst unter Zeitdruck, und dann zu spät.
Der zweite Klassiker ist die Rechnung. Wer eins zu eins umzieht, nimmt seine Auslastungsprobleme mit und zahlt in der Cloud künftig pro Stunde dafür. Deshalb gehört die Kostenrechnung vor den Umzug und nicht in die Rückschau, und deshalb lautet die ehrliche Empfehlung bei manchen Systemen, sie vorher zu ändern oder gar nicht mitzunehmen.
Typische SymptomeWas läuft wo, wovon hängt es ab, wer benutzt es. Ich nehme Server, Dienste, Datenbanken, Jobs und Datenflüsse auf und mache die Abhängigkeiten sichtbar, inklusive der Dinge, die niemand mehr auf dem Zettel hat. Diese Karte ist die Grundlage für alles Weitere.
Nicht alles gehört gleich behandelt. Manches wird umgehoben, manches beim Umzug auf Container gestellt, manches umgebaut, und manches abgeschaltet, weil es niemand mehr braucht. Für jede Anwendung fällt diese Entscheidung begründet und mit Aufwand hinterlegt.
Was kostet der Zielzustand monatlich, realistisch und auf Basis Ihrer tatsächlichen Auslastung statt Ihrer Serverausstattung. Inklusive der Posten, die in der ersten Rechnung überraschen: Datentransfer, NAT-Gateways, Logs, Backups. Wo ein Umzug eins zu eins teuer würde, steht das vorher fest.
Bevor die erste Anwendung umzieht steht das Fundament: Kontenstruktur, Netzwerk, Zugriff über SSO statt Dauer-Zugangsschlüssel, zentrale Protokollierung und Verschlüsselung. Alles in Terraform, damit es reproduzierbar bleibt und im Audit erklärbar ist.
Datenbanken ziehen mit Replikation um, das Umschaltfenster liegt im Minutenbereich. Für jeden Schritt gibt es einen Rollback-Pfad, der geprobt wird bevor er gebraucht wird. Migriert wird in Wellen, sortiert nach Risiko: die unkritischen Systeme zuerst, damit das Team Routine hat bevor es ernst wird.
AWS zu betreiben ist etwas anderes als Server zu betreiben. Monitoring, Alarme, Runbooks und eine Kostenkontrolle, die nicht erst am Monatsende auffällt. Dazu Pairing mit Ihrem Team, bis der Regelbetrieb ohne mich läuft.
Die Bestandsaufnahme ist ein abgeschlossenes Mandat. Danach entscheiden Sie mit Zahlen, ob und wie es weitergeht.
Auslöser, Termin, Umfang, wer es danach betreibt. 30 Minuten reichen für die erste Einschätzung.
Inventar, Abhängigkeiten, Migrationspfad je Anwendung und Kostenmodell für den Zielzustand.
Konten, Netzwerk, Rechte und Protokollierung in Terraform, bevor die erste Anwendung umzieht.
Unkritisches zuerst, Geschäftskritisches zuletzt. Jede Welle mit Cutover-Plan und geprobtem Rollback.
Was in der Rechnung steht, war vorher bekannt. Kein System, das erst beim Abschalten auffällt.
Konten, Netzwerk und Rechte kommen aus Terraform. Die zweite Umgebung ist ein Apply, keine Woche Arbeit.
Runbooks, Monitoring und Pairing statt einer Umgebung, die am Ende nur der Dienstleister versteht.
Das ist die Frage, die vor dem Umzug beantwortet gehört. Das Kostenmodell entsteht in der Bestandsaufnahme auf Basis Ihrer tatsächlichen Auslastung, nicht Ihrer Serverausstattung, inklusive der Posten, die in der ersten Rechnung überraschen: Datentransfer, NAT-Gateways, Logs, Backups.
Nicht immer und nicht für alles. Wer eins zu eins umzieht, nimmt seine Auslastungsprobleme mit und zahlt künftig pro Stunde dafür. Für manche Systeme ist die ehrliche Empfehlung, sie vorher zu ändern oder gar nicht mitzunehmen. Das steht nach der Bestandsaufnahme fest, und wenn die Rechnung insgesamt nicht aufgeht, sage ich das auch.
Die Bestandsaufnahme zwei bis vier Wochen. Der Umzug selbst hängt an Anzahl und Verflechtung der Systeme. Belastbar wird das erst mit der Abhängigkeitskarte. Migriert wird in Wellen, damit früh etwas fertig ist und nicht alles am Ende gleichzeitig passiert.
Dafür gibt es für jeden Schritt einen Rollback-Pfad, der vorher geprobt wird. Deshalb ziehen auch die unkritischen Systeme zuerst um: damit das Team den Ablauf im Griff hat, bevor es an das Geschäftskritische geht.
Ja, und häufig ist das sinnvoll, etwa wegen Latenz, Lizenzen oder laufender Abschreibung. Dann geht es um eine saubere, abgesicherte Anbindung zwischen beiden Welten statt um einen vollständigen Umzug.
Die Infrastruktur hinter produktiven KI-Systemen: MCP-Server, sichere Tool-Anbindung, LLM-Integration mit Zugriffsschutz und Kostenkontrolle.
Mehr erfahrenManuelle Abläufe durch echte Systeme ersetzen: angebunden an Ihre Bestandssysteme, mit Berechtigungen und Protokoll statt Tool-Kette.
Mehr erfahrenIch finde wo Ihr AWS-Budget versickert, messbar reduziert, ohne Abstriche bei Performance oder Verfügbarkeit.
Mehr erfahrenGewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenBackends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahren