Cloud-Migration:
Kunden gewinnen als Cloud-Dienstleister

Die ungewöhnlich lange Cloud-Recherche

Cloud-Migrationen werden anders eingekauft als jede andere IT-Dienstleistung. Sie haben eine ausgedehnte, oft sechs- bis neunmonatige Lesephase, bevor der erste externe Kontakt stattfindet. In dieser Phase liest der Cloud-Architekt mehr als er spricht. Er liest Whitepapers, Architecture Center, Re-Invent-Recaps, Microsoft Ignite Highlights, FinOps-Foundation-Material, Hacker News, deutsche Fachartikel, GitHub-Diskussionen. Er bildet sich seine eigene Meinung, bevor er sich gegenüber dem Vorstand oder CTO positioniert.

Diese Lesephase ist der Punkt, an dem ein Cloud-Dienstleister sichtbar werden muss. Wer dort als kompetente Stimme auftaucht, kommt in die mentale Auswahl, lange bevor das offizielle Vergabeverfahren startet. Wer dort fehlt, wird selbst bei späterem direktem Kontakt als unbekannter Player wahrgenommen. Cloud-Mandate werden selten in einem Pitch entschieden, sondern in der Recherche-Phase davor.

Wie dieser Vorprojekt-Mechanismus für IT-Dienstleister insgesamt funktioniert, behandeln wir im Pillar-Artikel IT-Kunden gewinnen. Für Cloud-Dienstleister gilt die zugespitzte Variante: Weil die Recherche länger und tiefer ist, ist die Investition in inhaltliche Tiefe besonders rentabel. Ein einziger Architektur-Artikel kann zwölf Monate später ein siebenstelliges Mandat begründen.

Wer in der Cloud-Vorprojekt-Phase googelt

Eine Cloud-Migration ist nie eine Ein-Personen-Entscheidung. Fünf Rollen sind typischerweise beteiligt, jede mit eigenem Suchverhalten und eigenen Bewertungskriterien. Wer den Cluster nur für eine dieser Rollen baut, verliert die anderen vier. Wer alle fünf bedient, wird in der internen Diskussion mehrfach zitiert, bevor ein Termin entsteht.

Die fünf Stimmen am Tisch

72 Prozent der B2B-Entscheider geben an, dass durchdachter Thought-Leadership-Content sie zu einer Beratung führt, die sie sonst nicht in Betracht gezogen hätten1. Im Cloud-Markt ist dieser Effekt besonders ausgeprägt, weil die Entscheidung mit unklaren Bewertungskriterien (welche Tiefe ist genug?) über mehrere Monate fällt. Wer in dieser Lage als technisch kompetent wirkt, wird zur Default-Option.

Wie topische Autorität konzeptionell entsteht und warum Vollständigkeit der Themen-Abdeckung wichtiger ist als einzelne Top-Rankings, behandelt unser Artikel zu topische Autorität aufbauen.

Migrationsstrategien sichtbar als Entscheidungs-Hilfe machen

Die fünf gängigen Migrationsstrategien (in der Branche oft als 6R bekannt, mit Retain als sechster Option) sind die meistgesuchten Cloud-Begriffe in der Vorprojekt-Phase. Trotzdem werden sie auf den meisten Anbieter-Webseiten als reine Definitionen behandelt, statt als operative Entscheidungs-Hilfe positioniert. Wer hier die Lücke füllt, gewinnt einen Themenraum, der direkten Conversion-Bezug hat.

Die fünf operativ wichtigsten Strategien

Erstens, Lift-and-Shift (Re-Host). Die Anwendung wird ohne Veränderung in die Cloud verschoben. Schnellste Umsetzung, niedrigste Risiken bei der Migration selbst, häufig aber hohe Folgekosten in der Cloud-Rechnung und wenig Nutzen aus Cloud-Native-Diensten. Sinnvoll bei Zeitdruck, Vertrags-Stichtagen mit dem alten Rechenzentrum oder als erster Schritt einer Schrittfolge.

Zweitens, Re-Platform. Die Anwendung wird leicht verändert, um Cloud-Native-Dienste zu nutzen (Managed Database statt selbst betriebene DB, Object Storage statt File Server). Mittlerer Aufwand, deutliche Vorteile in Betrieb und Kosten. Häufig die pragmatischste Wahl für etablierte Anwendungen.

Drittens, Refactor. Die Anwendung wird grundlegend umgebaut, oft in Microservices und Cloud-Native-Architektur. Höchster Aufwand, größtes langfristiges Potenzial. Sinnvoll bei Anwendungen, die ohnehin modernisiert werden müssen, oder bei strategischer Bedeutung für die Geschäftsentwicklung.

Viertens, Re-Host mit Optimierung. Variante von Lift-and-Shift, bei der unmittelbar nach der Migration ein Optimierungs-Sprint eingeplant ist (Right-Sizing, Reservierungen, Storage-Tiering). Senkt die Folgekosten deutlich, ohne die Anwendung selbst zu verändern.

