Structurizr Cloud wird am 30. September abgeschaltet: Hol zuerst dein Modell raus

Structurizrs Cloud-Dienst ist am Ende seines Lebenszyklus. Ihre End-of-Life-Seite führt "Structurizr cloud service (no replacement)" neben Lite, der CLI und der On-Premises-Installation auf — alle ersetzt durch das neue konsolidierte Tooling. Laut ihrer End-of-Life-Ankündigung wurden Workspaces am 1. Juli 2026 schreibgeschützt, die verbliebenen Monatsabos wurden am selben Tag beendet, und der Dienst wird am 30. September 2026 abgeschaltet. Diese Ankündigung liegt hinter Patreon — prüf die Daten also selbst nach, bevor du deine Planung darauf aufbaust.

Schreibgeschützt ist nicht der Notfall. Der Notfall ist das, was der Schreibschutz verdeckt: Die Werkzeuge, mit denen du deinen Workspace extrahieren würdest, sind Teil des Dienstes, der schließt. Der DSL-Tab im Workspace-Editor, der Export-Link auf deinem Dashboard, die Web-API. Das alles ist der Cloud-Dienst. Am 1. Oktober gibt es keinen Tab mehr zum Anklicken.

Die erste Entscheidung ist also nicht, zu welchem Tool du wechselst. Sie besteht darin, eine Datei auf deine Festplatte zu bekommen. Das ist ein Kopieren und Einfügen pro Workspace, und es verpflichtet dich zu nichts. Ein Ziel zu wählen ist weder das eine noch das andere.

Hol dein Modell raus

Mach diesen Teil zuerst, bevor du irgendetwas darunter liest.

Deine Workspaces sind schreibgeschützt, nicht unsichtbar. Structurizrs FAQ zum Cloud-Dienst sagt über schreibgeschützte Workspaces: "You can still view the workspace content (via the UI and web API) but no changes can be made" — du kannst den Inhalt des Workspace weiterhin ansehen (über die UI und die Web-API), aber es sind keine Änderungen möglich. Alles Folgende funktioniert heute.

Wenn du in DSL geschrieben und mit der CLI gepusht hast, bist du vielleicht schon fertig. Deine workspace.dsl liegt in Git. Öffne sie und prüf, ob sie aktuell ist. Die eine Sache, auf die du achten musst: Jedes Layout, das du im Browser-Diagrammeditor von Hand zurechtgerückt hast, lebt in der Cloud-Kopie, nicht in deinem DSL. Wenn dir das wichtig ist, nimm auch den JSON-Export aus Schritt 2 mit.

Wenn du im Browser oder über die Workspace API geschrieben hast, existiert dein Modell nur in Structurizrs Datenbank. In dieser Reihenfolge:

Das DSL. Structurizrs eigener Rat an bestehende Nutzer lautet, auf das DSL umzustellen. Von ihrer Hilfeseite zum Workspace-Editor: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — eine DSL-Repräsentation deines Workspace (ohne Dokumentation) findest du im DSL-Tab. Der Workspace-Editor selbst wurde im Februar 2022 eingestellt, ist aber weiterhin unter einer URL der Form https://structurizr.com/workspace/XXXXX/workspace-editor erreichbar, wobei XXXXX deine Workspace-ID ist. Öffne ihn, klick auf den DSL-Tab, kopier alles, speicher es als workspace.dsl.

Achte auf die Klammer in ihrem Satz. Die DSL-Repräsentation enthält die Dokumentation nicht. Wenn du Dokumentation oder ADRs in den Workspace geschrieben hast, statt !docs und !adrs auf Markdown-Dateien in einem Repository zeigen zu lassen, gibt der DSL-Tab sie dir nicht zurück.
Das JSON. Structurizrs Migrationshinweise verweisen dich auf den Link "export your workspaces" oben auf der Seite. Der erzeugt workspace.json. Nimm es mit, auch wenn du das DSL schon hast. Es ist das Format, das sowohl Structurizrs eigener Playground als auch local akzeptieren, und local sucht in dieser Reihenfolge nach workspace.dsl und workspace.json.
Alles, was die beiden Dateien auslassen. Im Workspace geschriebene Dokumentation, hochgeladene Bilder, Entscheidungen mit ihrer Statushistorie. Öffne den Workspace in der UI und kopier dir in Markdown, was dir wichtig ist, solange die UI noch existiert.
Committe beide Dateien in ein Repository. Nicht in einen Ordner auf dem Laptop. In ein Repository, neben den Code, den sie beschreiben, dorthin, wo die nächste Person sie findet.

