Architecture transitions and roadmaps
Change is the default state of a working system. NeoArc treats as-is and to-be as two versions of the same model, so the migration plan is a property of the graph, not a slide deck.
Most organisations draw transitions as before-and-after diagrams that bear no formal relationship to each other. The as-is diagram lives in one file. The to-be diagram lives in another. Deprecation is tracked in a spreadsheet. By the time the migration runs, the as-is diagram is already stale and the to-be diagram has become speculative. Nobody is quite sure which version describes the state of the system on any given day.
NeoArc treats a transition as a typed change over the same model. The to-be shape references the as-is shape by entity. Every migration step is an edge. Deprecation is a property on the as-is entity, not a note in a document that lives somewhere else.
Transitions and turnover are the same problem over different timescales. If you have not read the companion piece on human turnover, see architecture that survives team turnover.
The cost of a senior leaving is not their salary. It is the months of knowledge transfer, the slow re-discovery of design decisions, and the gradual loss of context about why things are the way they are.