Unsere Leistungen
Unterstützung für Wachstumsstrategien, Transformationen oder M&A-Prozessen.
Unsere Freelance Experts verfügen über tiefgehendes Fachwissen in ihrem Bereich.
Wir liefern Ihnen erfahrene Interim Manager, die Verantwortung übernehmen.
Maßgeschneiderte Expertenteams für komplexe Projekte
Für diese Unternehmen finden wir die besten Experten
Private Equity
Effiziente Unterstützung im gesamten Deal Cycle
Unternehmensberatungen
Flexible Ressourcen für anspruchsvolle Projekte
Mittelstand
Beratungsexpertise für den Mittelstand
Corporates
Fach- und Führungsexperten für operative Exzellenz
Scale-Ups
Strategische & operative Unterstützung für Wachstum
Standortbestimmung

Was Cloud-Beratung leistet — und was nicht

Beraterin und Berater besprechen die Anwendungslandschaft eines Unternehmens vor einem Cloud-Umzug

Cloud-Beratung — im Markt ebenso geläufig als Cloud Consulting oder Cloud-Computing-Beratung — beantwortet, welcher Teil der eigenen IT in einer fremden Rechenzentrumsumgebung besser aufgehoben ist und was sich dadurch an Architektur, Betrieb und Verantwortung ändert. Ihr Gegenstand ist nicht die Auswahl eines Anbieters. Der eigentliche Unterschied zum klassischen Rechenzentrum steckt woanders, und er bestimmt, wo eine Beratung überhaupt etwas bewirken kann.

Cloud verlagert Kosten von der Anschaffung in die laufende Entscheidung. Im eigenen Rechenzentrum fällt der Betrag einmal an, bei der Beschaffung, und steht danach für Jahre fest; eine schlecht ausgelastete Maschine fällt in der Abschreibung auf, nicht am Monatsende. In einer Cloud-Umgebung erzeugt beinahe jede technische Entscheidung eine wiederkehrende Position: eine zu groß gewählte Datenbank, ein vergessener Testcluster, ein Datenpfad über eine Regionsgrenze. Die Summe steht nicht am Anfang fest — sie entsteht täglich neu, dort, wo gearbeitet wird.

Daran hängt, wo Beratung wirkt. Wirksam ist sie vor dem Umzug, wenn der Schnitt durch die Anwendungslandschaft gelegt wird: welche Anwendung wandert unverändert, welche wird vorher umgebaut, welche abgelöst, welche bleibt bewusst stehen. Wirksam ist sie in den Regeln, die Verbrauch begrenzen, bevor er entsteht — Netzwerkschnitt, Identitäten, Umgebungstrennung, Ablagepflichten. Und wirksam ist sie dort, wo jemand Rechnung und Architektur zusammen liest. Ohne diese dritte Stelle bleibt jede Kostenanalyse eine Momentaufnahme.

Wo Vorhaben regelmäßig aus dem Ruder laufen. Eine unveränderte Verlagerung überträgt eine gewachsene Landschaft samt ihrer Fehlauslastung in ein Modell, das genau diese Fehlauslastung monatlich abrechnet. Sie ist trotzdem oft die richtige erste Welle, weil sie den Standortvertrag löst — nur eben mit einem verabredeten Zeitpunkt, an dem nachgearbeitet wird. Fehlt dieser Zeitpunkt, wird aus der Übergangslösung ein Dauerzustand mit Mietpreis.

Was Cloud-Beratung nicht leistet. Sie ersetzt weder einen Plattformanbieter noch einen Betriebsdienstleister; die Umgebungen selbst betreiben Sie oder ein von Ihnen beauftragter Partner. Sie nimmt Ihnen auch die Abwägung zwischen Tempo und Bindung nicht ab — wie eng Sie sich an die Dienste eines Anbieters binden, ist eine unternehmerische Entscheidung, keine technische. Und sie ersetzt keine rechtliche Prüfung: Ob eine bestimmte Datenkategorie in eine bestimmte Umgebung darf, klären Datenschutz und Rechtsabteilung im Einzelfall. Wer den Umbau der Prozesse rundherum sucht, findet ihn in der Beratung für digitale Transformation.