Wiederhol das pro Workspace. Wenn du zwölf davon hast, mach sie in einem Rutsch, statt dir zu versprechen, dass du später nochmal zurückkommst.

Eines konnte ich nicht klären: Structurizr hat nirgendwo, wo ich es finden konnte, veröffentlicht, ob die Workspace-Daten am 30. September gelöscht oder nur unerreichbar gemacht werden. Geh nicht davon aus, dass du sie im Oktober zurückfordern kannst. Geh aber auch nicht vom Gegenteil aus. Hol dir die Dateien.

Wohin damit

Vier ehrliche Optionen. Sie passen zu unterschiedlichen Teams, und drei davon sind nicht archyl.

Option 1: Structurizrs eigenes Tooling

Das ist für mehr Teams die richtige Antwort, als irgendein Anbieter-Blog dir sagen wird, und es sollte das Erste sein, was du durchrechnest.

Structurizr verschwindet nicht. Der Cloud-Dienst verschwindet. Ihre EOL-Seite bildet die alten Produkte auf neue ab: Lite wird durch local ersetzt, die CLI durch pull / push / export und die On-Premises-Installation durch server. Wenn du heute auf Lite oder der CLI bist, hast du ebenfalls eine Migration vor dir — nur eine viel kleinere.

local wird in ihrer Doku so beschrieben: "the free and open source local command provides a way to view diagrams and modify their layout" — der kostenlose und quelloffene Befehl local bietet eine Möglichkeit, Diagramme anzusehen und ihr Layout zu ändern. Er läuft auf deiner Maschine, gebunden an localhost. Ihr Quickstart sind zwei Befehle: docker pull structurizr/structurizr, dann docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Richte ihn auf ein Verzeichnis mit deiner workspace.dsl, öffne http://localhost:8080, bearbeite die Datei, aktualisiere den Browser.
Der Playground ist ihr Vorschlag für gelegentliche Nutzung: workspace.dsl oder workspace.json hochladen, sich die Diagramme ansehen, den Tab schließen.
server ist der, der das ersetzt, was der Cloud-Dienst für dich getan hat: Workspaces einem größeren Publikum zugänglich machen. Er hat einen offenen Kern, der kostenlos ist, wenn du ihn aus dem Quellcode baust — mit Dateisystem-Storage, Lucene-Suche und ohne Authentifizierung. Die vorgebauten Binaries ergänzen SAML, rollenbasierte Zugriffskontrolle, private Sharing-Tokens, S3- und Azure-Blob-Storage, Elasticsearch und eine Admin-API und erfordern eine Lizenz: 300 £ pro Monat für 1 bis 20 eindeutige Nutzer, 600 £ für 21 bis 50, 900 £ für 51 bis 100, jährlich abgerechnet. Ihre Definition eines eindeutigen Nutzers zählt jede Person, die ein Diagramm ansieht — auch über ein iframe oder ein eingebettetes Bild —, nicht nur die Bearbeitenden.

Für wen das passt: Teams, deren Modell schon als DSL in Git liegt, deren Leser Engineers sind und deren Hauptnutzung des Cloud-Dienstes das Rendern war. Du behältst dein DSL exakt so, wie es ist, du behältst die Deployment- und die dynamischen Views, die unser eigener Importer fallen lässt, und das Tooling ist von der Person geschrieben, die das C4-Modell erfunden hat. Wenn das auf dich zutrifft: hör hier auf zu lesen und führ den Docker-Befehl aus.

Für wen es nicht passt: Teams, bei denen hundert Nicht-Engineers die Diagramme durchsehen müssen, ohne dass du einen Server betreibst, und Teams, für die 300 £ im Monat für zwanzig Betrachter schlechter aussehen als ein SaaS-Preis pro Bearbeiter. Und noch eines, worauf der gesamte Rest dieses Beitrags aufbaut: Selbst-Hosting bewahrt dein Modell, es pflegt es nicht. Der Workspace, der in der Cloud veraltet ist, veraltet auch in local. Niemand lässt das DSL neu laufen, wenn sich der Code ändert.

Option 2: das DSL im Repo behalten und aufhören, für ein Tool zu zahlen

Die am meisten unterschätzte Option, und die billigste.

workspace.dsl in Git, in Pull Requests reviewt wie alles andere, bei Bedarf gerendert, wenn wirklich jemand ein Bild braucht. local rendert es in einem Container. Der Playground auch. Wenn du lieber ganz von Structurizrs Syntax weg willst: LikeC4 steht unter MIT-Lizenz, wird als .c4-Dateien in deinem Repository geschrieben und über ein Vite-Plugin, React-Komponenten oder Web Components veröffentlicht — Diagramme lassen sich also in eine Doku-Site einbetten, die du ohnehin schon betreibst.