Fünftens, Retire oder Repatriate. Nicht jede Anwendung gehört in die Cloud. Manche wird stillgelegt, andere zurück ins eigene Rechenzentrum geholt (Cloud Repatriation), wenn die Wirtschaftlichkeit nicht stimmt. Wer diese Option offen und ehrlich diskutiert, gewinnt Vertrauen bei Entscheidern, die in der Cloud schon einmal überrascht wurden.

FinOps und Compliance: Die zwei stärksten Conversion-Hebel

Cloud-Themen ranken sehr unterschiedlich. Generische Begriffe ("Was ist die Cloud") bringen Reichweite, aber kaum Anfragen. Architektur-Themen bauen Autorität, konvertieren aber langsam. Die zwei Themen-Bereiche mit dem höchsten Conversion-Druck sind FinOps und Compliance. Beide sind im DACH-Markt deutlich unterbesetzt.

Warum FinOps so stark konvertiert

Viele Unternehmen haben in der Cloud die Kosten unterschätzt. Was als Effizienz-Versprechen begonnen hat, endet oft in einer Cloud-Rechnung, die schneller wächst als das Geschäft. Wenn diese Erkenntnis im CFO-Office ankommt, wird gegoogelt: "AWS Kosten explodiert", "Cloud Cost Optimization Mittelstand", "FinOps Foundation Reifegrad", "Cloud Spend Reduction". Diese Suchen kommen aus einem konkreten Druck-Moment. Wer hier methodisch klar erklärt, wie FinOps strukturiert wird, mit Tagging-Strategie, Cost Allocation, Reservierungen, Right-Sizing und Reporting, gewinnt einen Themenraum, in dem die Konversion sehr hoch ist.

Warum Compliance der zweite Hebel ist

Compliance in der Cloud ist im deutschen Markt eine eigene Welt. BSI C5 ist der praktische Standard, ISO 27017 die internationale Variante, der EU Data Act schafft seit 2024/2025 neue Klarheit zur Datensouveränität, NIS2 erweitert die Compliance-Pflichten für KRITIS-Unternehmen auch in der Cloud. Diese Themen sind operativ konkret, regulatorisch verbindlich und im Suchverkehr deutlich unterbesetzt. Wer hier strukturiert dokumentiert, gewinnt Anfragen von Security- und Compliance-Funktionen, die genau jetzt nach Anbietern suchen, die diese Anforderungen wirklich umsetzen.

Wichtig zur Einordnung: Die Werte sind aus Beobachtung gewichtete Indikatoren, nicht studienbasierte Konversionsraten. Die Aussage dahinter ist robust: Je näher der Inhalt an der konkreten Druck-Frage des Lesers liegt, desto höher die Wahrscheinlichkeit, dass die Lektüre in eine Anfrage mündet. Generische Übersichten sind nicht wertlos, aber sie tragen den Cluster, sie verkaufen nicht.

Eine Fallstudie aus dem IT-Dienstleister-Bereich zeigt, was möglich ist: Ein IT-Spezialist konnte über systematischen Cluster-Aufbau seinen organischen Traffic um 327 Prozent steigern, mit entsprechender Steigerung qualifizierter Anfragen2. Die Mechanik ist dieselbe: thematische Tiefe plus interne Verlinkung plus klare Stakeholder-Adressierung. Für Cloud-Dienstleister kommt die hohe Suchnachfrage in FinOps und Compliance als zusätzlicher Beschleuniger hinzu.

Wie ein Cloud-Cluster konkret aussieht

Ein Cloud-Cluster ist keine Sammlung loser Artikel zur Cloud. Er ist eine systematische Abdeckung eines klar abgegrenzten Bereichs, in dem Sie als Dienstleister die authoritative Quelle im deutschsprachigen Markt sein wollen. Die Wahl dieses Bereichs ist die wichtigste strategische Entscheidung. Zu breit erzeugt Verzettelung. Zu eng begrenzt das Anfragevolumen.

Beispiel: Ein Dienstleister, der sich auf AWS-Migrationen für SaaS-Unternehmen mit 50 bis 250 Mitarbeitern in der DACH-Region spezialisiert hat. Das ist kein zu breiter Bereich wie "Cloud" und kein zu enger wie "AWS Lambda Tuning". Es ist genau die Größe, in der ein fokussiertes Team in 10 bis 16 Monaten thematische Autorität aufbauen kann.

Warum die Struktur funktioniert

Jede Cluster-Ebene bedient eine andere Stimme am Tisch (vgl. Abschnitt 2). Architektur-Artikel ziehen den Cloud-Architekten, Strategie-Artikel den CTO, FinOps-Artikel die Finanzfunktion, Compliance-Artikel Security und Vergleichs-Artikel die Geschäftsführung. Die Pillar Page bindet alles zusammen und signalisiert der Suchmaschine, dass diese Domain die Referenz für das Gesamtfeld ist3.

