Azure ist bei euch im Haus angekommen — vielleicht durch eine halbfertige Migration, vielleicht über einen Test, der „erstmal so blieb”, vielleicht weil ein Dienstleister vor zwei Jahren „alles in die Cloud” versprochen hat. Das Ergebnis sieht oft ähnlich aus: ein Teil der Workloads läuft in Azure, ein Teil lokal, die monatliche Rechnung kommt zuverlässig, und niemand kann auf Anhieb sagen, warum sie genau so hoch ist. Wir bauen einen sauberen Azure-Hybrid-Betrieb für mittelständische Firmen — mit dem ehrlichen Grundsatz, dass nicht jeder Workload in die Cloud gehört.

Erkennst du das?

Die Azure-Rechnung kommt jeden Monat — und niemand kann genau sagen, wofür das Geld ausgegeben wird. Auf Nachfrage heißt es „das sind die VMs und der Storage”, aber welche VMs noch laufen müssen, weiß keiner mehr ganz sicher.
Ihr habt vor zwei Jahren mit „alles in die Cloud” begonnen — die Hälfte ist da, die andere Hälfte hängt zwischen lokal und Azure, und gefühlt läuft nichts wirklich rund. Die Migration steht bei 30 % und bewegt sich seit Monaten nicht mehr.
Backups laufen — aber niemand hat in den letzten 12 Monaten einen Restore wirklich getestet. Auf die Frage „Was würde passieren, wenn morgen früh der Hauptserver weg ist?” gibt es nur ungemütliches Schweigen.
Eure Konstruktion klagt über lahme CAD-Performance, seit Teile der Projektdaten in SharePoint oder in einer Azure-Files-Freigabe liegen. Was vorher in zwei Sekunden offen war, dauert jetzt zehn.
Der Cyber-Versicherer hat einen Fragebogen geschickt mit konkreten Punkten zu Off-Site-Backups, Immutability und Restore-Drills — und ihr seid euch nicht sicher, wie ihr ehrlich antworten könnt.

Warum das passiert

Azure und „die Cloud” wurden in den letzten Jahren als universelle Antwort verkauft. Auf jeder Konferenz, in jedem Sales-Pitch, in jeder Beratungs-PowerPoint. Mittelständische Firmen, die in genau dieser Phase eine Modernisierung anpacken mussten — weil ein Server alt wurde, weil ein Standort dazu kam, weil Corona-Homeoffice plötzlich Realität war — haben das oft pauschal übernommen. „Lift and Shift in die Cloud” war der Plan, mit der Annahme, alles würde danach billiger, einfacher, sicherer.

In der Praxis stellt sich heraus: Nicht jeder Workload profitiert von Azure. Ein ERP-System, das jahrelang auf einer lokalen Maschine läuft, mit Latenz im einstelligen Millisekunden-Bereich zur Datenbank, wird in der Cloud nicht schneller — höchstens langsamer und teurer. CAD-Workstations, die mit großen Konstruktionsdateien arbeiten, brauchen lokalen Storage in Gigabit-Geschwindigkeit, nicht eine SMB-Freigabe über VPN. Maschinensteuerungen und SPS-Welten haben in der Cloud schlicht nichts verloren.

Dazu kommt: Azure ist eine Plattform mit hunderten von Diensten, und jeder Dienst kostet anders. Eine VM, die in der falschen Größe und im falschen Reservierungsmodell läuft, kann das Drei- oder Vierfache dessen kosten, was sie kosten müsste. Ein Storage-Account mit falscher Redundanz-Stufe verbrennt Geld für eine Verfügbarkeit, die niemand braucht. Ohne eine konsequente Cost-Governance wird Azure zum Abo, das man bezahlt, ohne es zu verstehen.

Und schließlich: Wer eine Migration auf halbem Weg abbricht — weil die Komplexität größer wurde als gedacht, weil das Budget aufgebraucht ist, weil der externe Dienstleister gewechselt hat — bleibt mit einem hybriden Setup zurück, das niemand sauber entworfen hat. Halb-lokal, halb-Azure, Identitäten an zwei Stellen, Backup an drei Stellen, und keiner hat die Gesamtsicht. Genau hier setzen wir an.

