CloudHound misst jeden Server, bepreist ihn anhand aktueller Tarife von AWS, Azure, Google Cloud und Oracle Cloud und migriert ihn in die Cloud Ihrer Wahl.
Jeder Datensatz ist eine Messung von einem laufenden Server: CPU, Arbeitsspeicher, Datenträger, Prozesse und Netzwerkflüsse. Mit denselben Daten wird die Umgebung bepreist, geplant und migriert.
Ein typisches Projekt, Tag für Tag.
Ein Befehl pro Server oder agentenlos über SSH und WinRM. Inventar, Prozesse und Verbindungen sind sofort da.
CPU, Arbeitsspeicher und Datenträger werden jede Minute gemessen, und jeder Server ist innerhalb von Minuten beschrieben.
Jeder Server zu aktuellen Preisen von AWS, Azure, Google Cloud und Oracle Cloud bepreist: On-Demand, Reserved und Savings Plan nebeneinander.
Fünf Tage Netzwerkflüsse werden zu Anwendungen gruppiert.
Aus der Abhängigkeitskarte wird ein Wellenplan erstellt. Anwendungen lassen sich zwischen Wellen verschieben.
Jede Welle wird repliziert, Block für Block verifiziert, konvertiert und in der gewählten Cloud gestartet. 125 Server in 12 Minuten auf EC2.
Beim Anlegen eines Portfolios wählen Sie eine von siebzehn Hosting-Regionen. Agenten in jedem Land melden sich über ausgehendes TLS bei dieser Region, und ihre Daten werden ausschließlich dort verarbeitet und gespeichert.
Der Agent erfasst ohne Unterbrechung hochauflösende Auslastung mit Minutenauflösung: CPU, Arbeitsspeicher sowie die Operations- und Bytezähler jedes Laufwerks. Jeder Server wird anhand von sieben Tagen mit Messwerten im Minutentakt nach seiner gemessenen Nutzung dimensioniert. Hier eine Woche eines beispielhaften Anwendungsservers mit 8 vCPU, 32 GiB und neun Laufwerken, dessen CPU und Arbeitsspeicher der Woche eines Produktionsservers nachgebildet sind.
Was CloudHound nach einer Woche Erkennung über einen typischen Anwendungsserver weiß. Der Server ist ein Beispiel, aber jedes Feld darauf erfasst der Agent.
Eine Beispielumgebung, so gezeichnet, wie CloudHound Ihre Umgebung aus den Netzwerkflüssen zwischen Ihren Servern zeichnet: 145 Server, 780 Verbindungen, in Anwendungen gruppiert. Ziehen Sie einen Server, zeigen Sie darauf, um seine Verbindungen zu sehen, und klicken Sie auf eine Anwendung, um sie hervorzuheben.
CloudHound erkennt, welche Server miteinander kommunizieren, und gruppiert sie anhand dieses Verkehrs in Anwendungen. Jede Anwendung kommt dann mit den Datenbanken, von denen sie abhängt, in eine Migrationswelle, sodass nichts ohne die benötigten Systeme umzieht. Dieses Beispiel begleitet 1.000 Server von der Erkennung bis zu einem Plan mit zehn Wellen. Zum Drehen ziehen.
CloudHound migriert jeden Server auf eine von zwei Arten. Es kann den ganzen Server als exakte, verifizierte Kopie auf AWS, Azure, Google Cloud oder Oracle Cloud umziehen (Rehosting). Auf AWS kann es außerdem die Datenbanken des Servers direkt auf Amazon RDS for SQL Server, PostgreSQL, MySQL oder MariaDB umstellen (Replatforming).
CloudHound unterstützt 135 Betriebssystemvarianten und kann 99,5 % der Unternehmensserver migrieren, die wir im Einsatz gesehen haben.
Viele Windows-Server, die zu AWS wechseln, laufen mit einer Version, die Microsoft nicht mehr unterstützt. CloudHound kann sie während der Migration auf Windows Server 2025 aktualisieren, sodass sie mit Support bis November 2034 ankommen.
Die Migration auf Blockebene kopiert die Blöcke der Festplatte, daher ist das Ergebnis ein exakter Klon, der wie die Quelle startet. Die Quelle wird nie verändert. Rohe Blöcke werden mit Plattengeschwindigkeit gelesen: In unserem Benchmark wurde ein 1-TiB-Datenträger in 255 Sekunden kopiert. Jeder weitere Durchlauf überträgt nur geänderte Blöcke, sodass die finale Synchronisierung nur die letzten Änderungen enthält. Vor dem Start wird das Zielvolume zurückgelesen und Block für Block mit der Quelle verglichen, dann wird die Festplatte passend dimensioniert. Die Werte unten stammen von einer Beispielfestplatte.
Wenn Server in der Cloud starten, prüft CloudHound, ob alles so zurückgekommen ist, wie es auf der Quelle lief - jeder Dienst, jeder Port, jede Datenbank, jedes Volume und jeder Netzwerkpfad.
Keines der Probleme liegt am Server. Der Routing-Tabelle seines Subnetzes in AWS fehlt eine Route zu zwei lokalen Netzwerken. Öffnen Sie diese Routing-Tabelle in der VPC-Konsole und fügen Sie hinzu:
10.20.8.0/2410.20.9.0/24Eine Wiedergabe unseres Benchmarks vom September 2026: 125 Server mit 94 Betriebssystemvarianten und 140 Festplatten mit insgesamt 9,3 TiB, jeder repliziert, Block für Block verifiziert, konvertiert, gebootet und auf EC2 bestätigt.

„CloudHound verschafft uns sofort Klarheit über komplexe Umgebungen - von der Erkennung bis zur Wellenplanung. So liefern wir unseren Kunden schneller Ergebnisse, hinter denen wir sicher stehen können.“
Leiter Migrationen
AWS Premier Partner