Entscheidungspunkte

Wann externe Unterstützung ein Cloud-Vorhaben vom Fleck bringt

Nicht jedes Cloud-Vorhaben braucht Hilfe von außen. Wenn die Anwendungslandschaft überschaubar ist, im Haus schon einmal eine Umgebung sauber aufgebaut wurde und jemand die Zeit hat, das zweite Mal zu machen, ist der interne Weg der schnellere und der günstigere. In den folgenden Ausgangslagen fällt die Rechnung erfahrungsgemäß anders aus — nicht weil Wissen über die eigene IT fehlt, sondern Routine mit genau dieser Art von Umzug: Ein Unternehmen verlagert seine Kernsysteme einmal, unser Netzwerk begleitet solche Vorhaben laufend.

1. Eine Frist zwingt zur Entscheidung

  • Hardware am Ende ihres Lebenszyklus, auslaufender Standortvertrag, angekündigtes Supportende.
  • Der Termin steht fest, die Bewertung der Anwendungen nicht — und ohne Bewertung verlängert der Umzug nur das Bestehende.

2. Der Umzug läuft, die Rechnung erklärt sich nicht mehr

  • Der Verbrauch steigt, ohne dass jemand ihn einer Anwendung, einem Team oder einer Entscheidung zuordnen kann.
  • Ohne Zuordnung wird pauschal gekürzt — und getroffen wird meist das Falsche.

3. Ein Umzug dieser Größe war im Haus noch nie dran

  • Datenmigration, Berechtigungsmodell, Netzanbindung und Ausnahmen, die in keiner Anforderungsliste stehen.
  • Fehler an diesen Stellen zeigen sich erst im Regelbetrieb und sind dann teuer.

4. Jeder Bereich hat seine eigene Umgebung gebucht

  • Mehrere Konten, mehrere Anbieter, mehrere Zahlungswege — ohne gemeinsame Regeln.
  • Zusammenführen heißt zuerst: Inventar und Zuständigkeit klären, erst danach Technik.

5. Ein Nachweis wird verlangt

  • Aufsicht, Konzernmutter oder Großkunde fragen nach Speicherort, Zugriffswegen und Ausstiegsfähigkeit.
  • Der Nachweis lässt sich selten nachträglich erzeugen; er entsteht aus Architektur und Dokumentation.

6. Der Betrieb soll vom Projekt in die Linie übergehen

  • Die Umgebung steht, aber Bereitschaft, Änderungsprozess und Kostenverantwortung sind nicht geregelt.
  • Ohne diesen Schritt bleibt das Projektteam im Betrieb — dauerhaft und zu Projektkonditionen.

Erkennen Sie Ihre Ausgangslage in einem dieser Punkte wieder? Ein kurzes Telefonat sortiert die Lage: welche Anwendungen zuerst bewertet gehören, welche Welle den Anfang macht — und ob Sie dafür überhaupt jemanden von außen brauchen.

Arbeitsgebiete

Von der Cloud-Strategie bis zum Kostenregelkreis: die Arbeitsgebiete

Die Gebiete werden einzeln oder zusammen besetzt, je nachdem, wo ein Vorhaben steht. Meist beginnt es mit Bewertung und Zielbild; Architektur, Kostensteuerung und Betrieb folgen dort, wo die Reihenfolge es verlangt. Es ist ein Ausschnitt — über die Kategorieseite sind weitere Spezialisierungen erreichbar.

Cloud-Strategie und Zielbild

Welche Last gehört in eine öffentliche Cloud, welche in eine private Umgebung, welche bleibt im eigenen Rechenzentrum — beantwortet je Anwendung statt pauschal. Dazu gehören eine Anwendungsübersicht mit Abhängigkeiten und eine Reihenfolge, die auch bei gekürztem Budget noch trägt.

Migrationsplanung und Wellenschnitt

Der Schnitt entscheidet über den Verlauf: Welche Anwendungen wandern gemeinsam, weil sie sich Daten teilen, welche lassen sich trennen, wo liegt der Rückweg. Jede Welle bekommt Umfang, Abnahmekriterium und einen Abbruchpunkt — damit ein Problem eine Welle kostet und nicht das Programm.

