Structurizr Cloud cierra el 30 de septiembre: saca tu modelo primero

El servicio cloud de Structurizr ha llegado al final de su vida. Su página de fin de vida lista "Structurizr cloud service (no replacement)" junto a Lite, la CLI y la instalación on-premises, todos reemplazados por el nuevo tooling consolidado. Según su anuncio de fin de vida, los workspaces pasaron a solo lectura el 1 de julio de 2026, las suscripciones mensuales restantes se detuvieron ese mismo día, y el servicio se apaga el 30 de septiembre de 2026. Ese anuncio está detrás de Patreon, así que contrasta tú mismo las fechas antes de planificar nada a partir de ellas.

El solo lectura no es la emergencia. La emergencia es lo que el solo lectura esconde: las herramientas que usarías para extraer tu workspace forman parte del servicio que cierra. La pestaña DSL del editor de workspace, el enlace de exportación en tu panel, la API web. Todo eso es el servicio cloud. El 1 de octubre no hay ninguna pestaña que pulsar.

Así que la primera decisión no es a qué herramienta te mudas. Es conseguir un archivo en tu disco. Eso es un copiar y pegar por workspace, y no te compromete a nada. Elegir un destino no es ninguna de las dos cosas.

Saca tu modelo

Haz esta parte primero, antes de leer nada de lo que viene después.

Tus workspaces están en solo lectura, no invisibles. La FAQ del servicio cloud de Structurizr dice sobre los workspaces en solo lectura: "You can still view the workspace content (via the UI and web API) but no changes can be made" — puedes seguir viendo el contenido del workspace (a través de la interfaz y la API web) pero no se pueden hacer cambios. Todo lo de abajo funciona hoy.

Si escribías en DSL y hacías push con la CLI, puede que ya hayas terminado. Tu workspace.dsl está en Git. Ábrelo y comprueba que está al día. Lo único que tienes que mirar: cualquier layout que hayas ajustado a mano en el editor de diagramas del navegador vive en la copia de la nube, no en tu DSL. Si eso te importa, llévate también la exportación JSON del paso 2.

Si escribías en el navegador, o a través de la Workspace API, tu modelo existe únicamente en la base de datos de Structurizr. En este orden:

El DSL. El consejo que Structurizr da a sus usuarios actuales es convertir al DSL. De su página de ayuda del editor de workspace: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — una representación DSL de tu workspace (excluyendo la documentación) se encuentra en la pestaña DSL. El editor de workspace en sí se discontinuó en febrero de 2022, pero sigue siendo accesible en una URL con la forma https://structurizr.com/workspace/XXXXX/workspace-editor, donde XXXXX es el ID de tu workspace. Ábrelo, pulsa la pestaña DSL, copia todo, guárdalo como workspace.dsl.

Fíjate en el paréntesis de su frase. La representación DSL excluye la documentación. Si escribiste documentación o ADRs dentro del workspace en lugar de apuntar !docs y !adrs a ficheros Markdown de un repository, la pestaña DSL no te los va a devolver.
El JSON. La guía de migración de Structurizr te lleva al enlace "export your workspaces" de la parte superior de la página. Eso produce workspace.json. Llévatelo aunque ya tengas el DSL. Es el formato que aceptan tanto el playground de Structurizr como local, y local busca workspace.dsl y workspace.json en ese orden.
Todo lo que esos dos ficheros se dejan fuera. Documentación escrita dentro del workspace, imágenes que subiste, registros de decisiones con su histórico de estados. Abre el workspace en la interfaz y copia a Markdown lo que te importe mientras la interfaz siga existiendo.
Haz commit de ambos ficheros en un repository. No en una carpeta del portátil. En un repository, al lado del código que describen, donde la próxima persona los encontrará.

Repite por cada workspace. Si tienes doce, hazlos de una sentada en lugar de prometerte que volverás luego.

Una cosa que no he podido establecer: Structurizr no ha publicado, en ningún sitio que yo haya encontrado, si los datos de los workspaces se borran el 30 de septiembre o simplemente se vuelven inaccesibles. No des por hecho que podrás pedirlos de vuelta en octubre. Tampoco des por hecho lo contrario. Consigue los ficheros.

Dónde ponerlo

Cuatro opciones honestas. Sirven a equipos distintos, y tres de ellas no son archyl.

Opción 1: el propio tooling de Structurizr

Esta es la respuesta correcta para más equipos de los que ningún blog de proveedor te va a decir, y debería ser lo primero que presupuestes.

Structurizr no desaparece. El servicio cloud sí. Su página EOL mapea los productos viejos sobre los nuevos: Lite se reemplaza por local, la CLI por pull / push / export, y la instalación on-premises por server. Si hoy estás en Lite o en la CLI, también tienes una migración por delante, solo que mucho más pequeña.

