How the draw.io migrator finds your drawings
A draw.io macro on a page does not contain the drawing. It points at it, and where it points depends on the app version, how the diagram was created, and whether it lives on this page at all.
Capable tries five places in a fixed order, and stops at the first one that yields a real drawing.
#The order it tries
#Why raw bytes matter
Attachments are read as raw bytes rather than as text. Drawings saved inside a PNG or SVG preview carry their XML in the file's metadata, and reading the file as text destroys it. Reading bytes is what recovers those correctly, and it is the single biggest cause of failure when it goes wrong.
#Diagrams on another page
If the macro points at a diagram stored elsewhere, Capable follows the macro's own page reference first. Only if that is missing does it search the site for a page holding an attachment with that name.
Two safety rules on that search. First, a diagram still called "Untitled Diagram" is never searched for site-wide, because the name is too generic to trust. Second, if the same name exists on several pages, Capable refuses to guess and reports the ambiguity with the candidate pages named.
#Data Center imports
Macros buried inside Data Center import wrappers are found and converted too, which is what makes a Server-to-Cloud estate migratable without unpicking the wrappers first.
#A few things that catch people out
Verification substitutes a stand-in drawing and never downloads the real file, so a clean dry run does not prove these will migrate.
A macro that was never saved, or whose attachment was deleted, is reported as unsupported rather than failed: there is genuinely nothing to migrate.
Leftover Gliffy files from an old bulk import are skipped in favour of the converted draw.io file. If only the Gliffy file remains, the macro is left alone.
#Related
Find the drawing. Everything else is easy.