Cloud-Architektur und Landing Zone

Die Grundordnung einer Umgebung, bevor die erste Anwendung einzieht: Kontenstruktur, Netzwerkschnitt, Identitäten und Rechte, Trennung von Test und Produktion, Protokollierung, Ablage und Wiederherstellung. Anbieterunabhängig aufgestellt: Wir vertreiben weder Lizenzen noch Betriebsleistungen.

Cloud-Kosten und FinOps

Verbrauch sichtbar machen, zuordnen und in eine Entscheidung überführen: Kennzeichnung von Ressourcen, Zuordnung zu Anwendungen und Teams, Erkennen ungenutzter Umgebungen und ein monatlicher Regelkreis mit benannter Verantwortung.

Betrieb, Automatisierung und Plattformteams

Wie eine Umgebung nach dem Umzug geführt wird: Infrastruktur als Code statt Klickwege, Überwachung und Bereitschaft, Änderungsprozess, wiederkehrende Bausteine für die Fachbereiche. Ziel ist ein Team, das Selbstbedienung ermöglicht, statt zur nächsten Warteschlange zu werden.

Cloud-Sicherheit und Souveränität

Zugriffsrechte, Verschlüsselung, Protokollierung und Schlüsselverwaltung werden im Vorhaben mitentschieden, ebenso Speicherort, Zugriffswege und Ausstiegsfähigkeit. Wir reißen das an; die Tiefe steht in der Cyber Security Beratung.

Welches dieser Gebiete bei Ihnen zuerst greifen muss, lässt sich in einem kurzen Gespräch einordnen. Schildern Sie die Ausgangslage — Sie bekommen eine Einschätzung, keine Präsentation.

Beauftragungsformen

Vier Formen, in denen Cloud-Beratung beauftragt wird

Über das Ergebnis entscheidet oft nicht die fachliche Tiefe, sondern die Form: wie viel Kapazität, mit welchem Mandat, über welchen Zeitraum. Vier Formen deckt unser Netzwerk ab, ein Wechsel im Verlauf ist der Normalfall. Für alle vier gilt dasselbe Gerüst: eine benannte interne Verantwortung, schriftliche Ziele vor dem Start und ein zu Beginn vereinbarter Übergabepunkt.

Bestandsaufnahme
Anwendungslandschaft bewerten

Eine erfahrene Person nimmt Anwendungen, Abhängigkeiten, Datenpfade und heutige Betriebskosten auf und liefert eine begründete Empfehlung je Anwendung. Sinnvoll, wenn intern gearbeitet wird und nur die Vergleichserfahrung fehlt.

Architekturmandat
Zielarchitektur verantworten

Eine Person verantwortet die Grundordnung der Umgebung und die Regeln, nach denen später gebaut wird. Üblich, bevor die erste produktive Anwendung einzieht, und immer dann, wenn mehrere Teams parallel bauen sollen.

Umsetzungsbegleitung
Wellen mitfahren

Externe Fachleute arbeiten in einem Team mit Ihren Leuten, unter interner fachlicher Führung. Das gängigste Modell bei Standortablösungen. Was dabei gelernt wird, bleibt im Haus, weil es dort erarbeitet wird.

Kostensteuerung
Verbrauch dauerhaft steuern

Eine kleine, wiederkehrende Beteiligung nach dem Umzug: monatlicher Blick auf Verbrauch und Abrechnungsmodelle, Aufräumen ungenutzter Umgebungen. Diese Form wird am häufigsten zu spät beauftragt.

Branchenpraxis

Cloud nach Branche: was die Verlagerung begrenzt

Der Weg in die Cloud folgt überall derselben Mechanik, die Grenzen liegen aber an verschiedenen Stellen. In der Fertigung begrenzt die Anlagenanbindung, wie viel verlagert werden kann; im Handel bestimmt das Saisongeschäft, wann ein Umzug nicht stattfinden darf; bei Banken und Versicherungen setzt das Aufsichtsrecht die Bedingungen für Auslagerung und Ausstieg; in der Verwaltung entscheiden Beschaffungswege und der Speicherort. Wer diese Eigenheiten erst während der Umsetzung kennenlernt, zahlt dafür in Wochen.