Worum es konkret geht

Azure Landing Zone — saubere Cloud-Basis

Bevor irgendetwas in Azure produktiv wird, braucht es ein Fundament: eine Subscription-Struktur, die zu eurem Unternehmen passt (Prod, Dev, Test, ggf. Sandbox), ein Naming-Schema für Ressourcen, ein Tagging-Konzept für Kostenstellen und Verantwortlichkeiten, eine klare Trennung von Identitäten und Berechtigungen. Wir bauen die Landing Zone als Infrastructure-as-Code (Bicep oder Terraform), damit jeder spätere Schritt nachvollziehbar und reproduzierbar ist. Woran ihr merkt, dass es fehlt: Wenn Ressourcen im Azure-Portal heißen wie „vm-test-2”, „vm-test-2-neu” und „vm-test-2-final”.

Hybrid-Anbindung — Identitäten und Netzwerk

Die Brücke zwischen eurem lokalen Standort und Azure. Auf der Netzwerk-Seite meistens ein Site-to-Site-VPN über die vorhandene Firewall — in den meisten Fällen ist das vollkommen ausreichend. ExpressRoute ist die teurere Variante mit dedizierter Leitung, die wir nur dann empfehlen, wenn Latenz, Bandbreite oder Compliance es wirklich erfordern. Auf der Identitäten-Seite Entra Connect, damit eure Mitarbeitenden sich überall mit demselben Konto anmelden. Optional Azure Virtual Desktop, wenn ihr Arbeitsplätze braucht, die wirklich von überall aus erreichbar sein sollen — aber auch das nur, wenn es zum Anwendungsfall passt, nicht als Selbstzweck. Woran ihr merkt, dass es fehlt: Wenn Mitarbeitende sich an einem lokalen Konto und an einem Cloud-Konto separat anmelden müssen, mit zwei Passwörtern.

Backup & Disaster Recovery — Restore getestet, nicht „läuft”

Der Punkt, an dem viele Firmen am verletzlichsten sind. Wir bauen Backups nach dem Grundsatz, dass sie off-platform, immutable und getestet sein müssen. Off-platform heißt: Die Sicherung liegt nicht im selben Account und nicht in derselben Region wie die Quelldaten — sonst nimmt euch ein einziger Vorfall (kompromittierter Admin-Account, Ransomware) beides gleichzeitig. Immutable heißt: Sobald die Sicherung geschrieben ist, kann sie auch ein Angreifer mit Admin-Rechten nicht löschen oder verschlüsseln. Und „getestet” heißt: Mindestens einmal pro Jahr wird ein realistischer Restore durchgespielt — nicht auf dem Produktivsystem, aber mit echtem Zeit-Stoppuhr-Protokoll. Woran ihr merkt, dass es fehlt: Wenn die Antwort auf „Wann habt ihr zuletzt einen Restore getestet?” länger als sechs Sekunden braucht.

Monitoring & Cost-Governance — Transparenz, was Azure tut

Was hat Azure gestern gekostet, warum, und was hat sich gegenüber der Vorwoche verändert? Das ist die Frage, die in einem sauberen Cloud-Betrieb jederzeit beantwortbar sein muss. Wir richten Azure Monitor, Log Analytics und Cost Management so ein, dass Kostentreiber sichtbar werden, Budgets pro Subscription oder Tag ein Alarm auslösen, wenn sie überschritten werden, und ungenutzte Ressourcen (VMs, die nie hochgefahren werden, Disks, die nie attached sind, Public IPs, die nichts tun) regelmäßig identifiziert und entfernt werden. Woran ihr merkt, dass es fehlt: Wenn die Geschäftsführung beim Blick auf die Azure-Rechnung jeden Monat ähnlich überrascht ist wie im Monat davor.

Wann lokal besser bleibt — die ehrliche Antwort

Das hier ist der Teil, den ihr in den meisten Sales-Pitches nicht hört. Cloud ist nicht automatisch besser, nicht automatisch günstiger und nicht für jeden Workload sinnvoll. Wir empfehlen explizit gegen die Cloud, wenn:

Euer ERP lokal stabil läuft. ProAlpha, Microsoft Dynamics NAV/BC on-prem, ams.erp, Sage — wenn die Anwendung seit Jahren auf einer lokalen Maschine läuft, die Datenbank im Nebenraum steht und die Latenz unter einer Millisekunde liegt, dann ist eine Cloud-Migration kein Fortschritt, sondern eine Risiko-Operation. Lasst es lokal.
CAD-Workstations und Lizenzserver. Konstruktionsabteilungen arbeiten mit großen Dateien, häufigen Speichervorgängen und Anwendungen, die auf lokale Performance angewiesen sind. Lizenzserver für CAD-Software (FlexLM, Sentinel) gehören neben die Workstations, nicht in die Cloud.
SPS, MES, Maschinensteuerung. Die Produktions-Welt hat eigene Echtzeit-Anforderungen, eigene Netzwerke, oft eigene Wartungszyklen. Was da läuft, bleibt vor Ort. Eine Cloud-Anbindung kann sinnvoll sein für Auswertungen und Reporting — die Steuerung selbst gehört nicht dorthin.
File-Server für die Konstruktion. Wenn eure Konstruktion mit großen 3D-Modellen, Baugruppen und Zeichnungsverwaltung arbeitet, ist ein lokaler File-Server mit ordentlicher Backup-Strategie oft die bessere Antwort als SharePoint oder eine Azure-Files-Freigabe. Wir haben mehr als einmal gesehen, dass eine SharePoint-Migration die Konstruktion ausgebremst hat.
Backup-Wiederherstellung muss auch ohne Internet möglich sein. Wenn euer Provider eine Stunde ausfällt — und das passiert — darf der Restore eines kritischen Servers davon nicht abhängig sein. Eine lokale Kopie auf einem separaten Medium ist Teil einer ehrlichen Backup-Strategie.

Klare Aussage: Wenn euer ProAlpha auf der lokalen Maschine seit fünf Jahren stabil läuft, lasst es da. Eine Cloud-Migration ist kein Selbstzweck — und nicht jeder Workload gehört in Azure. Wir empfehlen, was zu eurem Geschäft passt, nicht was den höchsten Beratungsumsatz erzeugt.

Worauf du achten solltest — auch wenn du nicht uns nimmst

Lass dir vor Projektstart eine Landing-Zone-Vorlage zeigen, nicht erst danach. Wer keine standardisierte Basis hat, baut bei euch eine Custom-Lösung, die nur er selbst versteht — und ihr seid in zwei Jahren genau dort, wo ihr heute nicht mehr sein wollt.
Frag nach dem Restore-Drill, nicht nach dem Backup. Jeder Dienstleister wird euch versichern, dass „Backup läuft”. Die einzig relevante Frage ist: „Wann habt ihr zuletzt einen Restore gemacht, und wie lange hat er gedauert?” Wer darauf keine konkrete Antwort hat, hat kein erprobtes Backup.
Pauschal-Cloud-Verträge der Marke „Azure Managed Service für x € pro Monat” decken meistens nur Monitoring und Patching ab. Keine Kosten-Optimierung, keine Architektur-Anpassung, keine Beratung gegen die Cloud. Das ist nicht schlecht — es ist nur etwas anderes als das, was die meisten Firmen wirklich brauchen.
Wenn jemand ExpressRoute empfiehlt, ohne eure Workload-Latenz und Bandbreiten-Bedarfe gemessen zu haben — Vorsicht. ExpressRoute ist teuer und nur für sehr spezifische Anforderungen nötig. Für die meisten Mittelständler reicht ein gut konfiguriertes Site-to-Site-VPN.
Frag, ob der Dienstleister euch auch von einer Migration abrät. Wer Azure als einzige Antwort kennt, verkauft euch Azure. Wer mehr als eine Antwort kennt, kann beraten.
Klärt, wer die Global-Admin-Rechte auf eurer Azure-Tenancy hält. Wenn die nur beim Dienstleister liegen, habt ihr ein Klumpenrisiko. Die müssen bei euch im Haus liegen, mit MFA, mit separater Notfall-Identität.
Frag nach Infrastructure-as-Code. Wenn jemand eure Azure-Umgebung im Portal zusammenklickt, ist sie nicht reproduzierbar. Bicep oder Terraform sind keine Engineering-Spielerei — sie sind die Voraussetzung für nachvollziehbaren Betrieb.