Interne Verlinkung ist das Fundament dieser Architektur. Jeder Cluster-Artikel verlinkt zurück zur Pillar Page und zu mindestens 2 bis 3 thematisch passenden anderen Cluster-Artikeln. Die Pillar Page verlinkt auf alle Cluster-Artikel. Diese Vernetzung ist es, die Google als topische Autorität liest, nicht die Anzahl der Artikel allein. Wie diese Mechanik im IT-Dienstleister-Markt typischerweise verläuft, mit konkreten Wachstumskurven, zeigen wir im Detail unter Content-Cluster für IT-Dienstleister: Ergebnisse.

Ein realistischer Aufbau-Rhythmus

Im Pillar-Hub zu IT-Kunden gewinnen ordnen wir Cloud-Spezialisierungen ins Gesamtbild der IT-Dienstleister-Akquise ein. Die Cloud-Variante hat die längste Compound-Phase, dafür auch die höchsten Mandats-Volumina pro qualifizierter Anfrage.

Was es braucht um anzufangen

Die größte Hürde ist nicht das Schreiben. Die größte Hürde ist die Spezialisierungs-Entscheidung. Cloud-Dienstleister wollen verständlicherweise alle drei Hyperscaler und alle Branchen erreichen und positionieren sich entsprechend breit. Genau diese Breite verhindert die topische Autorität, die organische Anfragen erst auslöst. Wer alles macht, ist für Google in nichts die Referenz.

Drei Vorbereitungs-Entscheidungen

Erstens: Hyperscaler und Branche wählen. Nicht "wir können AWS, Azure und GCP", sondern die Kombination, in der Sie nachweislich heute schon stark sind. Wenn 8 von 10 Mandaten auf AWS laufen, ist AWS Ihr Cluster-Bereich. Die anderen können als Vergleichs-Artikel später ergänzt werden, sind aber nicht das Fundament. Eine Hauptbranche (z.B. SaaS, E-Commerce, Industrie) schärft den Cluster zusätzlich.

Zweitens: Themen-Cluster definieren. Listen Sie 25 bis 35 Suchanfragen, die ein Idealkunde in den kommenden 6 Monaten realistisch googeln wird, kombiniert mit den fünf Stakeholder-Stimmen aus Abschnitt 2. Wenn Sie diese Liste nicht zusammenbekommen, kennen Sie Ihre Nische nicht gut genug. Aus dieser Liste entstehen die Pillar Page (der Oberbegriff) und die Cluster-Artikel (die Detail-Fragen).

Drittens: Operative Verantwortung klären. Ein Cluster ohne Halter scheitert, gerade in der Cloud-Welt, wo technische Aktualität wichtig ist. Wer entscheidet über Themen, wer schreibt, wer lektoriert fachlich, wer aktualisiert nach Produkt-Updates, wer veröffentlicht? Die Antwort darf "wir mit Unterstützung" sein, sie darf nicht "wir, irgendwie" sein.

Was Vertrauen ergänzt, das der Cluster aufbaut

Cloud-Dienstleistung bleibt ein Vertrauensmarkt. Der Cluster ist der Verstärker, nicht der Ersatzkanal. Drei Dinge wirken parallel: Erstens, Hyperscaler-Partner-Status (AWS Advanced Tier, Azure Solutions Partner, GCP Partner) bleibt ein Trust-Anker. Zweitens, technische Konferenzauftritte (Re:Invent, Ignite, KubeCon, FinOps X) und Open-Source-Beiträge vertiefen Autorität in der Community, die der Cluster im zweiten Schritt aufgreift. Drittens, Empfehlungen aus dem Kunden- und Partnernetzwerk bleiben die wichtigste Quelle für die größten Mandate.

Der Unterschied: Ohne Cluster werden Partner-Status, Auftritte und Empfehlungen zu Punkten. Mit Cluster werden sie zu einem Netz. Wer als AWS Advanced Tier Partner empfohlen wird und dann eine Webseite findet, die seine FinOps- und Migrationserfahrung im richtigen Sektor in der richtigen Sprache belegt, konvertiert höher als jemand, der nur den Partner-Status kennt. Das ist der Grund, warum der Cluster nichts ersetzt, sondern alles, was Sie ohnehin tun, hebt.

Im IT-Mittelstand entscheiden Käufer im Median nach Konsum mehrerer Inhalts-Berührungen, oft 7 bis 13 Touchpoints über mehrere Wochen4. Cloud-Käufer sind keine Ausnahme, sie sind die ausführlichste Variante: dieselben Touchpoints, über mehrere Monate, mit fünf Stakeholdern parallel. Die Folge: Wer in mehreren dieser Touchpoints auftaucht, wird zur Default-Wahl5.

Häufig gestellte Fragen