14-Step AI-Native Migration Process

TL;DR: Ready to execute? Here’s the playbook — 14 steps from first folder to final vault. Each step has one job, one reason, and one check. No fluff.

Before you start

These 14 steps assume you’ve read the Migration Plan Template Walkthrough and have written your own Migration Plan.

Core rule throughout: copy, never move. The old tree stays untouched until step 13.

Step 0: Create a validation checklist

What: Before you copy a single file, create a validation checklist. This is your migration’s test suite — a list of checks that prove every file is accounted for, every access boundary is respected, and nothing got lost.

Why: Without a checklist, you’ll wonder whether something was missed. With it, you prove completeness.

How: Use the Validation Checklist template from the migration toolkit. Ask your AI to customize it for your company.

If you use the template, you don’t really need the rest of this article. Just ask your AI to execute the plan phase by phase. Only remember that the longer an AI conversation is, the more prone to mistakes it is. So when the step becomes too big - especially Step 5, the file copy or Step 6, the creation of relationships, you should request the AI to make smaller plans for it, focusing on one part of the step.

Step 1: Create reorganization root

What: Create a new folder alongside your current company folder. Make sure all the folders you want to move and merge are there. Name it [Company Name] Reorganization/.

Why: The root is a staging area. Nothing changes in your live folders. If a step goes wrong, you lose nothing.

Check: The root exists, your old folders are untouched, and nothing has been migrated yet.

Step 2: Create migration control folder

What: Create 00-Migration Control/ inside the reorganization root. This folder lives outside the operational vaults — it holds planning and validation documents, not company data.

What goes in it:

• AI Migration Plan.md — your filled-in template
• Folder Mapping.md — source-to-destination mapping table
• Validation Checklist.md — the checklist from the template
• README.md — notes for anyone running the migration
• convert — the document conversion CLI
• Duplicate Reports/ — hash-based duplicate analysis
• Migration Logs/ — log of every copy and conversion

Why: Separating migration management from operational data keeps the vault clean. When migration is done, 00-Migration Control/ becomes a reference archive.

Rule reference: Rules 3 (numbered prefixes) and 6 (design for reorg).

Step 3: Create draft folder mapping

What: Before creating any vault folders, map every source folder to its destination. Use the mapping table from the template.

Why: The mapping is your single source of truth. It catches scope questions before you start copying. When a team member asks “where does the budget go?” you point to the map.

Actions:

• copy — straight copy, no conversion
• convert — binary to markdown via ./convert
• reference — leave in place, note the location
• manual review — needs human decision

Check: Every source folder has a destination and an action.

Step 4: Create vault folders

What: Create the folder structure from the template’s Target Folder Tree section. Start with the three vaults, then build the subfolders under each.

01-Main Vault/
  01-Products/[Product A]/Product Notes/
  01-Products/[Product A]/Launch/
  ...
02-Legal Vault/
  Contracts/
  Signed Agreements/
  ...
03-HR and GDPR Vault/
  Employment Documents/
  ...

Why: Build the shelves before you move the books. Empty folders confirm the structure works before any files are in it.

Rule reference: Rules 1 (path tells story), 2 (deep paths), 3 (numbered prefixes), 4 (access-aware vaults).

Step 5: Copy files into new structure

What: Follow the folder mapping. For each source:

• copy — straight copy to destination
• convert — run ./convert source.docx -o destination.md
• reference — create a .md note with the original location
• manual review — skip, flag for later

Why: Copy-first is the safety net. The old tree still works. Nobody loses access to anything. You can iterate the new structure without pressure.

Tool: ./convert handles .docx, .doc, .xls, .xlsx, .pptx → .md.

Check: All copy and convert actions complete. Log any failures or unexpected files.

Rule reference: Rule 6 (design for reorg).

This is by far the longest step — use the example Copy Plan from the repo.

Step 6: Create relationship notes

What: One .md note per important company and individual in 02-Relationships/. Include historical/inactive relationships — mark their status in the note, don’t delete them.