Wann das jetzt dran ist

Eine begonnene Cloud-Migration steht seit Monaten — irgendwann zwischen 2023 und 2024 wurde gestartet, 30 bis 50 Prozent sind drüben, und der Rest steht. Niemand traut sich, den nächsten Schritt zu planen, weil keiner mehr den Überblick hat.
Der Cyber-Versicherer stellt Fragen nach Off-Site-Backups, Immutability, Restore-Tests — und ihr braucht in den nächsten Wochen oder Monaten belastbare Antworten.
NIS-2-Vorbereitung steht an, entweder direkt betroffen oder als Zulieferer, und Backup- sowie Recovery-Prozesse müssen nachweisbar sein.
Die monatliche Azure-Rechnung steigt ohne erkennbaren Grund. Letztes Jahr war sie noch im erwarteten Rahmen, dieses Jahr deutlich darüber, und keiner kann sagen, was die Treiber sind.
Generationenwechsel im IT-Team — die Person, die das hybride Setup über Jahre im Kopf hatte, geht in Ruhestand oder wechselt das Unternehmen, und nichts davon ist dokumentiert.
ERP-Renewal steht an, und die Frage „lokal weiterbetreiben oder in die Cloud?” muss beantwortet werden — am besten mit einer ehrlichen Bewertung beider Optionen, nicht mit einem Reflex.
Der Maschinenpark wird erweitert, neue Standorte oder neue Anlagen kommen dazu, und die Frage nach Anbindung, Latenz und Datenfluss zwischen Produktion und Cloud wird zum Thema.
Ein Sicherheitsvorfall oder ein „Beinahe-Vorfall” hat gezeigt, dass die Backup-Strategie nicht hält, was sie verspricht.

Wie wir vorgehen

Phase 1 — Erstgespräch & Bestandsaufnahme

Wir starten mit einem 30-Minuten-Erstgespräch, danach mit einem strukturierten Blick auf eure aktuelle Cloud- und Hybrid-Landschaft. Welche Subscriptions, welche Ressourcen, welche Identitäten, welche Netzwerk-Anbindung, welcher Backup-Stand. Liefer-Ergebnis: eine ehrliche Bestandsaufnahme als kompaktes Dokument, das auch die Geschäftsführung versteht — was gut ist, was schief liegt, was dringend ist, was Zeit hat, und vor allem: welche Workloads aus unserer Sicht in Azure gut aufgehoben sind und welche lokal bleiben sollten.

Phase 2 — Zielbild & Architektur-Plan

Auf Basis der Bestandsaufnahme entwerfen wir mit euch zusammen das Zielbild. Welche Workloads gehen (oder bleiben) wohin, wie sieht die Landing Zone aus, wie die Netzwerk-Anbindung, wie die Identitäten-Synchronisation, wie das Backup-Konzept. Liefer-Ergebnis: ein Architektur-Plan mit nachvollziehbarer Begründung pro Entscheidung, einer klaren Umsetzungs-Reihenfolge und einer realistischen Kosten-Indikation (qualitativ — Kostenangaben für Azure-Ressourcen aus dem Microsoft-Pricing-Calculator, nicht Pauschalpreise von uns).

Phase 3 — Umsetzung in kontrollierten Schritten

Wir setzen die Änderungen schrittweise um. Erst die Landing Zone als Infrastructure-as-Code, dann die Netzwerk-Anbindung, dann pro Workload einzeln: testen, validieren, umstellen, Rollback-Pfad bereithalten. Keine Big-Bang-Migration. Backups werden parallel zum bestehenden System aufgebaut und mit einem echten Restore-Drill abgenommen, bevor wir den alten Backup-Stand außer Betrieb nehmen. Liefer-Ergebnis: Schritt für Schritt ein Hybrid-Betrieb, der euch beim Arbeiten hilft, statt euch zu beschäftigen.

