Antworten zu Azure Landing Zones, Cloud-Migration-Strategien, Microsoft 365 Rollouts, Hybrid-Cloud-Architekturen und Microsoft Fabric — von der Discovery bis zum Go-Live.
Wir setzen auf erprobte Migrationsmethoden mit ausführlichen Tests, Rollback-Plänen und schrittweisen Cutover-Strategien. Kritische Systeme werden außerhalb der Geschäftszeiten migriert.
Das hängt vom Umfang ab. Eine Microsoft 365 Migration für 500 User dauert ca. 4-8 Wochen. Komplexe Infrastruktur-Migrationen können 3-6 Monate in Anspruch nehmen.
Absolut. Hybride Szenarien sind unser Alltag. Wir sorgen für einen sanften Übergang mit definiertem Parallelbetrieb und klaren Meilensteinen für die Ablösung.
Die Treiber sind zählbar: Anzahl der Arbeitsplätze und Postfächer, zu bewegendes Datenvolumen, Anzahl und Alter der Server-Workloads, Anteil an Altanwendungen ohne Cloud-Freigabe des Herstellers, Zahl der Standorte und Rollout-Wellen sowie die Frage, ob ein Wartungsfenster erlaubt ist oder ein unterbrechungsfreier Cutover gefordert wird. Abgerechnet wird als Festpreis je abgegrenzter Phase — Assessment, Pilot, Wellen-Rollout —, je Arbeitsplatz bei wiederkehrenden Rollout-Wellen oder nach Aufwand dort, wo der Umfang offen ist. Microsoft-Lizenzen und Azure-Verbrauch laufen getrennt davon über Ihre eigenen Verträge.
Wir beginnen fast immer mit einem Assessment zum Festpreis, weil es die Grundlage für jede belastbare Zusage danach ist. Die Umsetzung folgt als Festpreis je Phase mit definierter Abnahme; Kriterien wie erfolgreicher Pilot, geprüfter Rollback und abgeschlossene Datenübernahme halten wir vorab schriftlich fest. Wiederkehrende Rollout-Wellen rechnen wir je Arbeitsplatz ab, Altlasten mit unklarem Umfang nach Aufwand mit Obergrenze. Die Hypercare-Phase nach dem Go-Live ist ein befristetes Kontingent. Kosten entstehen erst nach schriftlicher Aufwandsschätzung und Ihrer Freigabe.
In vier Schritten: Inventar aller administrativen Konten und delegierten Zugriffe, Übernahme der vorhandenen Dokumentation, Parallelbetrieb mit klarem Stichtag, dann Abschaltung der Altzugänge nach Abnahme. Zwei Punkte werden dabei regelmäßig übersehen. Erstens: Break-Glass-Konten müssen in Ihrem Besitz sein und dürfen nie ausschließlich beim Dienstleister liegen. Zweitens: Der Dienstleisterwechsel ist vom Lizenzvertrag zu trennen — platzbasierte Microsoft-Abonnements im neuen Handelsmodell lassen sich nur innerhalb von sieben Kalendertagen nach Kauf oder Verlängerung kündigen und laufen sonst bis zum Laufzeitende weiter.
Das Assessment beginnt in der Regel innerhalb weniger Tage nach Beauftragung. Von Ihnen brauchen wir einen Projektverantwortlichen mit Entscheidungsbefugnis, administrativen Zugang zur Ist-Umgebung, vorhandene Netz- und Systemdokumentation, eine Liste der geschäftskritischen Anwendungen samt Herstellerkontakt, eine Testgruppe für den Pilot und freigegebene Wartungsfenster. Bei Endgeräte-Rollouts kommt die Abstimmung mit dem Betriebsrat hinzu — die dauert erfahrungsgemäß länger als die Technik. Der häufigste Projektstopper ist eine Altanwendung, für die der Hersteller keine Freigabe für den Zielbetrieb erteilt.
Ja, und zwar als Teil der Abnahme, nicht als Gefallen danach. Sie erhalten eine As-built-Dokumentation der Zielumgebung, das Infrastructure-as-Code-Repository mit den Bicep-Vorlagen, Runbooks, die Cutover- und Rollback-Protokolle sowie eine vollständige Übersicht aller angelegten Konten, Dienstprinzipale und Berechtigungen. Sämtliche administrativen Konten liegen in Ihrem eigenen Tenant; unsere Zugänge sind separate, benannte Konten, die zum vereinbarten Stichtag deaktiviert und entfernt werden. Wir setzen kein eigenes Werkzeug ein, dessen Wegfall die Umgebung unbetreibbar machen würde.
Durch die Wahl von EU-Regionen und eine Prüfung je Dienst, nicht durch eine pauschale Zusage. Microsoft hat die letzte Ausbaustufe der EU Data Boundary am 26. Februar 2025 in Kraft gesetzt: Kundendaten und pseudonymisierte Personendaten werden für Microsoft 365, Dynamics 365, Power Platform und die meisten Azure-Dienste in EU- und EFTA-Regionen gespeichert und verarbeitet, Daten aus dem technischen Support dort zumindest ruhend gespeichert. Microsoft dokumentiert weiterhin Ausnahmen — etwa Titel von Supportfällen oder Eskalationen an Produktteams —, und für einzelne nicht-regionale Azure-Dienste ist eine Konfiguration auf Kundenseite nötig. Wir dokumentieren je Workload, wo Daten liegen. Datenresidenz allein ersetzt jedoch keine datenschutzrechtliche Prüfung der Drittlandsübermittlung.
S2D ist die zugrunde liegende Storage-Technologie, auf der Microsofts Azure Local (vormals Azure Stack HCI) aufbaut. Wir konzipieren Ihre Cluster von Anfang an Azure-Local-kompatibel, damit Sie später nahtlos in hybrides Cloud-Management wechseln können, ohne die Infrastruktur neu aufzubauen.
Klassische Backup-Ziele sind vom Produktivnetzwerk aus erreichbar und damit selbst angreifbar. Erst unveränderlicher (immutable) Storage — bei dem selbst Administratoren gesicherte Daten nicht löschen oder verschlüsseln können — schützt zuverlässig gegen Ransomware, die gezielt Backups zuerst angreift.
Über Fine-Grained Password Policies (FGPP) in Active Directory in Kombination mit automatisierter Passwort-Verwaltung — niemand merkt sich mehr ein Passwort. Für die Alltagsanmeldung an verwalteten Endgeräten nutzen wir Windows Hello for Business (biometrisch oder per PIN, gerätegebunden); für Zugriffe, die nicht an ein einzelnes Gerät gebunden sein dürfen — etwa privilegierte Zugriffe oder wechselnde Arbeitsplätze — kommen YubiKeys als portabler, hardwarebasierter Faktor zum Einsatz. Die zugrunde liegenden Passwörter rotieren täglich automatisiert im Hintergrund und sind für niemanden mehr sichtbar oder merkbar, was klassische Passwort-Angriffe praktisch wirkungslos macht.
Die Entscheidung fällt je Workload, nicht pauschal für das ganze Unternehmen. Für eigene Hardware sprechen konstante Dauerlast, harte Latenzanforderungen etwa zu Produktionsanlagen, große Datenmengen mit hohem Durchsatz und regulatorische Vorgaben zur Datenhoheit. Für die Public Cloud sprechen schwankende Lasten, kurze Bereitstellungszeiten, geografische Verteilung und der Wunsch, keine Hardware mehr zu betreiben. Zusätzlich zählen die Restlaufzeit vorhandener Hardware, verfügbares Betriebs-Know-how und die Ausstiegsfähigkeit. In der Praxis endet es meist hybrid: ERP und Dateidienste lokal auf einem Cluster, Identität, Kollaboration und die ausgelagerte Backup-Kopie in der Cloud.
Vor allem die Resilienz-Entscheidung, weil sie die benötigte Rohkapazität bestimmt. Ein Zwei-Wege-Spiegel braucht mindestens zwei Server und erreicht 50 Prozent Speichereffizienz, ein Drei-Wege-Spiegel mindestens drei Server und 33,3 Prozent — für ein Terabyte Nutzdaten also drei Terabyte Rohkapazität. Für produktive Zwei-Knoten-Cluster empfiehlt Microsoft zusätzlich Nested Resiliency, die als verschachtelter Zwei-Wege-Spiegel nur rund 25 Prozent Speichereffizienz erreicht. Dazu kommen NVMe-Anteil und Cache-Auslegung, das Netzwerk mit redundanten 10G- oder 25G-Switches sowie die Lizenzierung: Windows Server wird nach physischen Kernen lizenziert, mindestens acht je Prozessor und sechzehn je Server. Bei Azure Local kommt eine monatliche Abrechnung je physischem Kern hinzu, Gastbetriebssysteme werden separat lizenziert.
Assessment und Architektur laufen als Festpreis, ebenso Aufbau und Migration je Phase mit definierter Abnahme. Als Abnahmekriterien vereinbaren wir überprüfbare Tests statt weicher Formulierungen: erfolgreicher Failover eines Clusterknotens im laufenden Betrieb, dokumentierter Restore aus dem unveränderlichen Backup, gemessener Durchsatz. Offene Altlasten rechnen wir nach Aufwand ab. Hardware und Lizenzen können Sie über Ihren gewohnten Einkaufsweg beziehen; unsere Sizing-Empfehlung ist davon unabhängig. Der spätere Betrieb ist optional als Managed Service je Server und Cluster buchbar.
Assessment ein bis zwei Wochen, Architektur und Sizing zwei bis vier Wochen; danach bestimmt fast immer die Lieferzeit von Servern und Switches den Termin, nicht die Konfiguration. Von Ihnen brauchen wir Rack-Platz mit ausreichender Stromversorgung, idealerweise zwei Kreisen und USV, Kühlung mit Reserve, freie Switch-Ports und Uplinks, ein IP- und VLAN-Konzept oder die Freiheit, eines zu entwerfen, Zutritt zum Serverraum sowie freigegebene Wartungsfenster für den Cutover. Ergänzend eine Liste der Anwendungen mit Ansprechpartnern, damit Abhängigkeiten vor der Migration bekannt sind.
Ja, beides. Zur Abnahme gehören eine As-built-Dokumentation mit Cluster-Layout, Volumes samt gewähltem Resilienz-Typ, VLAN- und Firewall-Übersicht, Backup-Jobs mit Aufbewahrungsfristen sowie das Protokoll des Restore-Tests. Administrative Zugänge einschließlich Break-Glass-Konten liegen bei Ihnen, nicht bei uns. Die Umgebung basiert auf Standardtechnologien — Windows Server mit Storage Spaces Direct, marktübliche Switches, Veeam für Backup — und nicht auf proprietären Alendris-Komponenten. Sie können den Betrieb selbst übernehmen, an einen Dritten geben oder uns beauftragen; wir übergeben in allen drei Fällen dieselben Runbooks.
Die Nutzdaten Ihrer virtuellen Maschinen und Dateidienste liegen physisch in Ihrem Rechenzentrum und verlassen es auch bei einer Azure-Anbindung nicht. Was an Azure fließt, sind Verwaltungs- und Abrechnungsdaten: Inventar, Zustandsmeldungen und die Zahl der physischen Kerne, nach denen Azure Local monatlich abgerechnet wird. Diese Daten gehen in die Region, in der das System registriert wurde — Azure Local unterstützt dafür nur eine begrenzte Liste an Regionen, innerhalb der EU derzeit West Europe. Wir registrieren dort und dokumentieren es. Gleiches gilt für die ausgelagerte Backup-Kopie: Eine unveränderliche Kopie bleibt vor Ort, die zweite liegt in einer EU-Region mit vertraglich fixierter Aufbewahrungsfrist.