Why: A markdown CRM is searchable, backlinkable, and never locked behind a subscription. Every company gets a note; every person gets a note. Backlinks connect them.

Skip if: Your business doesn’t track relationships this way (manufacturing, solo consulting).

Template reference: Relationship Model for CRM section.

Step 7: Create investor notes

What: Same pattern as relationships, but in 03-Investors/. Investor company and individual notes, with light frontmatter for pipeline stage, last contact, next action.

Why: Investor workflows need their own context — deal stages, data room access, contact cadence. Separate from general relationships.

Skip if: No active investors or fundraising.

Template reference: Investor Model section.

Step 8: Add backlinks

What: Link related files with [[File Name]] syntax. Connect companies → people → meetings → products → decisions.

Examples:

• A company note links to its contacts: [[Jane Smith]]
• A meeting note links to the product discussed: [[Stellar Navigation Platform]]
• A launch plan links to the approval: [[Q3 Launch Approval]]

Why: Backlinks turn a folder tree into a knowledge web. The AI can navigate from a company note to every meeting, decision, and document connected to it — without searching.

Rule reference: Article 01 vision section (backlinks + graph view).

Step 9: Handle exact duplicates

What: Run hash-based duplicate detection on the new vault. Remove only exact duplicates (same hash, same content). Keep near-duplicates and different versions.

Why: Exact duplicates are safe to remove — they’re the same file in two places. Near-duplicates might be intentional (drafts, revisions). Don’t risk data loss.

Check: Duplicate report saved to 00-Migration Control/Duplicate Reports/. Only exact-match rows removed. Re-run after step 10.

Step 10: Validate completeness

What: Compare original vs. reorganized file count. Review the duplicate report. Manually check skipped folders and manual review items.

Check:

• File counts match within expected bounds (some files may be merged or split)
• All manual review items have a decision
• No source folder was accidentally skipped
• All high-priority files (legal, HR, product) are present

Template reference: Validation Checklist section.

Step 11: Review access boundaries

What: Confirm every file is in the right vault. Walk through the access model and spot-check files in each vault.

Key boundary checks:

• Signed contracts → Legal Vault, not Main Vault
• Privacy policies → Product folders (not Legal — they’re product docs)
• Investor files → Investors, not general Relationships
• HR/personal data → HR and GDPR Vault
• Budgets → in context (product, investor, grant) — no separate finance vault

Why: An access boundary mistake means someone sees something they shouldn’t. This step is the firewall.

Rule reference: Rule 4 (access-aware vaults).

Step 12: Approve final structure

What: Present the new vault to stakeholders. Walk through the validation checklist. Get explicit sign-off.

Who needs to approve:

• Team lead (operational correctness)
• Legal/compliance (boundary correctness)
• Decision-maker (budget, time, scope)

Why: The next two steps are irreversible — deleting the old tree and renaming the root. Approval is the last chance to catch issues.

Check: Written approval (email, signed checklist, or meeting notes) saved to 00-Migration Control/.

Step 13: Delete old folder tree

What: Delete the original company folder tree. Keep backups for a reasonable period (30 days recommended).

Why: The old tree was your safety net during migration. Now the new vault is the source of truth. Keeping both creates confusion and duplicate maintenance.

Only after: Step 12 approval. Not before.

Step 14: Rename reorganization root

What: Rename [Company Name] Reorganization/ to your final vault name — e.g., Stellar Robotics Vault/.

Why: The “Reorganization” label was temporary. The final name is what your team and AI will use for years. Choose a name that reflects the vault’s role, not the migration project.

Done. The vault is live.

Summary

Total: roughly 2-5 days for a small company, 1-3 weeks for an enterprise with complex access boundaries.

What’s next

Migration done. Now make it stick:

• Train Your Team — teach them the new system.
• Markdown CRM — turn your folder into a sales engine.
• Kill Word: Markdown to PDF with Pandoc and TeX — create branded documents from your files.

Markdown your next move. By Charles Henri Gayot.