Move your Structurizr workspace to Modudraft

Import a workspace and keep its levels, its documentation and its decisions. You can do it in the web app with a file, or with an agent through the MCP server, and import again later to update the diagram in place. You can also export it back to DSL or JSON.

Why move

Structurizr's cloud service closed on 30 September 2026. Your model does not have to go with it. A workspace comes over as one diagram: the software systems, containers and components as nested levels, the relationships as arrows, the documentation and architecture decisions as notes, the dynamic views as sequences and the deployment model as the Cloud tab.

What to export

• From the Structurizr cloud service: export the workspace as JSON. The JSON keeps the layouts you arranged by hand, so the diagram opens with your positions.
• From Structurizr Lite, the CLI, on-premises or vNext: take the folder with workspace.dsl. If Structurizr Lite saved layouts in a workspace.json next to it, include that file too: its positions are used.

The folder matters when the workspace uses !include, !docs or !adrs, because those files are read from it.

Import on the web

Open a diagram, then Import in the toolbar, then Open a file…. Choose one of:

• a .dsl file;
• a Structurizr .json file;
• a .zip of the workspace folder. Use the zip when the workspace uses !include, !docs or !adrs, or extends another workspace file.

A lone .dsl cannot read other files. Its !include, !docs, !adrs and workspace extends lines are left out and listed in the report, and the rest is imported.

The import replaces the open diagram. If the diagram is not empty you are asked "Replace current diagram?" first. The import is one undo step, and it is refused on a diagram that is locked or view only. Web import never merges with what was there; to update a diagram in place, use the MCP server (below).

When it finishes, an import report opens with Imported, plus Not imported and Warnings when there is something to list:

• Imported: counts of elements, relationships, groups, sequences, cloud resources, documentation sections and decisions.
• Not imported: what was skipped (see What is not imported).
• Warnings: things to check, such as an unknown colour, a skipped dynamic-view step whose elements are not components, or an unsupported statement.

Use Copy report to keep it.

With an agent (MCP)

Ask your agent to call import_file on workspace.dsl (or a Structurizr workspace.json), or import_directory on the folder. For a workspace.dsl, the files it uses are read from its folder. Set up the MCP server first.

Importing the same workspace again updates the diagram in place:

• Elements are matched by their Structurizr names, so matched items keep their position and pin.
• New elements are added, and elements removed from the workspace are removed with their arrows, unless a DB table, API endpoint or task is attached to them; those are kept and listed in the response.
• Items you made by hand inside a removed element are moved up one level, not deleted.
• Renaming a software system or a container gives it, and everything inside it, a new name. Its contents are imported again as new items, with fresh positions, and the old ones are removed.
• The documentation and decisions block in the Notes is replaced, not added twice.

You can import several workspaces into one diagram: each keeps its own items, sequences and notes block, and a re-import of one never touches another. A diagram made by importing a workspace on the web is picked up by the first import_file of the same workspace: when the workspace matches (the same entry file and most element names), its items are matched rather than added a second time. A web import of a different workspace is left alone, the new one is imported beside it, and a warning says so.

To get a warning when the workspace and the diagram drift apart, add workspace.dsl to the sources in modudraft.json, as described on the CI drift check page. The tools that watch a project track the workspace.dsl file itself, not the files it includes; after editing an included file, run the sync or the CI check, which read the whole workspace. sync_project and the CI check do not report a change to only the documentation, decisions or dynamic views as drift.

What maps to what

Scroll sideways to see the whole table.

What is not imported

The report lists these under Not imported or Warnings:

• Filtered, custom, image and deployment views. The deployment model itself is imported, as the Cloud tab.
• Element styles: colours, shapes and icons. Components keep the look of their tool. Group and relationship colours are the exception, and are kept. Themes are not imported either.
• !script, !plugin and custom importers.
• Includes and workspace extends that point to a URL: remote files are not fetched, and the report lists each one under Warnings.
• Relationships between deployment elements.
• Images in documentation. The text is imported.
• Files in a zip that are not a type the import reads (.dsl, .json, Markdown, AsciiDoc and text files).

