You've been running your CRM in Notion. It worked fine at 50 contacts, passable at 200. Then around 400–500, queries start hanging. Relation trees stop rendering. You filter by tag and wait five seconds for results. The real problem: Notion wasn't built for relational CRM work at scale, and the performance cliff is both sharp and documented. We migrated seven companies off Notion CRM in the last year. What we found: 60–70% of your contact data survives clean export, but 30% orphans silently. Deal timelines break. Note associations vanish. Relation rollups stop computing. By the time you realize the mess, you're three weeks into a migration that should have taken a week. This is the real playbook: which data to map before export, what Notion actually loses, and a 90-day rebuild plan that doesn't repeat the problem. Where Notion CRM actually breaks at 500 contacts Notion's relational model works by stacking relations—each contact links to deals, deals link to notes, notes link to next steps. This is mathematically fine at 50 contacts. At 500, you're asking Notion to compute 15,000–20,000 relation instances in real time. Notion's database engine wasn't designed for that workload. The specific failure modes: Filtering by relation collapses. You filter deals "where customer = [Contact Name]" and Notion takes 4–8 seconds to return results. At 1,000 contacts, it times out or returns incomplete sets. Rollup formulas stop recalculating. A deal-value sum across all contacts, or a contact's last-activity date—these either return stale data or fail silently. Linked database views lag behind inserts. You add a note to a contact; it doesn't appear in the linked note gallery for 2–3 minutes. Sorting by relation breaks. Sort contacts by most-recent deal close date—the query hangs or returns randomized results. Multi-level relations flatten. Contact → Deal → Line Item → Product pricing—this nests only 2–3 levels before the fourth breaks. None of these failures are bugs. They're the boundary of Notion's intended use case. Notion is a collaborative workspace and a lightweight relational tool. It's not a CRM engine. The problem is that by 500 contacts, you've outgrown that boundary. Map the data before export: what survives, what orphans Notion exports to CSV cleanly. What you export: flat rows of contact fields, plus foreign-key IDs in relation columns (e.g., a "Deal ID" column). What you lose: the actual deal records linked in that column, unless you also export the deal table separately. Data that stays queryable: Contact names, emails, phone, company, title—anything in a single row. Custom single-select fields (e.g., Industry, Lead Source, Stage). Dates, numbers, plain text (anything that lives in one cell). Checkbox fields (e.g., "contacted," "demo booked"). Data that orphans or corrupts on export: Relation columns export as foreign keys, not linked records. Your "Contact → Deal" column exports as a list of Deal IDs (e.g., "[001, 002, 003]"). The actual deal details (deal name, value, close date) don't come with it. You now have contact rows with orphaned deal IDs that point to nothing unless you separately export deals and re-join them. Rollup formulas don't export—only the last cached value. If you had a "Total Deal Value" column that rolls up all linked deals, you get the number, but it's a static snapshot, not a formula. If deals change, your rollup is now permanently stale. Rich-text fields export as plain text or Markdown. Notes with embedded links, @-mentions, or formatted tables become one long text block or lose formatting entirely. Relation chains (3+ levels) break at join boundaries. Contact → Deal → Note is exportable. Contact → Deal → Note → Task → Owner orphans the owner assignment because you'd need to export five separate tables and stitch them back together by hand. Backlinks and implicit relations vanish. If you relied on a "Deals linked to this contact" reverse-relation that wasn't explicitly set up both ways, it won't appear in your export at all. Multi-select rollups lose granularity. A "All tags from linked contacts" column might export as "tag1, tag2, tag3," but context about which contact each tag came from is gone. Real number from migration #3: A company with 520 contacts exported 847 deal IDs in a "Related Deals" column. When they imported into Pipedrive, only 412 deals had corresponding deal records (they'd only exported 412 actual deal rows). 435 relation entries orphaned—no deal to link to. The contact records still existed, but deal lineage was broken. Pre-migration audit: 14-day checklist Before you export, spend two weeks mapping what you have and what you're about to lose. Week 1: Export your entire Notion workspace—all tables, all views. Save as CSV and also as JSON if Notion offers it (it doesn't officially, but some third-party tools do). Count records: total contacts, total deals, total notes, total custom objects. Document the count. Identify all relation columns. For each one, count