Deshalb wählen wir nach gelebter Branchenpraxis aus und nicht danach, wer gerade frei ist: nach Fachleuten, die die üblichen Systemlandschaften, Prüfroutinen und Stellen kennen, an denen vergleichbare Vorhaben stockten. Dahinter steht ein Netzwerk mit 25 Fachbereichen und über 300 Rollenprofilen. In den folgenden Branchen arbeiten wir regelmäßig — jede Kachel nennt, was dort den Ausschlag gibt und woran der Fortschritt sichtbar wird.

Fertigungs- und IT-Fachleute überwachen Produktionsdaten an mehreren Bildschirmen

Industrie & Maschinenbau

Mitarbeiterin prüft Bestandsdaten im Filialbetrieb an einem mobilen Gerät

Handel & E-Commerce

Fachleute aus Finanzdienstleistung und Aufsichtsrecht prüfen Auslagerungsunterlagen

Banken & Versicherungen

Klinisches IT-Team bespricht die Anbindung von Fachsystemen im Krankenhaus

Gesundheitswesen

IT-Verantwortliche der öffentlichen Hand besprechen Anforderungen an den Speicherort

Öffentliche Verwaltung

Techniker prüft Anlagen eines Energieversorgers im Feld

Energie & Versorger

Fertigungs- und IT-Fachleute überwachen Produktionsdaten an mehreren Bildschirmen

Industrie & Maschinenbau

Mitarbeiterin prüft Bestandsdaten im Filialbetrieb an einem mobilen Gerät

Handel & E-Commerce

Fachleute aus Finanzdienstleistung und Aufsichtsrecht prüfen Auslagerungsunterlagen

Banken & Versicherungen

Klinisches IT-Team bespricht die Anbindung von Fachsystemen im Krankenhaus

Gesundheitswesen

IT-Verantwortliche der öffentlichen Hand besprechen Anforderungen an den Speicherort

Öffentliche Verwaltung

Techniker prüft Anlagen eines Energieversorgers im Feld

Energie & Versorger

Vorhabenstypen

Cloud-Vorhaben, die regelmäßig beauftragt werden — und ihre Zielzahl

Was in Cloud-Programmen tatsächlich beauftragt wird, fällt größtenteils in vier Typen. Jeder hat eine typische Ausgangslage, eine Reihenfolge, die sich bewährt hat, und eine Zahl, die vor dem Start vereinbart und während der Laufzeit gemessen wird — nicht am Ende geschätzt.

Rechenzentrum ablösen

Ausgangslage: eigene Hardware am Ende ihres Lebenszyklus oder ein auslaufender Standortvertrag, dazu ein fester Termin. Bewährt hat sich: erst bewerten und einen Teil bewusst abschalten, dann Wellen schneiden, dann verlagern — je Welle mit Rückweg. Zielzahl ist die Zahl der Anwendungen, die zum Stichtag den Standort verlassen haben.

Kosten nach dem Umzug in den Griff bekommen

Ausgangslage: Die Umgebung läuft, die Rechnung wächst, niemand kann sie einer Entscheidung zuordnen. Der Weg führt über Kennzeichnung und Zuordnung, dann über das Abschalten des Ungenutzten, erst danach über Abrechnungsmodelle. Zielzahl sind die Kosten je Anwendung oder je Vorgang, nicht die Gesamtsumme.

Grundordnung nachträglich einziehen

Ausgangslage: über Jahre entstandene Konten und Umgebungen ohne gemeinsame Regeln, oft bei mehreren Anbietern. Zuerst inventarisieren und Verantwortung zuordnen, dann eine Zielstruktur beschreiben, dann schrittweise umziehen. Zielzahl ist der Anteil der Umgebungen, der den Regeln für Netzwerk, Rechte und Protokollierung entspricht.

Betriebsmodell und Übergabe in die Linie

Ausgangslage: Das Projekt endet, der Betrieb ist nicht geregelt — Bereitschaft, Änderungsprozess, Kostenverantwortung, Bereitstellung neuer Umgebungen. Zuerst Rollen und Freigaben beschreiben, dann Wiederkehrendes automatisieren, dann übergeben. Zielzahl ist der Anteil der Anforderungen, den die Fachbereiche selbst erfüllen können.

