Migrating from Attio

Attio’s list-based modeling maps well to Primicornis object definitions with relation-heavy schemas.

Mapping strategy

Attio concept	Primicornis
Object	Object definition (custom or core)
Attribute	Property definition (watch for formula vs static)
List membership	Often modeled as relation + stage, or filterable select
Record view	Saved views / pipeline boards

Sync considerations

1. Export via Attio API with attribute IDs, not human labels.
2. Resolve multi-select values to Primicornis select options with matching keys.
3. Map Attio People ↔ Companies as bidirectional relations only if your UI needs reverse navigation; otherwise keep a single directional relation plus inverse lookup through search.

Deduplication

• Attio record UUID → store as attio_record_id text property.
• Prefer transactional upserts: batch in units of 200–500 records with retry on 429.

Pitfalls

• Formula attributes — compute outside Primicornis or reimplement via analytics events later.
• Attio views don’t translate 1:1 — rebuild Kanban columns using pipeline stages in Primicornis.

Suggested import order

1. Base entities (person, company, fund)
2. Portfolio companies (startup)
3. Graphs (opportunity, follow-on rounds)

Clean orphan rows (people without email, shell companies) before importing — Primicornis validation is stricter than Attio’s flexible cells.