Run old and new tools in parallel for 2-4 weeks during migration — new data to new tool, old data from old tool, end only when daily needs are confirmed

Why This Is a Rule

Cold-cut tool migration — switching entirely on day one — risks discovering critical gaps after you've already abandoned the old tool. The new tool might handle 95% of your needs but fail on the 5% you discover in week 2 when a specific use case arises. By then, the old tool has been decommissioned, and you're either stuck with the gap or facing emergency restoration.

Parallel running eliminates this risk by maintaining both tools simultaneously during a validation period. New data goes to the new tool (testing its capture and creation capabilities with real work). Old data is accessed from the old tool (maintaining continuity for ongoing projects and reference retrieval). This dual operation reveals whether the new tool handles your actual daily needs — not just the use cases you imagined during evaluation, but the full range of real-world interactions including edge cases.

The 2-4 week duration ensures you encounter most recurring use cases (weekly reports, monthly reviews, various project types) while keeping the parallel overhead bounded. Shorter than 2 weeks might miss weekly workflows; longer than 4 weeks creates excessive dual-system maintenance.

When This Fires

• When migrating from one tool to another for any critical function
• After Test migration before committing: import 20-50 representative items and check every one for formatting, metadata, and link integrity's import test confirms the new tool can handle your data format
• When the stakes of a failed migration are high (years of data, established workflows)
• Complements Test migration before committing: import 20-50 representative items and check every one for formatting, metadata, and link integrity (pre-migration import test) and Migrate active working set (last 90 days) first and verify every item — archive migration comes after active data is confirmed clean (active-set-first migration) with the validation period

Common Failure Mode

Day-one cutover: "I'm switching to Obsidian today! Goodbye Notion!" Week 2: "Wait, I need the database views Obsidian doesn't have." You've already stopped using Notion, broken your workflows, and now face either adapting to the gap or a painful reverse migration.

The Protocol

(1) After completing Test migration before committing: import 20-50 representative items and check every one for formatting, metadata, and link integrity's import test, begin the parallel period. (2) Route all new data to the new tool. Create new notes, capture new tasks, start new projects in the new system. (3) Continue accessing old data from the old tool. Don't migrate everything at once — read from old, write to new. (4) During the parallel period, note any friction: "I can't do X in the new tool," "The workflow for Y is significantly slower," "Z feature is missing." (5) After 2-4 weeks, evaluate: can the new tool handle 100% of your daily needs? If yes → decommission the old tool, begin archival data migration (Migrate active working set (last 90 days) first and verify every item — archive migration comes after active data is confirmed clean). If no → either accept the trade-offs, find workarounds, or abort the migration and stay with the old tool. A clear-eyed abort is better than a forced commitment to an inadequate tool.