The system landscape, system context, container and component views are not imported as views either. They are replaced by the levels (see Levels and views); only their positions are used.

Limits

• Zip upload: 20 MB packed, 50 MB unpacked, 2,000 files.
• A single file on the web: 5 MB.
• Size of the model: 5,000 elements.
• With an agent: the entry file may be up to 2 MB, or up to 20 MB for a Structurizr JSON; the files it includes count toward the 50 MB total.
• The notes hold 100,000 characters. A documentation or decision section that does not fit is left out and listed in the report.

Paths in !include, !docs and !adrs must stay inside the workspace folder.

Levels and views

In Structurizr a view is a picture of the model: you decide what a diagram shows with include * and keep one view per picture. In Modudraft the model is the diagram, and the inside of each component is a level you open. Open a software system to see its containers, and a container to see its components. There is no separate view to keep up to date.

The arrows that an include * context view draws between systems are the implied arrows here: they are computed from the real arrows below, so they never go out of date. Read how levels, implied arrows and the C4 look work on the Levels and C4 page.

Export back to Structurizr

Moving in does not lock you in. You can write the diagram back out as a Structurizr workspace, so your DSL can live in git, be edited visually in Modudraft and be written back when you are done.

On the web

Open the diagram, then Export in the toolbar, and under Other choose Structurizr DSL or Structurizr JSON. A summary opens with Exported counts, plus Not exported and Changed on export when there is something to list. Download saves workspace.dsl or workspace.json, and Copy puts the text on the clipboard.

With an agent (MCP)

Ask your agent to call export with the diagram and a format of structurizr_dsl or structurizr_json. Without an output_path it returns the workspace text and the summary. With an output_path it writes the file inside your project folders (it will not replace an existing file unless you pass overwrite: true) and returns the path and the summary. See the MCP docs.

DSL or JSON

• DSL has the model (people, software systems, containers, components, groups, relationships, the Cloud tab as deployment), the views (system landscape, container and component views, a dynamic view per sequence) and colour styles. It has no positions: the views use automatic layout.
• JSON has the same, plus the layouts (the positions you arranged) and the Notes tab as the workspace's documentation. Choose JSON when you want the picture to open the way you drew it.

What is not exported

The summary lists what has no Structurizr equivalent under Not exported. The main cases:

• The DB schema, API and Network tabs, and data flows: they are counted (for example "3 DB tables") and left out.
• Sticky notes, step markers and arrow shapes on the canvas, and tool logos.
• Architecture tabs other than the one exported.
• Boundaries with no components inside; a group colour or arrow colour that is not a hex colour.
• Arrows Structurizr cannot express: to a boundary, a note or a marker, to the item itself, between an item and what is inside it, or a second arrow with the same ends and label.
• Sequence fragments (loop, alt, opt, par), notes and messages that do not connect two components, and messages to the same lane.
• Cloud resource settings beyond technology, description and instances; a component that runs on a resource that no longer exists.
• The Notes tab in DSL. It is written to JSON only.

Things that are exported but changed are listed under Changed on export: a component whose kind does not fit its place (a container at the top level is exported as a software system), items more than two levels deep (exported as components of their container), duplicate names in one scope (the copy is renamed), a component without a name (exported as "Unnamed"), a URL that is not absolute (exported as a property), nested boundaries (the member is exported in the innermost group only), a sequence message that needed a relationship Structurizr requires (one is added), and create, destroy or async messages (exported as plain steps).

Implied arrows

Only the arrows you drew are exported as relationships. In both formats Structurizr shows the arrows between the levels above: in the DSL Structurizr works them out itself, and the JSON includes them as Structurizr's derived relationships, linked to the arrow they come from.

Round trip

Importing the exported DSL gives back the same components (names, levels, C4 kinds, descriptions and technology), the same drawn arrows (label and technology), the same groups and the same sequences. The JSON also brings back the positions (rounded to whole numbers) and the notes. Tool logos and the tabs listed above are not part of the round trip.