local se describe en su documentación así: "the free and open source local command provides a way to view diagrams and modify their layout" — el comando local, gratuito y de código abierto, permite ver los diagramas y modificar su layout. Corre en tu máquina, ligado a localhost. Su quickstart son dos comandos: docker pull structurizr/structurizr, y luego docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Apúntalo a un directorio que contenga tu workspace.dsl, abre http://localhost:8080, edita el fichero, refresca el navegador.
El playground es su sugerencia para un uso ocasional: subes workspace.dsl o workspace.json, miras los diagramas, cierras la pestaña.
server es el que reemplaza lo que el servicio cloud hacía por ti: publicar workspaces ante una audiencia más amplia. Tiene un núcleo abierto que es gratuito si lo compilas desde el código fuente, con almacenamiento en sistema de ficheros, búsqueda con Lucene y sin autenticación. Los binarios precompilados añaden SAML, control de acceso basado en roles, tokens de compartición privados, almacenamiento en S3 y Azure Blob, Elasticsearch y una API de administración, y requieren licencia: 300 £ al mes para 1 a 20 usuarios únicos, 600 £ para 21 a 50, 900 £ para 51 a 100, facturado anualmente. Su definición de usuario único cuenta a cualquiera que vea un diagrama, incluso a través de un iframe o de una imagen embebida, no solo a quienes editan.

A quién le encaja: a equipos cuyo modelo ya es DSL en Git, cuyos lectores son ingenieros, y cuyo uso principal del servicio cloud era el renderizado. Conservas tu DSL exactamente como está, conservas las vistas de deployment y las dinámicas que nuestro propio importador descarta, y el tooling está escrito por la persona que inventó el modelo C4. Si ese eres tú, deja de leer aquí y ve a ejecutar el comando de Docker.

A quién no le encaja: a equipos que necesitan que cien personas no técnicas naveguen los diagramas sin que tú operes un servidor, y a equipos para los que 300 £ al mes por veinte lectores se lee peor que un precio SaaS por editor. Y una más, que es el argumento sobre el que se apoya el resto de este artículo: autoalojar preserva tu modelo, no lo mantiene. El workspace que se quedó obsoleto en la nube se quedará obsoleto también en local. Nadie vuelve a ejecutar el DSL cuando cambia el código.

Opción 2: dejar el DSL en el repo y dejar de pagar por una herramienta

La opción más infravalorada, y la más barata.

workspace.dsl en Git, revisado en pull requests como cualquier otra cosa, renderizado bajo demanda cuando alguien de verdad necesita una imagen. local lo renderiza en un container. El playground también. Si prefieres salir por completo de la sintaxis de Structurizr, LikeC4 tiene licencia MIT, se escribe como ficheros .c4 en tu repository, y se publica mediante un plugin de Vite, componentes React o web components, de forma que los diagramas se pueden embeber en un sitio de documentación que ya operas.

A quién le encaja: a equipos donde la audiencia de los diagramas es un puñado de ingenieros capaces de leer un DSL, y donde la respuesta honesta a «¿cada cuánto abre alguien esto?» es «en el onboarding y durante los incidentes». No pierdes nada de lo que estabas usando y tu coste recurrente es cero.

A quién no le encaja: a cualquiera cuyos diagramas los lean personas que no van a clonar un repository. Lo cual, si estabas pagando por el servicio cloud, puede ser exactamente el motivo por el que pagabas.

Opción 3: otra herramienta C4 alojada

Si el servicio cloud te estaba resolviendo un problema real, reemplazarlo por otra herramienta alojada es un movimiento razonable, y deberías mirar más de una.

IcePanel es el equivalente más directo: una herramienta C4 visual ante todo, con servicio alojado y un plan gratuito de cinco editores, lectores ilimitados y hasta 100 objetos de modelo, con planes de pago desde 40 $ por editor al mes facturados anualmente. Su propia comparativa frente a Structurizr dice "model objects can be imported from Structurizr, Backstage, and a REST API" — los objetos de modelo se pueden importar desde Structurizr, Backstage y una API REST. No he encontrado documentado el formato de fichero aceptado en las páginas a las que he podido llegar, así que antes de comprometerte, sube exactamente el fichero que extrajiste en la sección anterior y confirma qué sobrevive. Ese consejo vale para todas las herramientas de este artículo, incluida la nuestra.

A quién le encaja: a equipos que quieren un editor de arrastrar y soltar y cuyos lectores no son ingenieros.

A quién no le encaja: a equipos que se pasaron a Structurizr porque el modelo era texto. Renunciar a la arquitectura como código para escapar del cierre de un servicio cloud es un trueque extraño, y lo vas a notar la primera vez que quieras hacer un diff de un cambio.

Opción 4: archyl

Nosotros construimos un importador de Structurizr DSL, así que esta es la opción que mejor conozco y la que deberías leer con más escepticismo.

Trae workspace.dsl, no workspace.json. Archyl parsea texto de Structurizr DSL. No hay camino para el JSON del workspace. Si el enlace de exportación solo te dio JSON, mira la sección de más abajo antes de intentarlo.

