OutaCloud Calculator v1.1: Migrationskosten transparent erklärt

Mit dem Update auf Version 1.1 zeigt unser Kostenrechner jetzt eine geschätzte Preisspanne für die Migration an. In diesem Beitrag erklären wir, wie diese Berechnung funktioniert und welche Faktoren die tatsächlichen Migrationskosten beeinflussen.

Inhaltsverzeichnis

• Was ist neu in v1.1
• Wovon hängen Migrationskosten ab?
  • Zielinfrastruktur Setup (Proxmox)
  • Migrationstyp: Lift & Shift vs. Refactoring
    • Lift & Shift (einfacher, günstiger)
    • Refactoring (komplexer, teurer)
  • Weitere Faktoren
• Beispielszenarien
  • Szenario 1: Kleines Setup (unteres Ende der Spanne)
  • Szenario 2: Mittleres Setup (Mitte der Spanne)
  • Szenario 3: Komplexes Setup (oberes Ende der Spanne)
• Fazit

Was ist neu in v1.1

Die wichtigste Neuerung: Der Calculator zeigt jetzt eine geschätzte Migrations-Gebühr an, sobald du deine Ersparnis berechnet hast. Diese Spanne basiert auf dem 4- bis 6-fachen deiner monatlichen Ersparnis.

Warum diese Formel?

Aus unseren bisherigen Migrationsprojekten wissen wir, dass sich die Investition in eine Migration typischerweise innerhalb von 4 bis 6 Monaten amortisiert. Ein Kunde, der beispielsweise 1.000 € pro Monat spart, kann mit Migrationskosten zwischen 4.000 € und 6.000 € rechnen. Nach spätestens einem halben Jahr hat sich die Migration bezahlt gemacht — danach ist jeder gesparte Euro reiner Gewinn.

Diese Spanne gibt dir eine erste Orientierung. Die tatsächlichen Kosten hängen von mehreren Faktoren ab, die wir im Folgenden erläutern.

Wovon hängen Migrationskosten ab?

Migrationskosten setzen sich aus zwei Hauptkomponenten zusammen: dem Setup der Zielinfrastruktur und der eigentlichen Migration deiner Workloads.

Zielinfrastruktur Setup (Proxmox)

Bevor deine VMs und Services migriert werden können, muss die neue Infrastruktur stehen. Dieser Aufwand umfasst:

Cluster-Design und Installation

Basierend auf deinen Anforderungen designen wir die optimale Proxmox-Cluster-Architektur. Das beinhaltet die Anzahl der Nodes, die Verteilung der Ressourcen und die Planung für zukünftiges Wachstum. Die Installation und Grundkonfiguration von Proxmox VE erfolgt auf allen Servern.

Netzwerkkonfiguration

Ein sauberes Netzwerk-Setup ist entscheidend für Performance und Sicherheit. Wir konfigurieren VLANs zur Trennung verschiedener Netzwerksegmente, richten die Firewall-Regeln ein und stellen sicher, dass die Kommunikation zwischen den Nodes und nach außen optimal funktioniert.

Storage-Setup

Je nach Anforderung implementieren wir verschiedene Storage-Lösungen:

• ZFS für lokalen Storage mit Snapshots und Komprimierung
• Ceph für verteilten Storage über mehrere Nodes mit Redundanz
• NFS/iSCSI für Anbindung an externe Storage-Systeme

Die Wahl hängt von deinen Performance-Anforderungen, dem Budget und der gewünschten Redundanz ab.

Hochverfügbarkeit (HA)

Für produktionskritische Workloads konfigurieren wir Proxmox HA. Bei einem Node-Ausfall werden VMs automatisch auf einem anderen Node neu gestartet. Das erfordert mindestens drei Nodes und entsprechendes Shared Storage.

Du benötigst Unterstützung bei deinem Proxmox-Cluster? Unser Proxmox Support hilft dir bei Design, Installation und Betrieb.

Migrationstyp: Lift & Shift vs. Refactoring

Der größte Kostenfaktor ist die Art der Migration. Hier unterscheiden wir zwei grundlegende Ansätze:

Lift & Shift (einfacher, günstiger)

Bei Lift & Shift übertragen wir deine VMs und Container weitgehend unverändert auf die neue Infrastruktur. Das ist möglich, wenn:

• Deine Workloads auf Standard-VMs laufen (EC2, Azure VMs, GCE)
• Keine tiefen Abhängigkeiten zu Cloud-spezifischen Services bestehen
• Das Betriebssystem und die Anwendungen auf dedizierter Hardware funktionieren

Typische Tools und Methoden:

• Image-Export und -Import
• Block-Level-Kopien mit dd oder ähnlichen Tools
• Datei-basierte Migration mit rsync
• Proxmox-eigene Migrations-Tools

