Windows 365 löst Dev Box ab: gute Konsolidierung, neue Abhängigkeit fürs KMU
Microsoft macht Windows 365 zur Plattform für Entwickler-Arbeitsplätze und stellt Dev Box ein. Für KMU bedeutet das weniger Verwaltung, aber mehr Abhängigkeit von einem einzigen Dienst – ein Exit-Plan gehört dazu.
In Kürze
- Microsoft Dev Box geht in die Ablösung, Windows 365 wird die Plattform für Entwickler-Arbeitsplätze.
- Die Schliessphase begann am 14. September 2026, das Enddatum ist der 18. September 2028.
- Eine Plattform bedeutet weniger Verwaltungsaufwand, aber mehr Abhängigkeit von einem einzigen Dienst.
Der Befund
Microsoft hat am 14. September 2026 im Blog "Build anywhere, stay in flow with Windows 365" angekündigt, Entwickler-Arbeitsplätze künftig auf Windows 365 statt auf Microsoft Dev Box zu bauen. Bestätigt wird das durch die eigene Produktdokumentation: Sie hält für Dev Box exakt dasselbe Datum fest, den 14. September 2026, als Beginn der Schliessphase, mit vollständiger Ablösung bis zum 18. September 2028. Bis dahin sollen Dev-Box-Kundinnen und -Kunden ihre Umgebungen gemäss eigener Roadmap auf Windows 365 oder eine andere passende Lösung übertragen.
Windows 365 selbst wird dafür ausgebaut: Cloud-PCs mit bis zu 32 virtuellen Prozessorkernen, GPU-fähige Konfigurationen für rechenintensive Aufgaben, vorbereitete Ready-to-Code-Images mit Visual Studio Code, Git, Python, Node.js und WSL Ubuntu bereits installiert. Dazu kommen in den nächsten Monaten Microsoft Execution Containers für isolierte Agent-Workloads wie Copilot-CLI-Aufgaben, sowie eine Vorschau für kontextbasierte Umleitungssteuerung, die Zwischenablage, Laufwerke, Drucker und USB-Zugriff je nach Sicherheitslage automatisch einschränken kann. Für Entwicklerteams, die bisher zwischen Dev Box für Code und Windows 365 für alles andere unterschieden haben, fällt diese Trennung weg: Ein Gerätetyp, eine Verwaltungsoberfläche, ein Abrechnungsmodell, egal ob eine Person damit E-Mails liest oder einen Build kompiliert.
Für Ihr Unternehmen bedeutet die Umstellung zunächst vor allem Planungsarbeit, nicht sofortigen Handlungsdruck. Die Schliessphase von Dev Box läuft über zwei Jahre, bestehende Umgebungen funktionieren in dieser Zeit weiter. Wer heute neu mit Cloud-Entwicklerarbeitsplätzen beginnt, kann direkt auf Windows 365 setzen, wer bereits auf Dev Box aufgebaut hat, sollte die Migration in die eigene IT-Planung für die kommenden zwei Jahre aufnehmen, statt sie kurzfristig unter Zeitdruck zu erledigen.
Der Mechanismus
Der Grund für den Schritt ist naheliegend: Zwei separate Cloud-PC-Dienste zu pflegen kostet Microsoft und seine Kundschaft doppelt, an Lizenzlogik, an Verwaltungsoberflächen, an Support. Windows 365 kennt bereits die Editionen Business für kleinere Betriebe bis 300 Sitze und Enterprise mit unbegrenzten Sitzen und voller Intune-Integration, jede Cloud-PC in einer festen 1:1-Zuordnung zu einer Person. Für Agenten-Workloads gibt es daneben ein eigenes, nutzungsbasiertes Abrechnungsmodell, während menschliche Cloud-PCs pauschal pro Sitz und Monat verrechnet werden. Diese Struktur auf Entwicklerarbeitsplätze auszuweiten, spart eine zweite Verwaltungsschicht, die IT-Teams in kleineren Firmen ohnehin selten doppelt bedienen können.
| Aspekt | Getrennte Dienste (Dev Box + Windows 365) | Eine Plattform (Windows 365 für alle) |
|---|---|---|
| Verwaltungsaufwand | Zwei Lizenzmodelle, zwei Konsolen | Eine Konsole, ein Abrechnungsmodell |
| Abhängigkeit von einem Anbieter | Aufgeteilt auf zwei Dienste | Vollständig auf einen Dienst konzentriert |
| Exit-Optionen bei Preis- oder Strategiewechsel | Getrennt verhandelbar | Ein Ausstieg betrifft beide Nutzungsarten |
| Netzabhängigkeit im Alltag | Schon vorhanden für Cloud-PCs | Zusätzlich auch für Entwicklerarbeit nötig |
Eine Plattform für alles spart Verwaltung, bindet ein KMU aber vollständig an einen einzigen Anbieter.
Für ein KMU, das heute vielleicht nur Standard-Cloud-PCs nutzt und morgen auch Entwicklerarbeitsplätze dazunimmt, heisst das: Die gesamte technische Arbeitsumgebung hängt an einem Vertrag, einem Preismodell und einer Netzverbindung. Das ist nicht grundsätzlich falsch, aber es verändert, was im Notfall auf dem Spiel steht.
Die Gegenseite
Der stärkste Einwand kommt aus dem Maschinenraum selbst: Lokale Entwicklerhardware ist günstiger pro Stunde Nutzung, läuft auch ohne Internetverbindung weiter und lässt sich nicht durch einen entfernten Preis- oder Strategieentscheid über Nacht verändern. Wer im Zug oder an Orten mit schlechter Verbindung arbeitet, merkt den Unterschied zwischen einer lokalen Workstation und einem Cloud-PC sofort. Andere Anbieter cloud-basierter Entwicklerumgebungen existieren ebenfalls, sie lösen das Netzabhängigkeitsproblem allerdings nicht grundsätzlich anders.
Der Einwand trifft einen echten Punkt, sticht das Konsolidierungsargument aber nicht aus. Für einzelne Entwicklerinnen mit hohen, planbaren Offline-Anforderungen bleibt lokale Hardware sinnvoll, und Windows 365 schliesst das nicht aus, ein Gerät kann beides zugleich tun. Für ein KMU mit einer Handvoll Entwicklerstellen ist die Frage aber selten Cloud gegen lokal im Ganzen, sondern wie viel Abhängigkeit sich mit einem klaren Exit-Plan vertreten lässt. Wer die Zahl der Sitze, die Kosten pro Monat und eine Alternative für den Ausstiegsfall kennt, kann die Konsolidierung nutzen, ohne blind hineinzulaufen. Wer hingegen weder das eine noch das andere vorher durchgerechnet hat, merkt die Abhängigkeit erst, wenn ein Preis- oder Strategiewechsel sie sichtbar macht, und dann meist zu einem ungünstigeren Zeitpunkt als heute.
Was das für Ihr KMU heisst
- Rechnen Sie die Kosten pro Entwicklersitz und pro Monat, bevor Sie von Dev Box umstellen.
- Prüfen Sie die Netzabhängigkeit an den Standorten, an denen Ihre Entwickler tatsächlich arbeiten.
- Halten Sie einen Exit-Plan bereit, falls Preise oder Bedingungen sich später ändern.