Für wen das passt: Teams, bei denen das Publikum der Diagramme eine Handvoll Engineers ist, die ein DSL lesen können, und bei denen die ehrliche Antwort auf „Wie oft öffnet das eigentlich jemand?“ „beim Onboarding und während Incidents“ lautet. Du verlierst nichts, was du benutzt hast, und deine laufenden Kosten sind null.

Für wen es nicht passt: für jeden, dessen Diagramme von Leuten gelesen werden, die kein Repository klonen werden. Was, wenn du für den Cloud-Dienst bezahlt hast, vielleicht genau der Grund ist, warum du bezahlt hast.

Option 3: ein anderes gehostetes C4-Tool

Wenn der Cloud-Dienst für dich eine Aufgabe erledigt hat, ist es ein vernünftiger Schritt, ihn durch ein anderes gehostetes Tool zu ersetzen — und du solltest dir mehr als eines ansehen.

IcePanel ist der nächstliegende Eins-zu-eins-Ersatz: ein visuell-orientiertes C4-Tool mit gehostetem Dienst und einer kostenlosen Stufe mit fünf Bearbeitern, unbegrenzt vielen Betrachtern und bis zu 100 Modellobjekten; bezahlte Pläne beginnen bei 40 $ pro Bearbeiter und Monat, jährlich abgerechnet. Ihr eigener Vergleich mit Structurizr sagt "model objects can be imported from Structurizr, Backstage, and a REST API" — Modellobjekte können aus Structurizr, Backstage und einer REST-API importiert werden. Auf den Seiten, die ich erreichen konnte, habe ich das akzeptierte Dateiformat nicht dokumentiert gefunden; bevor du dich festlegst, lad also genau die Datei hoch, die du im Abschnitt oben extrahiert hast, und prüf, was davon überlebt. Dieser Rat gilt für jedes Tool in diesem Beitrag, auch für unseres.

Für wen das passt: Teams, die einen Drag-and-drop-Editor wollen und deren Betrachter keine Engineers sind.

Für wen es nicht passt: Teams, die deshalb zu Structurizr gewechselt sind, weil das Modell Text war. Architecture-as-Code aufzugeben, um einer Cloud-Abschaltung zu entkommen, ist ein seltsamer Tausch, und du wirst es beim ersten Mal spüren, wenn du eine Änderung diffen willst.

Option 4: archyl

Wir haben einen Structurizr-DSL-Importer gebaut — das ist also die Option, die ich am besten kenne, und die, die du am skeptischsten lesen solltest.

Bring workspace.dsl mit, nicht workspace.json. Archyl parst Structurizr-DSL-Text. Es gibt keinen Weg über Workspace-JSON. Wenn dir der Export-Link nur JSON gegeben hat, lies den Abschnitt weiter unten, bevor du es versuchst.

Öffne ein Projekt, wähl im Import-Modal Structurizr DSL, lad die .dsl-Datei hoch oder füg sie ein. Was rüberkommt: person und softwareSystem auf oberster Ebene, verschachtelte container und component, Namen und Beschreibungen, Technologie-Strings an Containern und Components sowie an Beziehungen, kommagetrennte Tags, group-Blöcke in beliebiger Tiefe, flachgeklopft zu group:<name>-Tags, und Beziehungen, die irgendwo in der Datei deklariert sind, auch innerhalb von Element-Bodies. Container- und Beziehungstypen werden aus deinen Technologie- und Label-Strings abgeleitet. Externe Systeme werden am Tag External System oder External erkannt. Der Importer ist gegen Simon Browns eigenen Big-Bank-Beispiel-Workspace getestet.

Was nicht rüberkommt, und das wiegt schwerer:

Sämtliches Layout und Styling. views-, configuration- und styles-Blöcke werden übersprungen. Archyl legt das Diagramm stattdessen automatisch aus. Manuelles Layout ist eines der Dinge, die Structurizr verkauft — das ist also genau das, worin dein altes Tool am besten war, und du gibst es auf.
!docs und !adrs. Die Direktiven werden übersprungen. Archyl hat ADRs und Dokumentation; der Structurizr-Importer befüllt sie nicht.
!include. Workspaces aus mehreren Dateien müssen vor dem Import zusammengeführt werden, sonst ist der eingebundene Inhalt schlicht nicht da.
Deployment-Umgebungen, Deployment Nodes und Infrastructure Nodes. Werden nicht importiert.