Besetzung

Welche Cloud- und Plattformprofile in der Praxis gebraucht werden

Die Form eines Vorhabens bestimmt die Besetzung — eine Bewertung der Anwendungslandschaft verlangt ein anderes Profil als eine Rechenzentrumsablösung, und mit dem Übergang von der Planung in den Betrieb verschiebt sich der Bedarf erneut. Die folgenden Profile werden in Cloud-Vorhaben am häufigsten angefragt; sie sind ein Ausschnitt, über die Kategorieseite kommen zahlreiche weitere Rollen aus Cloud, Infrastruktur und DevOps hinzu. Welche Aufgaben eine Rolle übernimmt und in welcher Bandbreite ihr Tagessatz liegt, steht offen auf der jeweiligen Rollenseite.

Wie ein Cloud-Umzug in Wellen geplant und gefahren wird

Umfang und Dauer der Schritte hängen von Größe und Landschaft ab, die Abfolge nicht: erst aufnehmen, dann entscheiden, dann eine Grundordnung bauen, dann in Wellen verlagern und zuletzt übergeben. Kein Schritt entfällt; verkürzt wird einer nur dann, wenn dafür belastbare Vorarbeit vorliegt.

Schritt 1: Aufnahme der Anwendungslandschaft vor dem Cloud-Umzug

1. Anwendungen aufnehmen

Anwendungen, Abhängigkeiten, Datenpfade, Lizenzbindungen und heutige Betriebskosten werden erfasst — anhand dessen, was läuft, nicht anhand der Dokumentation.
Gespräche mit Fachbereich und Betrieb machen die Ausnahmen sichtbar, die in keiner Systemliste stehen.
Ergebnis ist eine begründete Empfehlung je Anwendung: verlagern, umbauen, ablösen oder bewusst stehen lassen.
Schritt 2: Zielbild und Reihenfolge der Cloud-Verlagerung werden festgelegt

2. Zielbild und Reihenfolge festlegen

Je Anwendung wird entschieden, wohin sie gehört und wie eng sie sich an die Dienste eines Anbieters binden darf.
Die Reihenfolge folgt Abhängigkeiten und Risiko, nicht der Sichtbarkeit; zurückgestellte Anwendungen werden benannt.
Am Ende steht ein Schnitt in Wellen, von denen jede für sich Nutzen liefert und für sich abgebrochen werden kann.
Schritt 3: Aufbau der Grundordnung einer Cloud-Umgebung

3. Grundordnung aufbauen

Kontenstruktur, Netzwerkschnitt, Identitäten und Rechte, Trennung von Test und Produktion, Protokollierung und Ablage werden eingerichtet.
Die Regeln werden als Code beschrieben, damit sie überprüfbar sind und sich wiederherstellen lassen.
Erst danach zieht die erste produktive Anwendung ein — Nachrüsten ist an dieser Stelle die teuerste Variante.
Schritt 4: Pilotwelle der Cloud-Migration wird durchgeführt

4. Pilotwelle fahren

Eine überschaubare, aber echte Anwendung wandert zuerst — mit Datenmigration, Abnahme durch den Fachbereich und geprobtem Rückweg.
Die Pilotwelle liefert die belastbaren Werte für Aufwand, Dauer und laufende Kosten der übrigen Wellen.
Was hier nicht funktioniert, wird korrigiert, bevor es sich über alle weiteren Wellen vervielfältigt.
Schritt 5: Weitere Migrationswellen laufen, der Betrieb wird aufgebaut

5. Wellen abarbeiten und betreiben

Die folgenden Wellen laufen nach demselben Muster; parallel wird der Betrieb aufgebaut statt nachgelagert.
Ihre eigenen Leute fahren die Wellen mit, damit das Wissen an der Stelle entsteht, an der später betrieben wird.
Eine Welle gilt erst als fertig, wenn die alte Umgebung aus ist und nichts mehr auf sie zeigt.
Schritt 6: Kostenregelkreis wird eingerichtet und der Betrieb übergeben

6. Kostenregelkreis und Übergabe

