An 80-engineer platform group keeps 60 hand-drawn architecture diagrams in a drawing tool and wants a single text model in version control that renders context and container views. Delivery cannot pause for this. Which first step is both useful and reversible?

The sequence

1. Pick the five systems that have external dependencies and write their context level as text. Five small files, an afternoon each, and the output is immediately useful: the context level changes a few times a year, so it will still be true next quarter. Nothing is deleted, so step 1 is reversible by deleting five files.
2. Render it where review already happens. Text diagrams render inline in the major code-review surfaces and in the editor — JetBrains' Markdown support renders PlantUML in the IDE preview with Mermaid available alongside it — so the diagram appears in the pull request rather than in a tool nobody opens. If the rendered diagram is not visible in review, the model will rot exactly as the drawings did.
3. Add the container level for the two systems under active change, and only those. A reference implementation of the C4 model such as Structurizr keeps one model with many views, so the container view reuses the elements already named at the context level instead of redrawing them.
4. Put one rule in the review template: a pull request that adds or removes a container updates the model. This is the step that makes the model live, and it costs about 10 minutes per structural change.
5. Retire drawings one at a time, each after its generated replacement has survived two reviews.

Why the other options fail

• Generate from service discovery and delete the drawings. Attractive, and it produces a true picture of what is running rather than what was intended. It cannot express the thing the drawings were for: planned state, boundaries and why a component exists. Deleting first also removes the rollback. Generated inventory is a complement to the model, not a replacement.
• Port all 60 in a hardening sprint. The classic big-bang. Most of the 60 describe components that churn every few sprints, so a third of the work is stale before the sprint ends, and the group learns the DSL on the diagrams that matter least. There is no reversible intermediate state.
• Commit the exports. It buys history on a binary blob and no diffs, no reuse and no rendering in review. It is the right move only when the goal is purely archival.
• Evaluate four tools first. Reasonable when the choice is expensive to reverse; here the content is perhaps 200 lines of text and converting between model-as-code dialects is mechanical. Three weeks of evaluation to protect an afternoon of rewriting is the wrong trade, and an evaluation with no written content gives the team nothing to evaluate against.

Where reality and the model diverge

At the container level, within weeks. Watch two signals: pull requests that add a deployable without touching the model, and a reviewer asking a question the diagram should have answered. Both are cheap to count and both say the model is drifting.

The point of no return

Deleting the drawing-tool originals. Keep them read-only for at least a quarter after each replacement, and delete per diagram rather than as a batch.

When this is the wrong answer

For a stable system nobody is changing, the drawings are fine and this is work with no payoff. The model-as-code approach earns its cost where structure changes often enough that stale pictures mislead — roughly, where a container is added or removed more than a few times a year.