Affinity to Attio migrations

Affinity and Attio both center the workspace around people and companies. Affinity supports several company relationships on one person by default. Attio usually treats one company as primary and uses attributes to capture the other roles.

We import companies and people directly and keep the Affinity record identifiers as internal matching keys during the migration. After coverage checks, we use domain-based deduplication to consolidate duplicate company records. When a person needs more than one company relationship, we model the additional roles with reference attributes in Attio.

Affinity lists often carry more meaning than a simple saved view. A single list can act as a working queue, an event roster, a fund proxy, an LP prospect list, a mentor group, or a watchlist. Each list needs to be classified before it can move into Attio cleanly.

For each list, we decide whether it should stay an Attio list, become a custom object such as LP, Fund, or Commitment, or collapse into a global attribute. We make those choices during scoping so the migration preserves how the team actually works.

Read: lists conversion deep-dive →

Affinity notes can be attached to several records at the same time. Attio notes attach to one primary record, so shared notes need a clear placement rule before they move.

Two options usually work. We can copy the note onto every linked record so each one shows it in its own activity, or we can attach it to one main record, usually the company, and reference the related people and deals inside the note. We choose the rule that best matches how the firm expects to find context after the migration.

Read: cross-linkable notes deep-dive →

Affinity dealflow can live in opportunities or in company lists. Many VC teams combine pipeline stage and pass reason in a single Status field, and multi-fund workspaces often use fund-specific lists as a stand-in for real fund architecture. Intro-source attribution is native in Affinity but has to be configured in Attio.

We use either Attio's standard Deal object or a custom Deal object, depending on how the firm runs pipeline. We almost always split the source Status field into separate Stage, Pass Reason, and Legacy Status attributes so reporting can separate current pipeline position from rejection reason. For multi-fund firms, we represent funds with lists or custom Fund records based on visibility needs, and we set up intro-source tracking with an attribute plus a workflow.

Multi-fund modeling → Intro-source tracking →

Affinity attributes include field type, allowed options, and historical values. The useful ones have a direct path into Attio attributes.

We migrate Affinity attributes into Attio after mapping field types, planning slugs, creating options, and reviewing how often each field is actually populated. Fields that are stale, duplicative, or barely used are identified and retired during the attribute review that happens inside the data export step.

Active users can rebuild their email and calendar history through Attio's native inbox sync. Departed-user mailboxes that have been deprovisioned cannot be backfilled through that sync, and standard Affinity API endpoints do not expose full email bodies.

For departed users, we preserve email and meeting metadata in a custom Interaction object so the context is still searchable. If full bodies or attachments matter, we evaluate the source data separately. Many firms also keep a frozen Affinity export as the historical archive of record.

Read: email + meeting history deep-dive →

Affinity stores files directly on records. Many VC teams prefer to keep documents in Google Drive or OneDrive and link the relevant folder from the Attio record instead.

We export files from Affinity, organize them by company in Drive or OneDrive, and link the folder back to the Attio record. Going forward, new folder creation can be automated from Attio events such as Deal stage changes.

Read: Google Drive deal folders →

Affinity and Attio use different access models, so permissions do not translate one-to-one. Sensitive LP data, fundraising commitments, and partner-only notes should be rebuilt intentionally rather than copied across in the same shape.

We typically define operating roles for partners, principals, analysts, and external admins, and then handle exceptions separately. Sensitive information lives on restricted lists or restricted custom objects, and we treat field-level privacy as a planning constraint rather than something Attio handles automatically.

Read: permissions and LP data →

Historical Affinity field changes cannot be inserted into Attio's native audit log. Attio's audit log begins when the migrated workspace starts operating in Attio.

If the previous change log matters, we preserve it in archived Affinity exports or send it to a warehouse as reference data. Reporting and workflow plans should account for the fact that Attio's native history starts at the migration.

Affinity's proprietary enrichment values are tied to Affinity's own data product and provider relationships. Once those values leave Affinity, they stop updating.

We do not migrate proprietary enrichment as a live source of truth. We use Attio's built-in enrichment as the baseline and add Apollo, Clay, or Harmonic where the firm needs deeper or fresher coverage.