Affinity to Attio: migration reference

Per-object map

The lift-and-shift map

The table below is the practical map: direct imports, decisions that shape the Attio schema, workarounds where behavior differs, and data that should not be treated as natively migratable.

Anchor 01

The lists conversion decision

Lists are the largest Affinity to Attio schema decision because Affinity firms use lists for several different jobs at once. A list might be an actual working queue, such as "Seed pipeline." It might be an event roster. It might represent a fund. It might be a temporary cleanup view. It might also be a disguised object, such as mentors, LP prospects, portfolio support requests, or acquisition targets.

The migration should classify each Affinity list into one of three destinations. First, keep it as an Attio list when the list is a view or operating surface over existing records. This fits event invitees, current sourcing queues, watchlists, and lightweight partner views. The list-level attributes should come with it, including dropdown options assembled from both field definitions and observed CSV values.

Second, promote it to a custom object when the list has its own lifecycle, permissions, relationships, or reporting needs. A list called "Fund IV LP Prospects" may really be an LP object with commitments, status, next steps, and owner fields. A list called "Dealflow" may become a custom Deal object if it holds stage, source, check size, valuation, partner owner, and pass reason.

Third, collapse it into a global attribute when list membership is just a label. A dormant "AI companies" list may be better as a company category. A one-off dinner list may be archived. A broad "Portfolio" list might become a Portfolio Status attribute unless the firm tracks deeper portfolio operations.

Worked example: a firm has "Fund I Deals," "Fund II Deals," and "Fund III Deals." If each fund has the same stages and permissions, model Fund as an attribute or reference on Deal. If each fund has a different workflow or visibility boundary, use fund-specific lists over a shared Deal object, or model Fund as its own object and reference it from Deals.

Anchor 02

Cross-linkable notes

Affinity and Attio differ in a way investors feel quickly: Affinity can associate one note with multiple records, while Attio notes attach to one record. That means a partner's note about a founder, company, co-investor, and opportunity cannot be copied literally as one native note connected everywhere. The migration has to choose how much fidelity is worth preserving and where users should expect to read the note later.

There are two standard implementation options.

Replication. Create one Attio note per linked destination. This gives users the best recall experience because the note appears wherever they expect it. The cost is duplication: edits after migration do not stay linked, and a single historical note becomes several records in the activity stream.

Canonical attachment plus reference metadata. Attach the note to the primary record, often the company or deal, and preserve other linked records in the note body or a structured reference field where possible. This avoids duplicate content, but users need a convention for where to look.

For many VC teams, the right answer is a mix. Most historical notes follow a canonical-attachment rule, and a smaller set of high-signal notes get replicated where partners are most likely to look for them.

Attio does not natively support moving a note from one record to another, so the placement rule needs to be decided before notes are written into the workspace. We do have internal tooling that can transfer notes between records after the fact, which usually comes up post-migration in cases like moving a note from a portfolio company to its LP record. It is not a substitute for choosing the canonical attachment rule up front, but it does mean a single misplaced batch does not have to live there forever.

Anchor 03

Email body, meeting history, departed users

Email and calendar history are the highest-risk migration surface because buyers use one phrase, "history," to mean several different things. Metadata, bodies, attachments, meetings, synced inbox history, and departed-user records all have different paths.

The default lift-shift path is metadata only. Affinity interaction exports can preserve information such as timestamp, subject, participants, interaction type, and linked records. That can be loaded into Attio as notes, a custom activity object, or structured reference data. This preserves searchable context, but it does not reconstruct the full email thread. Standard Affinity API access does not expose email bodies in the same way users see them in the product UI, so a normal migration should not promise full body import.

Meeting history has a separate matching problem. Attio can sync meetings from connected calendars, and historical Affinity meetings can be pulled and matched against Attio meetings by date range, title, and attendees. This can work well, but it is sensitive to API limits, date windows, attendee normalization, and blank or malformed interaction types. A migration plan should distinguish "meeting record preserved" from "meeting linked to the exact note or deal record."

Departed users create the real deadline. If two partners left the firm and their inbox or calendar history matters, the firm needs Affinity admin access while the subscription is still live. Once the subscription ends, and especially once source mailboxes are gone, the project moves from migration into data archaeology.

There are three practical options. Option one is metadata-only lift-shift: import subjects, dates, participants, and linked records, then rely on Attio's native inbox sync for active users. Option two is a specialized recovery path for firms that need bodies, attachments, or old user accounts recovered from nonstandard surfaces. Option three is an in-place freeze: keep final Affinity exports, store them durably, and accept that the old interaction archive is a reference source rather than live Attio activity.

{
  "interaction_history_default": {
    "migrates": ["subject", "timestamp", "participants", "linked_record_ids", "interaction_type"],
    "not_default": ["email_body", "inline_attachments", "departed_user_mailbox_content"],
    "recommended_destination": ["attio_note", "custom_activity_object", "archived_export"]
  }
}

Anchor 04

Permissions, LP data, access control

Permissions should be rebuilt, not mirrored. Affinity and Attio use different access models, and a literal copy can preserve the wrong exposure patterns. The recurring VC concern is LP and fundraising data visibility: analysts, interns, external admins, and platform contractors may need access to dealflow or contacts without seeing LP commitments, sensitive fundraising notes, or partner-only relationship context.

A common VC permission map uses three operating roles plus exceptions.

