Notion works beautifully until it doesn't. You build a contact database, layer in custom fields, link everything—and it hums along for 200 contacts, 300 contacts, even 400. Then you hit 500, you add a second user, filters slow to a crawl, and you realize Notion was never meant to be your CRM. The pivot to a real platform feels inevitable. But the data doesn't move cleanly. Nine specific field types orphan, duplicate, or truncate. The ones you don't notice until two months in, when your team is building on incomplete records and you're debugging why half your custom data vanished. This playbook documents exactly which fields break, how to audit before you migrate, and what to do if the data diverges on the other side. The nine fields that routinely orphan Every Notion-to-production CRM migration has the same weak points. They're not bugs—they're architectural mismatches between Notion's schema and how real CRMs model contact data. 1. Relation fields (multi-select linked records) Notion relations are bidirectional by default. A contact links to 3 deals, and those deals link back to the contact. When you export, only one direction comes through. You get contact → deal, but the reverse link is gone or appears as text, not a live relationship. Production CRMs store this as a single contact ID foreign key repeated across deal records. If you're not deliberately mapping it during export, you'll reconstruct only half the graph. 2. Rollup fields Rollups (sums, counts, concatenations of linked data) don't export. They're computed on the fly in Notion. When you land in a new platform, they're empty cells. If you're tracking "total deals by contact" or "sum of contract values", you need to rebuild that logic in the destination system's formula or automation layer before you migrate—not after. 3. Formula fields with conditional logic Notion formulas look portable. They're not. Different CRMs have different formula syntax, function libraries, and type coercion rules. A formula like if(dateBetween(finish, today(), 30 days), "urgent", "standard") won't parse in most platforms. You can export the computed values, but the logic stays behind. 4. Multi-line text with formatting (rich text) When you copy rich text (bold, links, inline code) from Notion, it comes through as HTML, Markdown, or plain text—depending on your export method. Most CRM imports flatten it to plain text. Links die. Formatting vanishes. Your notes look like a wall of gray. 5. Attachments with metadata Notion attachment fields can store multiple files per record, plus filename, size, and upload date. When you export, you get URLs or filenames only. The URLs work for 7–30 days if they're time-signed, then expire. Metadata (upload date, who added it) is lost. If you need an audit trail, you're rebuilding it manually. 6. Database templates and automation Notion database templates (which auto-fill fields when you create a new contact) don't export. Button-triggered automations don't. Anything procedural lives in Notion's UI, not in the data. You'll need to recreate these workflows in your new platform's automation engine before your team notices they're gone. 7. People/user fields with assignment metadata When a contact is assigned to "Alice", Notion stores Alice's user ID and avatar. Most CRMs expect a plain string (the person's name or email). The mapping is simple if your new system has the same user list, but metadata (notification history, assignment timestamp) is lost. 8. Checkbox fields with null/false ambiguity Notion checkboxes are true/false, but an empty cell looks the same as false. When you export, "no value" and "unchecked" both come through as FALSE or blank. In downstream systems, this ambiguity can mean "status unknown" gets treated as "confirmed no", silently corrupting your data. 9. Single-select with custom colors and sort order Notion select options have custom colors and a manual sort order. Only the text exports. If you're relying on color or sequence for workflow logic (e.g., a kanban board with stage colors), you rebuild those visual cues manually. The data is there; the context isn't. Pre-migration audit: the checklist Before you move a single row, audit your Notion database to catch these nine field types in context. Export a sample batch (50 records). Pick a variety: old contacts, recent ones, heavily linked ones, sparse ones. Run them through your destination system's import. Watch what breaks. This is your canary. Map every relation field. For each linked record type (deals, contracts, projects), write down: (a) which direction it flows (contact → deal or deal → contact), (b) whether both directions matter to your workflows, (c) how you'll reconstruct it in the new system (one-to-many foreign key, junction table, or API sync after import). List all rollup, formula, and template fields. For each, decide: export the computed value as static data, or rebuild the logic in the new platform? Write down the logic in plain English. Example