Sheet 01 of 02/Miro import
Systems & graphics engineeringDrawing 25.2 of 25Part 2 of 2
Getting fifty eight boards out of a format that was never meant to leave, and proving they arrived.
Specification / as recorded
Sheet 02 of 02/Import
This is the part that had to work before anything else mattered, because the boards being moved cannot be re-imported freely. Miro encrypts the .rtb backups server side. The REST API returns no content for a large share of items. The clipboard route needs the original board still open in front of you. A board lost in a refactor is lost for good.
So the importer decodes Miro's clipboard format and reads the encrypted backups, resolving assets by resource id across the whole archive set rather than one board at a time. That is what makes a fifty-eight board migration one pass instead of fifty-eight. Of the reference board's 596 widgets, 532 come across intact, 89 percent, covering ink, images, link previews, text, stickies, embeds, connectors and frames. The clipboard route actually carries more than the API does: it includes pen drawings that no Miro endpoint exposes.
Correctness is checked against Miro's own SVG export as an oracle. A clipboard import of the reference board has to reproduce 44 stickies, 12 frames, 47 shapes, 18 connectors, 134 ink paths and 429 text strings. The two formats come out of different Miro code paths, which makes agreeing with both the strongest signal available.
Data safety then became the first rule in the project's documentation, above the performance goals, and it is structural rather than careful. Delete writes a path into a trash sidecar and touches no file. A single confirmed purge is the only code in the app that removes a board. A schema change has to keep reading the old spelling instead of migrating to the new one.