Verbrauch wird Anwendungen und Teams zugeordnet, Abrechnungsmodelle werden verglichen und monatlich überprüft.
Wenige messbare Größen stehen von Beginn an fest: Kosten je Anwendung, Bereitstellungsdauer, Anteil regelkonformer Umgebungen.
Der Übergabepunkt ist zu Beginn vereinbart: Am Ende führt die Organisation die Umgebung ohne externe Unterstützung weiter.
Kostenrahmen

Was Cloud-Beratung kostet — und wie sich Cloud-Kosten planen lassen

Beim Budget eines Cloud-Vorhabens werden zwei Größen leicht verwechselt: das Honorar für externe Unterstützung und die laufenden Kosten der Umgebung selbst. Nur die erste lässt sich hier beziffern. Abgerechnet wird über unser Netzwerk nach Tagessatz, ohne Projektpauschale und ohne erfolgsabhängige Bestandteile.

Was den Satz bewegt. An erster Stelle die Seniorität und die Entscheidungsnähe der Rolle: Wer eine Zielarchitektur verantwortet oder ein Programm gegenüber der Geschäftsführung vertritt, liegt über einer Rolle, die zuliefert. Danach die Plattformerfahrung — Profile, die eine Ablösung dieser Größenordnung bereits zweimal begleitet haben, sind knapp, und Knappheit wirkt stärker als jeder andere Faktor. Dann die Branche: Umgebungen mit Nachweispflichten verlangen Zusatzerfahrung, die den Kreis verengt. Der Remote-Anteil schlägt in beide Richtungen aus — Architektur-, Automatisierungs- und Kostenarbeit läuft weitgehend ortsunabhängig und öffnet den Kandidatenkreis über die eigene Region hinaus, während Standort- und Rechenzentrumsarbeit Anwesenheit verlangt. Zuletzt die Projektdauer: Ein Einsatz über zwölf Monate liegt pro Tag unter einem Vier-Wochen-Einsatz mit demselben Einarbeitungsaufwand.

Die Bandbreiten aus unserem eigenen Rollenbestand, offen ausgewiesen auf den jeweiligen Seiten. Für Betrieb und Plattformarbeit 700 bis 1.300 € pro Tag (Cloud Operations Manager, Platform Engineer, DevOps Engineer, Site Reliability Engineer). Für Verlagerung und Standortablösung 750 bis 1.400 € (Datacenter Migration Specialist, Cloud Migration Consultant). Für die Kostensteuerung 800 bis 1.200 € (Cloud FinOps Consultant). Für Architektur und Grundordnung 800 bis 1.500 € (Infrastructure Architect, Hybrid Cloud Architect, Cloud Architect, Multi-Cloud Architect). Für Cloud-Sicherheit 900 bis 1.400 € (Cloud Security Architect). Alle Angaben sind Bandbreiten und keine Festpreise; der Satz eines konkreten Einsatzes wird vor der Beauftragung vereinbart.

Abschnittsweise freigeben statt als Gesamtsumme. Bewährt hat sich eine Budgetierung in vier Stufen, die jeweils mit einer Entscheidung enden, die auch „nicht weiter“ lauten darf: die Bewertung der Anwendungslandschaft mit einer begründeten Empfehlung je Anwendung, die Pilotwelle mit belastbaren Werten für Aufwand und laufende Kosten, die weiteren Wellen mit einer Abnahme je Welle und schließlich der Betrieb mit einem monatlichen Kostenregelkreis. Wer alles in einem Betrag freigibt, verliert die Punkte, an denen ein Kurswechsel noch günstig wäre.

Der Unterschied zur Beauftragung eines Systemhauses oder Plattformpartners liegt weniger im Preis als darin, was Sie einkaufen. Dort erhalten Sie ein Team samt Methodik und Werkzeugen, oft verbunden mit dem Vertrieb bestimmter Produkte oder Lizenzen; hier besetzen Sie eine Rolle in Ihrer eigenen Linie, ohne Lizenzinteresse und ohne Partnerprovision. Das verlangt fachliche Führung im Haus und hat zur Folge, dass die Erfahrung dort bleibt, wo die Umgebung später betrieben wird. Nicht enthalten sind in jedem Fall die laufenden Kosten der Plattform selbst — Verbrauch, Lizenzen, Datenübertragung und Betrieb hängen an Ihrer Architektur und Ihrem Nutzungsverhalten, nicht an der Besetzung.

