Verify data portability before committing: actually export, actually import in another tool, actually check for structure and metadata loss
Before committing to a new tool, verify it stores data in exportable open formats by actually performing an export and checking whether another tool can import it without significant loss of structure or metadata.
Why This Is a Rule
"Supports export" on a feature page and "actually exports your data cleanly" are different claims. Many tools advertise export capability that produces: HTML files with tool-specific formatting that no other tool can read. CSV exports with missing fields. JSON dumps with proprietary schemas. Markdown exports that strip all metadata and break all links. The export feature exists but produces data that's practically non-portable.
The only way to verify portability is to actually test it: create sample data in the tool, export it, import it into a different tool, and examine the result. Does the formatting survive? Are the metadata fields preserved? Do internal links still work? This 30-minute test before commitment prevents discovering the answer after 2 years of data accumulation, when the export failure means your data is trapped.
This is Test migration before committing: import 20-50 representative items and check every one for formatting, metadata, and link integrity's migration test applied at the selection stage rather than the migration stage. Verifying portability before you commit costs minutes. Discovering non-portability after years of use costs weeks of manual migration or permanent lock-in.
When This Fires
- During tool evaluation, after the tool meets your requirements (Pick a tool with 5 minimum requirements, select the first that meets them, commit for 90 days — satisfice, don't maximize) but before committing
- When Choose open portable formats (Markdown, CSV, JSON) over proprietary — migration cost compounds daily with every new piece of locked-in data's open-format preference needs empirical verification for a specific tool
- When a tool claims "export support" on its feature page
- Complements Choose open portable formats (Markdown, CSV, JSON) over proprietary — migration cost compounds daily with every new piece of locked-in data (open format preference) and Test migration before committing: import 20-50 representative items and check every one for formatting, metadata, and link integrity (migration testing) with the pre-commitment verification
Common Failure Mode
Feature-page trust: reading "Export to Markdown/CSV/JSON" on the tool's website and assuming it works well. The feature exists; the quality of the export is unknown until tested. A Markdown export that strips all YAML frontmatter, removes link targets, and converts tables into unintelligible plain text is technically "Markdown export" but practically useless.
The Protocol
(1) Create 10-20 representative items in the tool: notes with various formatting, items with metadata/tags, items with internal links, items with embedded content. (2) Export using every available export format. (3) Import the exported data into at least one other tool (ideally one you'd consider as a replacement). (4) Examine every imported item: Formatting — do headings, lists, bold, and tables survive? Metadata — are tags, dates, and properties present? Links — do internal references resolve? Content — is anything missing or garbled? (5) Grade: Clean export (all items import with minimal loss) → tool passes portability check. Lossy export (items import but with formatting/metadata loss) → acceptable if losses are fixable via script. Non-portable export (items are unusable after import) → tool fails portability check. Reconsider commitment per Choose open portable formats (Markdown, CSV, JSON) over proprietary — migration cost compounds daily with every new piece of locked-in data.