Abre un proyecto, elige Structurizr DSL en el modal de importación, sube el fichero .dsl o pégalo. Lo que cruza: person y softwareSystem en el nivel superior, container y component anidados, nombres y descripciones, cadenas de tecnología en containers y components y en las relaciones, tags separados por comas, bloques group a cualquier profundidad aplanados en tags group:<name>, y relaciones declaradas en cualquier punto del fichero, incluso dentro del cuerpo de los elementos. Los tipos de container y de relación se infieren de tus cadenas de tecnología y de tus etiquetas. Los sistemas externos se detectan a partir del tag External System o External. El importador está probado contra el propio workspace de ejemplo Big Bank de Simon Brown.

Lo que no cruza, que importa más:

Todo el layout y el estilo. Los bloques views, configuration y styles se omiten. Archyl calcula en su lugar un layout automático. El layout manual es una de las cosas que Structurizr vende, así que esto es aquello en lo que tu herramienta anterior era mejor, y lo estás dejando atrás.
!docs y !adrs. Las directivas se omiten. Archyl tiene ADRs y documentación; el importador de Structurizr no los rellena.
!include. Los workspaces repartidos en varios ficheros hay que aplanarlos antes de importar, o el contenido incluido sencillamente no está.
Entornos de deployment, deployment nodes y infrastructure nodes. No se importan.

El importador te devuelve casi todo eso como una lista de avisos en la pantalla de resultado de la importación, en los propios términos del fichero de origen:

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

Dos salvedades sobre eso, porque una lista en la que puedes confiar vale más que una lista que nos halaga. Primera, los entornos y nodos de deployment se omiten: archyl modela la estructura estática, no la topología de despliegue. El parser los nombra con su número de línea en la lista de avisos, así que un bloque deploymentEnvironment "Live" llega como una línea que puedes leer en vez de algo que descubres después. Segunda, un aviso te dice qué rechazó el parser; no te dice que la importación fuera perfecta por lo demás. Lee el modelo después.

El único argumento para pagar por esto en lugar de ejecutar local: archyl vuelve a contrastar el modelo con el repository y puntúa la distancia, de modo que un modelo que deja de coincidir con el código lo dice, en vez de volverse silenciosamente falso. Eso es el drift score, es determinista y funciona sin ninguna llamada a la IA. Si tu workspace de Structurizr era exacto y estaba al día el día que la nube pasó a solo lectura, no necesitas esto y yo no intentaría vendértelo. Si llevaba dieciocho meses obsoleto, la herramienta nunca fue el problema, y moverlo a otro sitio no lo va a arreglar.

Dos cosas que deberías tenernos en cuenta. El plan Developer gratuito limita un proyecto a 100 objetos de modelo, así que un workspace con cincuenta sistemas y sus containers no cabe en él; y archyl es cloud-first, con autoalojamiento solo en el nivel Custom. La razón que dio Structurizr para cerrar el servicio cloud, en el mismo anuncio que lleva las fechas, fue que los equipos de ingeniería han sido reacios a publicar diagramas de arquitectura en la nube y que el uso había ido cayendo de forma sostenida. Si eso describe a tu equipo de seguridad, la opción 1 encaja mejor que nosotros, y no deberías gastar dos semanas en descubrirlo dentro de un proceso de compra.

Si lo único que tienes es un fichero JSON

El enlace de exportación de tu panel te da workspace.json, y es el fichero con el que la mayoría de la gente va a acabar. Dónde aterriza:

Structurizr local y el playground lo leen directamente. Nada que convertir.
Archyl no. Consigue el DSL desde la pestaña DSL, y hazlo antes del 30 de septiembre. Si el workspace se escribió a través de la Workspace API y la pestaña DSL no te da algo utilizable, dos alternativas: conecta el repository y deja que el descubrimiento con IA proponga el modelo a partir del código, o apunta un agente de código al JSON y haz que escriba el modelo mediante el servidor MCP, que es la receta que hay aquí.
En cualquier otro sitio: pregunta antes de migrar, no después.

Elegir, en un párrafo

Si tu modelo ya es DSL en Git y tus lectores son ingenieros, ejecuta local y gasta en otra cosa el dinero que te ahorras. Si necesitas una instancia compartible y con control de acceso y puedes cargar con la licencia, server es lo más parecido a lo que el servicio cloud hacía por ti. Si quieres un editor visual y lectores no técnicos, mira IcePanel. Si el workspace que acabas de exportar ya estaba desactualizado, y está desactualizado porque actualizarlo a mano era la cuarta prioridad de alguien, entonces la herramienta no es lo que hay que reemplazar, y ese es justamente el argumento que defiende archyl.

Elijas la que elijas: saca los ficheros primero. La pestaña desaparece con el servicio.

Más sobre la mecánica: importar proyectos de Structurizr, LikeC4 e IcePanel, la página de migración desde Structurizr, y una comparativa 2026 de herramientas C4. Si el modelo en sí te resulta nuevo, empieza por el modelo C4 y el architecture drift.