Partners need broad access across Companies, People, Deals, Funds, LPs, notes, and reports. They usually own sensitive relationship context and need write access to deal and fundraising records.

Principals need working access to dealflow, sourcing lists, company records, people records, and meeting notes. They may need read access to some LP or fund records for context, but not necessarily full fundraising notes, commitment fields, or side-letter data.

Analysts and external admins need narrower operational access: research queues, enrichment views, task lists, scheduling, and specific deal lists. They should not get default visibility into LP records unless their work requires it.

In Attio, list-level access is often the practical lever. Sensitive fundraising data should live on restricted LP, Fund, or Commitment objects, or on restricted lists when the data is a list-specific workflow. Notes require conventions because a note visible on a record follows the record's visibility. Field-level privacy and list-scoped notes should be treated as limitations to design around, not assumed.

Anchor 05

Multi-fund VC operations

Multi-fund firms often use Affinity lists as a substitute for fund architecture. That can work for a while: one list for Fund I, another for Fund II, another for Fund III, each with its own status values, owners, and saved views. The problem appears when the firm wants cross-fund reporting, shared company records, LP visibility, or clean permissions.

There are two main Attio patterns. The lighter pattern is list-as-fund: use one Deal object, keep fund-specific lists for pipeline views, and add list-level attributes where each fund needs its own stage or notes. This fits firms where funds share a team, share most stages, and do not require strict data separation. It also keeps the day-to-day view familiar for investors.

The more structured pattern is custom-object-as-fund: create a Fund object and relate Deals, LPs, and Commitments to it. This fits firms that need to ask questions such as "show every deal sourced for Fund III," "show LPs committed to Fund IV," or "show companies shared across two fund strategies." It also makes permission design cleaner because LP and Commitment records can sit outside the general dealflow surface.

The access-control consequence matters. If fund membership is only a list label, sensitive fund data can leak into global company or people views. If Fund is an object with related records, the firm can separate operating pipeline data from fundraising and LP data more deliberately.

Anchor 06

Reporting and dashboards parity

Reporting parity is not a single feature check. Attio can handle core operating views, saved filters, pipeline boards, dashboards, and object-level reports. For many firms, that is enough to replace the reports partners use weekly: active pipeline by stage, owner workload, stale deals, pass reasons, recent meetings, and companies missing next steps.

Affinity can still be stronger for teams that built deep reporting around its native VC assumptions or connected it to Looker-style analytics. Some buyers explicitly compare Attio's native reporting with Affinity plus an analytics layer, not Affinity alone. That is the right comparison if the old workspace already has external dashboards, historical exports, or board reporting built around the source schema.

The migration decision is therefore tiered. Day-one reporting should live in Attio: partner pipeline views, IC prep, sourcing stage, owner, and next action. Deeper analytics should go to Metabase, Hex, Looker, or a warehouse when the firm needs historical trend reporting, change history, portfolio KPI views, or cross-system joins with fund admin data. Field-change history is a good example: Attio's audit log is useful after migration, but old Affinity change history belongs outside Attio if it needs to remain queryable.

A good scope names the reports that must work on launch day and the reports that should wait until the data model has stabilized.

Anchor 07

Intro-source tracking

Affinity's native intro-source behavior is one of the clearest places where buyers should not be dismissed. Investor teams care about who introduced a founder, which partner owns the relationship, whether an LP sourced a company, and whether a deal came through an existing founder, co-investor, scout, or cold inbound.

Attio can model this, but it is usually configured rather than native. The common setup is a structured Intro Source attribute on Deal, Company, or both, plus supporting attributes such as Introduced By, Source Type, First Touch Owner, and First Touch Date. Workflows can fill some fields from email metadata, form submissions, or manually selected referrers. More advanced builds parse forwarded intro emails and create a task when source data is missing.

This is a high-frequency buyer ask because intro attribution affects partner credit, scout relationships, LP relationship management, and sourcing strategy. The migration should preserve legacy intro-source fields where they exist, but it should also define the future workflow. Otherwise teams import messy source data and keep creating more.

Anchor 08

Google Drive deal folders

Google Drive deal folders are the file workflow most VC teams ask about. The pattern is straightforward: create or identify a folder for each deal, company, or diligence process; store the folder URL or connected-folder reference on the Attio record; then use automation to create the folder when a deal enters a relevant stage.

The migration has two parts. First, historical files need to be exported, grouped by source record, matched to Attio records, placed into a controlled storage destination, and linked back. Second, future files need a workflow. A typical architecture is Attio webhook on Deal created or Stage changed, middleware such as HookDeck for retries and ordering, Google Drive folder creation under the correct parent, then an Attio record update with the folder link.

This does not need to copy Affinity's exact file behavior. Many firms prefer the Attio pattern because the files live in storage the firm controls. The important scope decision is whether day one requires historical file migration, automatic future folder creation, or both.

Integrations

Integration inventory

The integration inventory should separate native product behavior from migration work. Some tools connect directly to Attio. Others need a bridge, middleware, or a post-cutover rebuild because the old Affinity integration cannot simply be repointed.

Forward-looking

Planning notes, not launch promises

The notes below are planning observations, not launch promises. They reflect our reading of Attio's direction and the migration patterns we have seen as of 2026-Q2, and they are meant to inform scoping decisions rather than to lock anyone into a roadmap.