Phase 4 — Übergabe & laufender Betrieb

Am Ende steht eine Dokumentation, die nicht nur beschreibt, was läuft, sondern auch, warum es so läuft. Architektur-Entscheidungen, Naming-Konventionen, Restore-Verfahren, Cost-Reports — alles an einem Ort, lesbar für die nächste Person, die das Setup verantworten wird. Optional begleiten wir den laufenden Betrieb: monatlicher Cost-Review, vierteljährlicher Architektur- und Backup-Check, jährlicher Restore-Drill, Reaktion auf Azure-Änderungen, gemeinsame Roadmap. Liefer-Ergebnis: eine Hybrid-Umgebung, die im Alltag stabil läuft, kostentransparent ist und sich auch in drei Jahren noch begründen lässt.

Was du von uns erwarten kannst — und was nicht

Was ihr bekommt:

Direkten Kontakt zum Gründer als festen Ansprechpartner — kein Ticket-Karussell, keine wechselnden Account-Manager:innen.
Remote-Reaktion sofort zu Service-Zeiten, mit ehrlicher Kommunikation, wenn etwas länger dauert.
Vor-Ort-Termine geplant nach Distanz: in Viersen binnen 24 Stunden, in Nachbarstädten 1–2 Werktage, weiter entfernt 3–5 Werktage.
Infrastructure-as-Code als Standard, nicht als Aufpreis-Option. Eure Azure-Umgebung ist reproduzierbar und versioniert.
Eine Dokumentation, mit der euch theoretisch jemand anderes ablösen könnte. Das ist Designziel, nicht Versehen.
Empfehlungen, die auch gegen unseren eigenen Umsatz gehen können, wenn es für euch passt.

Was wir bewusst nicht machen:

Vor-Ort-Pendel-Support im 30-Minuten-Modus für die Cloud-Operations selbst. Cloud-Betrieb ist Remote-Arbeit — Vor-Ort-Termine planen wir, wenn sie wirklich Sinn ergeben, zum Beispiel bei der Netzwerk-Anbindung oder beim physischen Backup-Konzept.
„Lift and Shift in die Cloud” als Pauschal-Versprechen. Wir migrieren, was hingehört, und lassen, was bleiben soll.
Versprechen, die ein 30-Personen-Team einlösen müsste, das wir nicht haben.

Wo wir auch mal Nein sagen:

Wenn ihr „alles in die Cloud” wollt, weil das gerade der Trend ist — dann sortieren wir vorher, welche Workloads dort wirklich gewinnen, und welche besser lokal bleiben.
Wenn ihr ExpressRoute haben wollt, weil ein Sales-Mensch das empfohlen hat, ohne die Bandbreite und Latenz eurer realen Workloads gemessen zu haben — dann messen wir das erst.
Wenn der Bedarf eigentlich gar nicht zu einem Cloud-Operations-Engagement passt, sondern zu einer einmaligen Migrations-Beratung oder zu einer reinen Backup-Konsolidierung.

So fängt es an

30 Minuten Erstgespräch, kostenfrei, unverbindlich, per Video oder Telefon.
Was wir klären: aktueller Stand eures Azure- und On-Prem-Setups, dringendste Schmerzpunkte, was in den nächsten 6–12 Monaten ansteht.
Optional vorab nützlich, aber nicht Pflicht: grobe Mitarbeitendenzahl, eingesetzte Azure-Dienste (Subscription-Liste oder Cost-Report reicht), bestehende ERP- und Branchensoftware, aktueller Backup-Stand.
Engagement-Modelle sind möglich als einmaliges Aufbau- oder Aufräum-Projekt, als laufende Betreuung im Quartals-Rhythmus, oder als Hybrid — was zu euch passt, klären wir im Gespräch.

Erstgespräch buchen

Häufige Fragen

