Test migration before committing
Before migrating any tool, test the destination by importing 20-50 representative items and examining every imported item in detail for formatting survival, metadata preservation, and link integrity.
When This Fires
- Before any tool migration, after selecting the destination tool
- Before starting Run old and new tools in parallel for 2-4 weeks during…'s parallel period
- When evaluating whether a migration is feasible at all
- Complements Choose open portable formats (Markdown, CSV, JSON) over… (open format preference) with the verification that open formats actually transfer correctly
Common Failure Mode
Untested bulk migration: exporting 3,000 notes, importing them all at once, and discovering two weeks later that all internal links are broken. The fix requires re-importing or manually repairing 3,000 items. A 50-item test would have caught the link issue in 30 minutes.
The Protocol
(1) Select 20-50 items from your current tool that represent the diversity of your data: different formatting styles, metadata patterns, link types, and content types. (2) Export and import these items into the destination tool. (3) Examine every imported item against the original. Check: Formatting — do headings, lists, bold/italic, code blocks, and tables reproduce correctly? Metadata — do tags, dates, custom fields, and properties transfer? Links — do internal links point to correct targets? Do external URLs work? (4) Document any failures. Categorize them: Fixable (can be batch-corrected post-migration) vs. Blocking (fundamental incompatibility that can't be fixed). (5) If blocking failures exist → either find an alternative migration path or reconsider the tool choice. If only fixable failures → proceed to Run old and new tools in parallel for 2-4 weeks during…'s parallel period, knowing what cleanup will be needed.