Notion gets you started. But when your contact database hits 300–400 records, filters slow, linked records lag, and rollups compute on page load. Moving to a real CRM feels overdue—except the thought of losing relationship context, deal history, and all those rollup calculations stops you cold. Here's the truth: most of that data does survive migration. But only if you map it deliberately. Linked records become foreign keys. Rollups become calculated fields. Formulas either get ported or replaced with native platform logic. And orphaned contacts happen only if you skip the deduplication step. This guide maps the exact survival rate of every Notion CRM field type, the remapping sequence to preserve relationship depth, and the dedup playbook that keeps your deal history clean. What actually survives: A field-by-field breakdown Not all Notion field types port equally. Some migrate verbatim. Others need translation. A few require manual rebuild. Fields that survive intact Text, email, phone, URL: These are atomic. They move as-is. No translation needed. Single select and multi-select: Notion's tags become dropdown or multi-select in Orin. Tags carry over if you map the select options first. Number, currency, percentage: Direct port. No loss. Dates and timestamps: Full fidelity, including time zones if you've used them. Checkboxes: Become Boolean fields or single-select (done / pending). Fields that require remapping Linked records. Notion's linked records are the spine of your CRM. A Contact links to Deals, which link to Projects and Activities. On export, these become foreign key IDs—raw numbers with no human readability. The survival rule: Linked records survive as data, but the visual relationship interface does not. You must rebuild the join logic in your destination system. When you export a Notion database with linked records, you get a CSV with two columns: the main record and a JSON array of linked record IDs. Example: Contact: "Alice Smith" (ID: rec_12345) Linked Deals: ["rec_67890", "rec_11111"] Orin's CRM ingests this natively. The importer detects foreign key patterns and auto-creates the relationships, provided both tables are being imported in the same batch. Rollups. These are calculations across linked records. Example: "sum of deal values for this contact" or "count of open tasks linked to this deal." Rollups do not survive export. The export gives you the current computed value, but not the formula that generated it. You have two choices: Preserve as snapshot: Export the rollup result as a static number field. Useful for historical reporting, but it doesn't update when linked records change. Rebuild as native logic: Recreate the calculation using Orin's AI-assisted field mapping or manual aggregation rules. This is the right move for active rollups that must stay current. Formulas. Like rollups, formulas export as values, not logic. A formula that concatenates first and last name, or calculates days since last contact, ships as read-only text. The fix: Identify critical formulas before migration and rebuild them in Orin using workflow automations or native calculated fields. Fields that orphan without a plan Rich text and attachments: Export as plain text or links. Formatting and file embeds don't survive. Collaborators and assigned users: Names survive; team assignments must be remapped manually if your Orin team structure differs. Button fields and integrations: Notion buttons that trigger Zapier or other actions vanish. Rebuild these as Orin automations. The deduplication sequence: Before you import anything Merging Notion with Orin often means reconciling duplicates. A contact might exist in both systems under slightly different names ("Alice Smith" vs "A. Smith"). Left unmerged, you fragment your deal history. Do this before importing: Export both datasets as CSVs. If you're moving from standalone Notion to Orin and also importing existing Orin contacts, pull both lists. Sort and flag near-matches. Use a spreadsheet tool or Python script to find records within 85% text similarity on email + name. Common duplicates: domain typos (gmail.com vs gmai.com), name variations (Robert vs Rob). Decide: merge or keep separate. For each duplicate pair, choose one as the primary record. Tag the secondary as "merge candidate." Consolidate notes and linked records before import. If Alice Smith appears twice with different deal links, manually combine the deal list in one record. Update the CSV to reflect consolidated linked records. Import only the primary records. Drop the marked duplicates from your CSV before upload. This prevents the "hello again" moment where you discover you've imported the same contact twice with orphaned deal histories. Preserving relationship context: The field mapping playbook Relationship depth isn't just about linked records—it's about the metadata that goes with them. A deal linked to a contact is useless if you've lost the engagement history, the opportunity source, or the