Das meiste davon gibt dir der Importer als Warnliste auf dem Ergebnis-Screen des Imports zurück, in den Begriffen der Quelldatei selbst:

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

Zwei Einschränkungen dazu, denn eine Liste, der du trauen kannst, ist mehr wert als eine, die uns schmeichelt. Erstens werden Deployment-Umgebungen und -Nodes übersprungen: archyl modelliert die statische Struktur, nicht die Deployment-Topologie. Der Parser benennt sie mit Zeilennummer in der Warnliste — ein deploymentEnvironment "Live"-Block kommt also als lesbare Zeile an, statt dass du es später herausfindest. Zweitens sagt dir eine Warnung, was der Parser abgelehnt hat; sie sagt dir nicht, dass der Import ansonsten perfekt war. Lies das Modell danach durch.

Das eine Argument dafür, dafür zu zahlen, statt local zu betreiben: archyl prüft das Modell erneut gegen das Repository und bewertet die Lücke, sodass ein Modell, das nicht mehr zum Code passt, das auch sagt, statt still falsch zu werden. Das ist der Drift Score, er ist deterministisch, und er läuft ohne einen einzigen KI-Aufruf. Wenn dein Structurizr-Workspace an dem Tag, an dem die Cloud schreibgeschützt wurde, korrekt und aktuell war, brauchst du das nicht, und ich würde nicht versuchen, es dir zu verkaufen. Wenn er achtzehn Monate veraltet war, war nie das Tool das Problem, und ihn woandershin zu verschieben wird das nicht beheben.

Zwei Dinge, die du uns anlasten solltest. Der kostenlose Developer-Plan begrenzt ein Projekt auf 100 Modellobjekte — ein Workspace mit fünfzig Systemen und ihren Containern passt da nicht hinein; und archyl ist cloud-first, Self-Hosting gibt es nur in der Custom-Stufe. Der Grund, den Structurizr für die Schließung des Cloud-Dienstes genannt hat, in derselben Ankündigung, die auch die Daten enthält, war, dass Engineering-Teams zurückhaltend dabei waren, Architekturdiagramme in die Cloud zu veröffentlichen, und dass die Nutzung stetig zurückgegangen ist. Wenn das dein Security-Team beschreibt, passt Option 1 besser zu dir als wir, und du solltest nicht zwei Wochen damit verbringen, das im Beschaffungsprozess herauszufinden.

Wenn du nur eine JSON-Datei hast

Der Export-Link auf deinem Dashboard gibt dir workspace.json, und das ist die Datei, die die meisten am Ende in der Hand halten werden. Wo sie landet:

Structurizr local und der Playground lesen sie direkt. Nichts zu konvertieren.
Archyl nicht. Hol dir stattdessen das DSL aus dem DSL-Tab, und zwar vor dem 30. September. Wenn der Workspace über die Workspace API geschrieben wurde und der DSL-Tab dir nichts Brauchbares gibt, gibt es zwei Rückfalloptionen: Verbinde das Repository und lass die KI-Discovery das Modell aus dem Code vorschlagen, oder richte einen Coding-Agenten auf das JSON und lass ihn das Modell über den MCP-Server schreiben — das Rezept dafür steht hier.
Überall sonst: frag vor der Migration, nicht danach.

Die Wahl, in einem Absatz

Wenn dein Modell schon als DSL in Git liegt und deine Leser Engineers sind, lass local laufen und gib das gesparte Geld woanders aus. Wenn du eine teilbare, zugriffskontrollierte Instanz brauchst und die Lizenz tragen kannst, ist server das, was dem am nächsten kommt, was der Cloud-Dienst für dich getan hat. Wenn du einen visuellen Editor und nicht-technische Betrachter willst, sieh dir IcePanel an. Wenn der Workspace, den du gerade exportiert hast, ohnehin schon veraltet war — und er veraltet ist, weil ihn von Hand zu aktualisieren irgendjemandes vierte Priorität war —, dann ist nicht das Tool das, was ersetzt werden muss, und genau das ist der Punkt, den archyl macht.

Was auch immer du davon wählst: hol zuerst die Dateien raus. Der Tab verschwindet mit dem Dienst.

Mehr zur Mechanik: Structurizr-, LikeC4- und IcePanel-Projekte importieren, die Structurizr-Migrationsseite und ein Vergleich der C4-Tools 2026. Wenn das Modell selbst neu für dich ist, fang mit dem C4-Modell und Architecture Drift an.