draw.io version history
By default a migrated diagram arrives as a single current version, authored by whoever ran the migration. Every previous edit, and every previous author, is gone from the new diagram.
That is often fine. Where it is not, the behaviour version picker is the only way to change it, and it has to be chosen before the run.
#The two outcomes
Behaviour version | What your diagrams look like afterwards |
|---|---|
v1.0.0 Standard migration | One version per diagram, dated today, authored by whoever ran the migration. Fast. |
v1.1.0 Diagram version history | Every version replayed in order, each keeping its original author and edit date. Substantially slower. |
There is no separate checkbox for this. Version history and original authorship come only from the behaviour version picker, and the picker defaults to v1.0.0.
#When it is worth the time
Regulated or audited content, where who changed a diagram and when is part of the record.
Long-lived architecture diagrams whose history is genuinely consulted.
Any estate where the diagram history was a reason for choosing the old app.
It is not worth it for diagrams that are regenerated frequently, or for a pilot where you are testing the conversion rather than the history.
#Pinned revisions
When a macro pins a specific revision, that historical snapshot is migrated rather than the current drawing. When no revision is pinned, the live copy draw.io keeps wins over the attachment file.
#A few things that catch people out
Replaying history means fetching every version of every diagram. On a large estate this is the single biggest driver of run time.
You cannot add history afterwards by repairing. It means running again at the higher behaviour version.
The version you used is stamped into the results and the log, so a log tells you which behaviour produced a given estate.
#Related
History is a version choice, made up front.
