You've built your contact list in Notion. It works fine at 100, 200, even 350 contacts. Then somewhere between contact 450 and 500, queries start to hang. Relationships feel sluggish. And when you finally export to migrate—thinking you've got a clean handoff to Pipedrive or Orin—you discover nine field types didn't make the jump. This isn't a failure of your process. It's a hard limit in Notion's architecture. Notion's database wasn't built for high-volume CRM work. It was built for team wikis and project tracking. The contact wall exists because relational databases, rollups, and formulas degrade under query load once you cross 500 rows with active syncing. Here are the nine field types that orphan on export, which ones matter most to your business, and a 30-day calendar to move without losing a single relationship or activity log. The nine fields that die on Notion export When you export a Notion database with 500+ contacts, these field types either truncate, flatten, or disappear entirely: Relation fields (linked records) Notion flattens these to text or IDs. If you've linked contacts to deals, projects, or companies, you get a comma-separated ID dump instead of usable relationship data. On import into Orin or Pipedrive, you'll need to map these manually or rebuild the relationships in bulk. Rollup fields Any field that sums, counts, or aggregates linked records returns only the last computed value—not the formula itself. If you tracked "total deals won" or "contact value," the number freezes at export and won't recalculate in the new system. Formula fields Notion exports formulas as static text or blank. A formula like if(Status = "Closed", Value, 0) becomes a dead field. You'll need to recreate the logic in your destination platform. Button fields Completely stripped. Any automation button you've wired (Zapier, Make, Slack integration) leaves no trace. You lose audit trails and automation metadata. Template fields Exported as text only. If you used templates to auto-generate email subjects or call scripts based on contact type, those disappear. You rebuild them cold in the new system. Activity/timeline fields (via database connections) Notion syncs activity logs tied to contacts very slowly after 300+ rows. On export, you get only the latest activity date—not the full log. Months of calling and email history can vanish if it wasn't backed up separately. Synced database fields If you've synced Notion contacts to an external tool (Slack, Gmail, Zapier), those sync blocks don't export. The one-way sync thread is severed; you start fresh. Conditional visibility rules and database filters All view filters and conditional hiding logic is lost. Exported data is flat. Contacts hidden by rule reappear as records in the CSV, creating duplicates or confusion on import. Custom metadata and tags (in rollup or multi-select linked to external source) If you've tagged contacts using a linked multi-select (e.g., a "Lead Sources" table), the export returns only raw IDs, not the human-readable tag names. Re-mapping takes hours. The core issue: Notion exports the current state of data, not the structure or logic. If your CRM relies on formulas, relationships, or activity timelines to work, you're exporting a corpse, not a working system. Which fields actually matter for your business Not all nine losses are equal. Some you can live without for a few days; others cost you revenue. Critical (migrate first): Relation fields, activity logs, and custom tags. These are your deal links, call history, and lead source attribution. Without them, your new CRM is a dumb contact list for seven days while you rebuild. Important (migrate within 72 hours): Rollups and formulas tied to deal value, pipeline stage, or contact scoring. If you use these to filter or report, losing them creates a forecast blind spot. Nice-to-have (migrate in week two): Buttons, templates, and synced database links. These speed up workflows but aren't deal-blocking if they're gone for a week. The export doesn't fail because Notion is malicious—it fails because Notion's database model was never designed for this use case. When you export, you're asking a wiki tool to behave like a CRM. It can't. The 30-day migration calendar Days 1–3: Audit and document List every field in your Notion database. Note type (relation, rollup, formula, etc.) and whether it's deal-critical, reporting-only, or operational fluff. Export a test batch of 50 contacts to see which fields truncate or disappear. Document the CRM field mapping (your Notion structure → destination system structure). Orin and Pipedrive field names differ; write them down. Identify orphaned activity logs. If you've tracked calls, emails, or notes in Notion's timeline, export that separately to a spreadsheet before the main export. Backup: Download your entire Notion database as CSV and PDF. You'll need this as a reference during migration. Days 4–10: Rebuild destination structure In your destination CRM (Orin or