Die Besetzung richtet sich nach der Form des Vorhabens: Eine Bewertung der Anwendungslandschaft verlangt ein anderes Profil als eine Standortablösung. Die vollständige Übersicht steht unter Cloud, Infrastruktur & DevOps — darunter Cloud Architects, Cloud Migration Consultants und FinOps Consultants. Für den Betrieb nach dem Umzug ergänzen IT Service Management, für Datenplattformen auf der neuen Umgebung Data Engineering & Data Science und für Modellbetrieb darauf die KI-Beratung.

Warum jetzt

Der Kostenblock der Cloud wächst schneller als die Fähigkeit, ihn zu steuern

90 %

der Unternehmen in Deutschland nutzen Cloud-Anwendungen — ein Jahr zuvor waren es 81 %.
Bitkom Cloud Report 2025

53 %

der Cloud-nutzenden Unternehmen sehen sich ihren Anbietern bei Preisen und Vertragsgestaltung ausgeliefert.
Bitkom Cloud Report 2025

52,7 %

der Unternehmen in der EU bezogen 2025 kostenpflichtige Cloud-Dienste; 2023 waren es 45,3 %.
Eurostat
Fragen zur Cloud-Beratung

Häufig gestellte Fragen zur Cloud-Beratung

Cloud-Beratung — auch Cloud Consulting genannt — klärt, welche Teile einer Anwendungslandschaft in einer Cloud-Umgebung besser aufgehoben sind, in welcher Reihenfolge sie dorthin gelangen und wie die Umgebung danach geführt wird. Dazu gehören die Bewertung der vorhandenen Anwendungen, die Grundordnung der neuen Umgebung mit Regeln für Netzwerk, Identitäten und Datenhaltung, der Schnitt der Migrationswellen sowie die laufende Kostensteuerung. Anbieterunabhängig ist sie dann, wenn sie nicht am Verkauf von Lizenzen oder Betriebsleistungen verdient.
Eine Cloud-Migration ist die Verlagerung von Anwendungen und Daten aus dem eigenen Rechenzentrum in eine Cloud-Umgebung. Sie läuft in Wellen: Zuerst wird die Anwendungslandschaft aufgenommen und je Anwendung entschieden, ob sie unverändert wandert, vorher umgebaut, abgelöst oder bewusst stehen gelassen wird. Danach entsteht die Grundordnung der Zielumgebung, es folgt eine Pilotwelle mit echter Anwendung und geprobtem Rückweg, dann die weiteren Wellen. Eine Welle gilt erst als abgeschlossen, wenn die alte Umgebung abgeschaltet ist.
Wenn ein fester Termin die Entscheidung erzwingt — auslaufende Hardware, endender Standortvertrag, angekündigtes Supportende. Wenn eine Verlagerung dieser Größe im Haus noch nie gemacht wurde. Wenn die Rechnung einer laufenden Umgebung sich niemandem mehr zuordnen lässt. Oder wenn ein Nachweis über Speicherort, Zugriffswege und Ausstiegsfähigkeit verlangt wird. Ist die Landschaft überschaubar und sind Erfahrung wie Kapazität im Haus, kostet externe Unterstützung vor allem Abstimmung.
Selten an der Technik. Häufiger daran, dass eine gewachsene Landschaft unverändert verlagert wird und ihre Fehlauslastung mitnimmt, die nun monatlich abgerechnet wird. Oder daran, dass niemand benannt ist, der eine Umgebung abschalten darf — dann wird keine abgeschaltet. Weitere wiederkehrende Ursachen: eine Grundordnung, die erst nachträglich eingezogen wird, und eine fehlende Übergabe vom Projekt in den Betrieb.
Die Frage lässt sich nicht für ein Unternehmen als Ganzes beantworten, sondern nur je Anwendung. Entscheidend sind Lastprofil, Datenkategorie, Abhängigkeiten zu Nachbarsystemen, vorhandenes Betriebswissen und die Frage, wie eng eine Bindung an einen Anbieter tragbar ist. Daraus ergibt sich für die eine Anwendung eine öffentliche Cloud, für die andere eine private Umgebung, für die dritte der Verbleib im eigenen Rechenzentrum. Diese Bewertung gehört vor die Plattformentscheidung, nicht danach.
Sicherheit in der Cloud ist geteilte Verantwortung: Der Anbieter sichert die Plattform, das Unternehmen die eigene Konfiguration — Rechte, Verschlüsselung, Schlüsselverwaltung, Protokollierung, Netzwerkschnitt. Die meisten Vorfälle entstehen in dieser zweiten Hälfte. Souveränität meint die Frage, wo Daten liegen, wer auf sie zugreifen kann und wie sie eine Umgebung wieder verlassen. Beides gehört in die Architektur; die rechtliche Bewertung einzelner Datenkategorien bleibt eine Einzelfallprüfung. Der Tiefgang zu Schutzmaßnahmen steht in unserer Cyber Security Beratung.
Die Bandbreiten auf unseren Rollenseiten reichen von 700 € für Rollen im laufenden Betrieb bis 1.500 € für Architektur- und Programmverantwortung. Wo ein Profil darin liegt, entscheiden Seniorität, Plattformerfahrung, Branche, Remote-Anteil und Projektdauer. Eine belastbare Zahl ergibt sich erst aus dem Zuschnitt. Dieselbe Aufgabe kann als Zulieferung oder als mitverantwortliche Position geschnitten sein, und der Unterschied bewegt sich im dreistelligen Bereich je Tag. Welche Bandbreite für welche Rolle gilt, steht offen auf der Rollenseite.
Der Aufwand hängt an der Zahl der Anwendungen, ihren Abhängigkeiten und daran, wie viel vorher umgebaut wird — belastbar wird er erst mit der Pilotwelle, die genau dafür da ist. Neben dem Honorar fallen drei Blöcke an, die in frühen Rechnungen regelmäßig fehlen: die laufenden Kosten der Zielumgebung, die nach dem Projekt bleiben und mit der Nutzung schwanken; interne Aufwände für Fachbereiche, Test und Abnahme; sowie der Parallelbetrieb während der Wellen, in dem beide Seiten gleichzeitig bezahlt werden. Für die Planung zählt daher weniger eine Gesamtsumme als die Frage, wann die alte Umgebung wirklich abgeschaltet wird.
Sie können sich auf uns verlassen