Müssen wir alles in die Cloud bringen? Nein. Cloud ist eine Möglichkeit, kein Ziel. Wir empfehlen explizit, ERP-Systeme, CAD-Arbeitsplätze, Maschinensteuerungen und oft auch Konstruktions-File-Server lokal zu belassen, wenn sie dort stabil laufen. In die Cloud gehören typischerweise Workloads, die von Skalierung, Ausfallsicherheit über Regionen, oder weltweitem Zugriff profitieren — nicht alles, was sich technisch migrieren ließe.

Was bringt Azure-Hybrid statt reiner Cloud? Ein Hybrid-Setup nimmt die Vorteile beider Welten mit: Workloads, die wirklich von Cloud-Eigenschaften profitieren — Skalierung, geografische Verteilung, integrierte Dienste wie Entra ID oder Defender — wandern dorthin. Workloads, die lokale Performance, lokale Kontrolle oder spezielle Hardware brauchen, bleiben vor Ort. Identitäten und Backup-Strategien überspannen beide Seiten, sodass für die Mitarbeitenden alles wie ein zusammenhängendes System wirkt. Reine Cloud ist für die wenigsten Mittelständler die beste Antwort — Hybrid ist es für die meisten.

Wie hoch sind typische Azure-Kosten für eine Firma mit 80 Mitarbeitenden? Das hängt sehr stark davon ab, was ihr wirklich in Azure laufen lasst. Eine Firma, die nur Identitäten und Backup-Replikate dort hat, bewegt sich in einem deutlich anderen Bereich als eine Firma, die ihre ERP-Datenbank, ihren Fileservice und Virtual Desktops dort betreibt. Die Kostentreiber sind: VM-Anzahl und -Größe, Storage-Menge und Redundanz-Stufe, ausgehender Netzwerk-Traffic, Reservierungen ja oder nein, sowie verwendete Premium-Dienste (Azure SQL, Application Gateway, AVD). Im Erstgespräch geben wir eine qualitative Einordnung — konkrete Zahlen entstehen erst, wenn wir wissen, welche Workloads geplant sind.

Können wir später wieder weg von Azure? Ja, und das ist ein wichtiges Designziel. Wir bauen die Umgebung so, dass ein Wechsel zu einem anderen Hyperscaler, zurück on-prem oder zu einem anderen Dienstleister möglich bleibt. Konkret heißt das: Infrastructure-as-Code, sodass die Konfiguration unabhängig vom Portal vorliegt. Backups in offenen Formaten, nicht nur in Azure-eigenen Spezial-Containern. Dokumentation, die ohne uns lesbar ist. Globale Admin-Rechte bei euch im Haus, mit MFA und Notfall-Identität. Die Abhängigkeit von uns oder von Azure ist eine Wahl, keine Falle.

Was passiert mit unserem Maschinen-Netzwerk und unserer Produktion? Im Normalfall bleibt die Produktions-Welt unangetastet. Maschinensteuerungen, SPSen, MES-Systeme laufen in einem eigenen Netzsegment, oft mit eigener Firewall und eigenen Wartungszyklen. Was wir machen können, wenn es passt: kontrollierte Datenflüsse vom Maschinen-Netzwerk in Richtung Auswertung und Reporting, mit klaren Regeln, was raus darf und was nicht. Was wir nicht machen: die Steuerung selbst in die Cloud verlagern oder ihr Update-Regime von außen vorgeben.

Brauchen wir ExpressRoute? Meistens nein. ExpressRoute ist eine dedizierte Leitung zu Microsoft und kostet entsprechend. Für die allermeisten Mittelständler reicht ein gut konfiguriertes Site-to-Site-VPN über die vorhandene Firewall — die Bandbreite reicht, die Latenz reicht, die Verschlüsselung passt. ExpressRoute wird sinnvoll, wenn ihr sehr große Datenmengen kontinuierlich zwischen lokal und Azure bewegt, wenn ihr Compliance-Anforderungen habt, die das öffentliche Internet als Transportweg ausschließen, oder wenn AVD mit vielen gleichzeitigen Nutzenden über VPN tatsächlich an Limits stößt. Wir empfehlen das ehrlich anhand eurer Messwerte — nicht aus Reflex.

Cloud-Operations (Azure-Hybrid) — wenn Cloud helfen soll, aber nicht alles dorthin gehört