Lift & Shift ist der schnellste und günstigste Weg. Eine typische VM-Migration dauert je nach Datenmenge wenige Stunden bis einen Tag.

Refactoring (komplexer, teurer)

Refactoring ist nötig, wenn Cloud-native Services durch Self-Managed-Alternativen ersetzt werden müssen. Das betrifft vor allem:

Managed Databases

AWS RDS, Azure SQL oder Cloud SQL bieten Features wie automatische Backups, Point-in-Time-Recovery und Read Replicas "out of the box". Bei einer Migration zu Proxmox müssen diese Funktionen manuell konfiguriert werden:

• Installation und Konfiguration von PostgreSQL, MySQL oder MariaDB
• Einrichtung von Backup-Jobs und Retention Policies
• Konfiguration von Replikation für Hochverfügbarkeit
• Monitoring-Integration

Serverless und FaaS

AWS Lambda, Azure Functions oder Cloud Run haben keine direkte Entsprechung auf dedizierter Infrastruktur. Alternativen sind:

• Container-basierte Deployments mit Docker/Podman
• Kubernetes für komplexere Setups
• Klassische Anwendungs-Server

Managed Services

Dienste wie AWS SQS, SNS, ElastiCache oder Cloud CDN müssen durch Self-Hosted-Alternativen ersetzt werden (RabbitMQ, Redis, eigenes CDN-Setup).

Refactoring erfordert mehr Planungsaufwand, Testing und oft Anpassungen am Anwendungscode. Der Aufwand kann erheblich sein, aber das Ergebnis ist eine vollständig kontrollierte Infrastruktur ohne Vendor-Lock-in.

Weitere Faktoren

Anzahl der VMs und Services

Mehr VMs bedeuten mehr Migrationsaufwand. Bei größeren Setups können wir aber effizienter arbeiten, da sich viele Schritte wiederholen oder parallelisieren lassen.

Downtime-Anforderungen

Eine Migration mit minimaler Downtime erfordert aufwendigere Verfahren wie Live-Migration oder Datenbank-Replikation mit Cutover. Bei planbarer Wartungszeit ist der Aufwand geringer.

Compliance und Dokumentation

Regulierte Branchen (Finanzsektor, Gesundheitswesen) erfordern oft zusätzliche Dokumentation, Audit-Trails und Zertifizierungen. Das fließt in den Gesamtaufwand mit ein.

Beispielszenarien

Um die Kostenspanne greifbar zu machen, hier drei typische Szenarien:

Szenario 1: Kleines Setup (unteres Ende der Spanne)

• 3 Standard-EC2-Instanzen (Web-Server, App-Server, Datenbank)
• Keine Cloud-native Dependencies
• Geplantes Wartungsfenster möglich

Migration: Klassisches Lift & Shift. VMs werden exportiert und auf Proxmox importiert. IP-Adressen und DNS werden umgestellt. Aufwand: wenige Tage.

Szenario 2: Mittleres Setup (Mitte der Spanne)

• 10 EC2-Instanzen für verschiedene Services
• 1 RDS PostgreSQL-Instanz (Managed)
• S3 für Datei-Storage

Migration: Lift & Shift für die EC2-Instanzen. Refactoring für RDS (Self-Managed PostgreSQL mit pgBackRest für Backups). S3 wird durch MinIO oder lokales Storage ersetzt. Aufwand: 1-2 Wochen.

Szenario 3: Komplexes Setup (oberes Ende der Spanne)

• 25+ VMs über mehrere AWS-Accounts
• RDS, ElastiCache, SQS in Verwendung
• Lambda-Funktionen für Background-Jobs
• Minimale Downtime erforderlich

Migration: Kombination aus Lift & Shift und umfangreichem Refactoring. Lambda wird zu Container-Workloads umgebaut. Managed Services werden durch Self-Hosted-Alternativen ersetzt. Live-Migration für kritische Systeme. Aufwand: mehrere Wochen bis Monate.

Fazit

Der neue Calculator v1.1 gibt dir eine transparente Ersteinschätzung der Migrationskosten. Die angezeigte Spanne (4-6x monatliche Ersparnis) ist ein guter Richtwert, der sich in unseren Projekten bewährt hat.

Die tatsächlichen Kosten hängen von deiner spezifischen Situation ab — insbesondere davon, ob ein einfaches Lift & Shift möglich ist oder Refactoring nötig wird.

Nächste Schritte:

1. Calculator ausprobieren und Ersparnis berechnen
2. Detaillierte Migrations-Analyse über das Formular anfordern
3. Wir melden uns mit einem individuellen Angebot

Nach der Migration profitierst du nicht nur von den niedrigeren laufenden Kosten, sondern auch von unserem Proxmox Monitoring für den sicheren Betrieb deiner neuen Infrastruktur.