Ausgezeichnet. Finden nicht nur wir selbst.

consultingheads wurde mehrfach von führenden Fachmagazinen und unabhängigen Dritten ausgezeichnet.

Siegel_FAZ TOP-Berater
consultingheads-brand-eins-beste-berater-2025-1
consultingheads-award-top-company-2025-kununu
consultingheads-kununu-top-company-2024 (1)
consultingheads-brand-eins-beste-berater-2024-3
consultingheads-kununu-top-company-2023
consultingheads-brand-eins-beste-berater-2021
consultingheads-brand-eins-beste-berater-2020
consultingheads-brand-eins-beste-berater-2019-1
BrandEins_Berater2026_Logo_DE_basic
Siegel_FAZ TOP-Berater
consultingheads-brand-eins-beste-berater-2025-1
consultingheads-award-top-company-2025-kununu
consultingheads-kununu-top-company-2024 (1)
consultingheads-brand-eins-beste-berater-2024-3
consultingheads-kununu-top-company-2023
consultingheads-brand-eins-beste-berater-2021
consultingheads-brand-eins-beste-berater-2020
consultingheads-brand-eins-beste-berater-2019-1
BrandEins_Berater2026_Logo_DE_basic
bildmarke
brand eins Beste Unternehmensberater 2026 — consultingheads
Nächster Schritt

Sprechen wir über Ihren Weg in die Cloud.

Einordnung Ihrer Anwendungslandschaft in zwanzig Minuten
Eine konkrete nächste Maßnahme statt Präsentationen
Kostenfrei und ohne Verkaufsdruck
Ein kurzes Gespräch, in dem wir Ihre Anwendungslandschaft grob sortieren und benennen, welche Welle den Anfang macht — und ob wir dafür die passenden Leute im Netzwerk haben.