Migrate from Apollo ERP to Twenty CRM

Apollo person records map 1:1 to Twenty People. Email, phone, job title, and name fields translate directly. Apollo's association labels (which contact belongs to which company) require resolution — if a contact has multiple companies, we map the most-recently-modified company as the primary companyId in Twenty, then surface the other associations as a custom relation or note.

Apollo company records map to Twenty Companies with direct field translation for name, domain, industry, employee count, and annual revenue. Parent-child company hierarchies in Apollo (if configured) map to Twenty's company relation field — the parent company must be migrated first to avoid circular reference errors.

Apollo deals map to Twenty Opportunities. The deal name becomes the Opportunity name, amount maps directly, close date maps to the expected close date field, and owner resolves by email match against Twenty workspace members. Pipeline stage values map via value-mapping to Twenty's Opportunity stage pick-list.

Apollo deal stage pick-list values map one-by-one to Twenty's Opportunity stage values. We read Apollo's stage labels and map each to a matching or closest Twenty stage name. If Twenty lacks a matching stage, we create it pre-import and configure probability per stage in Twenty settings before the migration runs.

Apollo custom fields on contacts (created via POST /api/v1/fields with modality: contact) become Twenty custom fields on the People object. Field type mapping: string → text, textarea → text (long), number → number, date → date, datetime → date, boolean → select (true/false options). All custom fields must be created in Twenty Settings → Data Model before the CSV import begins.

Apollo company-level custom fields map to custom fields on the Twenty Companies object, following the same type-translation rules as contact custom fields. String, number, date, and boolean field types translate directly to their Twenty equivalents. Industry-standard fields such as annual revenue and employee count have native Twenty equivalents and do not require custom field creation. Fields unique to your Apollo setup must be created in Twenty Settings before migration runs.

Apollo deal-level custom fields migrate to custom fields on Twenty Opportunities. Stage-entered timestamps from Apollo (stored as datetime custom fields) map to Twenty custom date fields. Probability fields map to custom number fields if not represented via Twenty's stage-level probability configuration.

Apollo custom objects (if configured) map 1:1 to Twenty custom objects. We read the custom object schema via Apollo's API and create matching custom objects in Twenty's data model. Custom object relations that use N:N linking in Apollo require junction objects in Twenty — we surface these in the mapping plan before migration runs.

Apollo engagement logs (calls, emails, meetings) map to Twenty Tasks. Original timestamps, owners, and subject/body content are preserved. Task type (call, email, meeting) is stored as a custom select field on the Twenty Task if Twenty's standard Task type field is insufficient. Tasks are linked to the parent People record via Twenty's relation field.

Apollo file attachments are not included in standard CSV exports. Files must be re-uploaded manually to Twenty or migrated via API. We provide a file inventory from Apollo's API and a step-by-step re-upload guide. This is disclosed honestly — attachments are not silently skipped without a remediation path.

Apollo owner IDs resolve to Twenty workspace members by email address match. All users must be invited to the Twenty workspace (Settings → Members) before the migration runs — Twenty's documentation explicitly states that owner relations cannot map unless the user already exists. Unmatched owners are flagged and assigned to a fallback Twenty user.

Apollo sequences (multi-step email/call cadences) are a core platform feature with no export or equivalent in Twenty. We extract sequence step definitions, timing rules, and enrollment conditions from Apollo's API as a structured JSON export. Your team uses this as a rebuild reference for Twenty's workflow builder or a third-party sequencing tool.

Apollo workflow rules (if configured as automations) do not migrate. Twenty's workflow builder handles simple automations but has a different trigger-and-action model. We export workflow definitions as documentation for manual rebuild. Complex Apollo automations with conditional logic should be scoped separately as a post-migration configuration project.