How to export your data from Attio

How to export your data from Attio before you leave

If a renewal, a rise in seat costs or a data residency requirement is pushing you to leave Attio, treat the export as an inventory task before you treat it as a download. Attio exports data view by view, as CSV or Excel files, so every list or object view you need must be exported on its own. Some data, such as enriched fields, may not come out as usable values, so inspect those columns before you rely on the files for a migration. Records you can see in the interface are not the same as records that arrive intact in a spreadsheet.

Before exporting, list the objects, lists and saved views that hold business data, including relations between records, notes and activity history that matter to your sales or compliance teams. Then confirm who in your workspace can run exports, since export permission is set by role and not every user will have it. Plan for a person with the right role to run each export and keep the files in a location you control. Compare the column headers in each file with the fields in your current workspace, and note any fields that export blank or as raw identifiers so you can handle them later.

The export is one step in a wider exit plan. It should sit alongside a decision on the target platform, such as self-hosted Twenty, and a plan for importing records, recreating objects and rebuilding automations. Confirm the current export formats, row limits, and any restrictions on what can be exported in Attio's own documentation and in your workspace admin settings, because these details can change. Ask Attio directly if you need a complete copy of data that the standard view export does not cover.

Which Attio data you can export and in what format

This table lists each type of Attio data you may need to move, the export route, the file format and the limits or permissions to confirm. Read it before you start, then use the checklist later on the page to confirm each row is covered. Where the supplied facts do not state a cap, the cell tells you what to confirm with Attio.

Data type	Export method	Format	Limits or permissions
Object records (companies, people, deals)	View export from the Attio interface, one view at a time	CSV or Excel	Confirm row and file size limits in Attio's current export documentation or with your account team
List entries and list view contents	Export the specific list view you need, with its filters and visible columns	CSV or Excel	Confirm whether every list is exportable by all roles in your workspace
Relations between records	Captured as linked fields in the view export, so check that the relation columns are visible in the view	CSV or Excel	Confirm how multi-value relations are written in the file before you plan the import
Enriched or third-party fields	May appear blank or be excluded from a standard view export	Not guaranteed in CSV or Excel	Confirm with Attio which enriched fields export and record a fallback for each one
Attachments and files	Not covered by a standard view export; download them separately where Attio allows	Original file format	Confirm the download route and any size or count limits with Attio
Activity, notes and emails	Check whether each activity type appears in an export or needs a separate method	Confirm per type	Confirm the export route with Attio, since support for each type may vary
Workspace settings and automations	Not part of a record export; document them manually before you leave	Notes or screenshots	Plan to rebuild these in the target CRM rather than expect a file
Export permissions	Only users whose role allows exporting can run a view export	Not applicable	Confirm which roles can export in your plan and assign a named export owner

What stays behind when you export from Attio

A CSV or Excel export carries record values, but much of what makes an Attio workspace work lives outside a table of records. The cards below cover the parts that tend to stay behind, what each gap means for your new CRM, and the workaround to plan before you cancel. Confirm every gap against Attio's current behavior with a test export in your own workspace.

Enriched fields may export blank

Attributes filled by enrichment, such as company size, funding or social profiles, are often pulled from a third-party source at the time of enrichment. In an export they may appear empty, or show the value without the source or timestamp that explains where it came from. Run a test export of a list with enriched columns and compare the output against what you see in the app. For the new CRM, plan to rebuild these fields as plain attributes and either re-run enrichment in the new system or keep a dated snapshot of the values so the history is not lost.

Email and calendar data stays in the source

Emails, calendar events and the links between them and your records are synced from connected Google or Microsoft accounts. Those messages live in the mailbox provider, and an export of records does not copy them into a file. Expect the activity timeline on each record to be empty in the new CRM until the new tool connects to the same mailboxes and syncs again, and past history older than the sync window may never come across. Confirm with a test export which activity you can actually retrieve, then keep the mailboxes as the long-term archive.

Workflows and automation definitions

Automations that route records, send notifications or update fields exist only as configuration inside Attio. A record export contains the results of those automations, not the logic that produced them. Before leaving, screenshot or write out each trigger, condition and action, and note which integrations each one calls. In the new CRM these must be rebuilt by hand, so treat the written list as the specification and test each rebuilt flow against sample records.

Custom roles and permissions

Workspace members, their roles and the access each role grants to objects, lists and fields are settings, not data. An export shows records that a user could see, but it does not show who had access to which parts of the workspace. Record the current member list, their roles and any restrictions on sensitive fields. The new system will need its own role model, so map each existing role to a role you create and confirm that restricted fields stay restricted after import.

Dashboards and reports

Charts, summary views and reports that aggregate pipeline value or activity over time are presentations of data rather than data themselves. A table export gives you the underlying rows, so totals and trends must be recalculated in the new CRM or in a reporting tool. Capture a dated copy of each dashboard as an image or a spreadsheet, and keep the filter logic written down so that the same numbers can be reproduced after the move.

Sequence for a complete Attio export

This sequence turns the views in your Attio workspace into a verified, dated set of export files and a register of gaps. Each step leaves a record that another team member can check before the data is loaded elsewhere or the workspace is retired.

Inventory every object and list view
List each object in the workspace, including people, companies and any custom objects, then list every saved view within each one. For each view, note the filters applied, the columns shown and the record count the interface displays. Keep this inventory in a spreadsheet, because views are the unit that Attio exports and any view left off the list is easy to miss. The step is done when every object and view has its own row in the inventory.
Confirm who holds export permission
Before any export starts, check which workspace members are allowed to export data. Ask the workspace owner or an admin to confirm the role settings that permit exports, and record the names of the people who will run them. If your account cannot export a particular view, arrange for an admin to run that export and note who did it. The step is complete when the export holders are named in the inventory and each one has run a test export on a single small view.
Export each view with its settings recorded
Export each view from the inventory as CSV or Excel using the export option in the interface. Before saving each file, record the view's filters, sort order and visible columns beside its inventory row, since the file reflects what the view shows at the moment of export. Fields that are hidden in a view may not appear in the file, so add any missing fields to the view first if you need them. The output is one file per view, each matched to its inventory row.
Store files with a naming and date convention
Save every file in one dated folder, using a naming pattern that includes the object, the view name and the export date, for example object_view-name_YYYY-MM-DD.csv (illustrative). Keep the original files unchanged and make a separate working copy for any cleaning. Store the folder on storage your organization controls, with access limited to the migration team. The check is that every file maps to exactly one inventory row, with no duplicates and no unnamed downloads.
Verify row counts and key fields against the live workspace
Compare each file with its live view. Count the rows in the file, compare them with the records the view shows, and either confirm the counts match or document the difference. Then spot-check a sample of records across the views: email addresses, names, owner assignments, relations between people and companies, and date fields should match what appears in the workspace. Flag any field that is blank in the file but populated in the workspace, because it needs separate handling. The step closes with a signed-off verification sheet for each view.
Record the gaps and decide how to fill them
List everything the export did not carry across, such as enriched or third-party data, attachments, activity history, automations, email content and any field that exported blank. For each gap, note its source and whether it can be recreated, exported separately or accepted as lost, and name the person who approves that decision. Confirm with Attio's documentation or support what the export covers, because coverage can change between releases. The output is a gap register that sits alongside the data files and feeds the migration plan.

Who can export from Attio and what to do if they cannot

The workspace admin is usually the person who runs the export project. Admins manage members, roles and workspace settings, so they are the most likely to confirm whether export is enabled for each member and which objects and lists are visible to them. Start by checking your own access before scheduling any other work, because an admin who cannot export will hit the same wall as everyone else.

Confirm your own export rights: Open the admin settings and check the role assigned to your account, then test an export on one small list.
Map roles to people: Record which members can export, which can only view, and which have no access to particular objects.
Export per object and list: Run exports for each object and saved view, since permissions can apply to objects and not only to the whole workspace.
Keep a record: Save the file names, record counts and dates of each export in your migration log.
Review access after the export: Remove temporary export rights once the files are verified.

Before you start, confirm the exact permission names and role mappings in Attio's admin settings, because they can change between releases.

Where the exported files go next

A CSV or Excel export is a neutral copy of your Attio data, so the target system decides how much work the import will be. Each file has to be mapped to the target's fields, relations between records have to be rebuilt from the exported values, and matching rules have to be set so existing contacts and companies are not duplicated. Check these three items against each object and list view before you choose where the data goes, because the export file alone does not carry the structure of your workspace.

A self-hosted Twenty instance is one possible target. Twenty is published mostly under AGPL-3.0 with an additional application exception, so you can review the license terms before you deploy. The Docker Compose self-hosting guide runs a server, a worker, PostgreSQL and Redis, and Twenty exposes both REST and GraphQL APIs, which matter if you plan to load data programmatically instead of through file import. Confirm the current release, hardware requirements and upgrade path in the Twenty self-hosting guide before you plan the rebuild.

Choosing the target is a separate decision, and the sibling pages on Attio versus Twenty, the migration steps and the cost comparison cover it in depth. Do not wait for that decision to finish before you export. Pull complete copies of every object and view now and store them under your retention policy, so that whichever platform you choose, you are working from a snapshot taken while your Attio workspace is still intact.

What to plan before the Attio contract ends

The export itself is the easy part. Before the contract ends, several decisions determine whether you keep a complete, usable copy of your records and whether your teams can keep working. Each card names what to confirm with Attio and who in your organization should own it.

Set the final export date

Pick the date your last full export must be taken, and work backward from it. Every object, list view and attachment should be exported after the last day anyone writes new records, so the archive matches the state of the CRM at shutdown. Ask Attio how it handles data after your subscription ends and whether it offers a timeline for access. The RevOps or CRM owner should set this date with finance and the sales leadership team.

Confirm the archive retention plan

Decide how long the exported files must be kept, where they will be stored, and who can open them. Sales and customer records may fall under contractual, legal or regulatory retention rules, and the archive must stay readable after Attio access ends. Store it in an encrypted location you control, with a named owner and an index of which object each file came from. Legal, compliance and IT should agree on this before the final export runs.

Ask about a read-only period

Ask Attio in writing whether a read-only window exists after the subscription ends and how long it lasts. If it does, you can verify exports against live data and recover records that were missed. If Attio does not offer one, plan for a single cutover export with a second check before access closes. The account owner should get this answer in writing, since it changes the verification plan.

Keep integrations running until cutover

Inventory every connection that writes to or reads from Attio, including email and calendar sync, forms, marketing tools, data warehouses and custom scripts that call its API. Keep them running until the new CRM is receiving data, then switch them off in a planned order so no lead or activity is lost. The integration owner, usually a platform or RevOps engineer, should maintain the list and sign off each switch-off.

Notify users and collect personal notes

Tell every user the date writes stop and the date access ends, and ask them to save personal notes, drafts and private tasks that may not appear in a standard export. Notes attached to a person, personal reminders and comments are the items most often missed. Give users a short checklist and a deadline. The CRM admin should send the notice and HR or team leads should confirm that departing staff have finished their handover.

Check the contract for return terms

Read the Attio agreement for clauses on data return, deletion after termination and any obligations to certify deletion. Confirm whether Attio will provide an export on request if your self-service exports miss something, and whether that carries a fee. Procurement and legal should hold this review, since the terms decide what you can ask for after access closes and what proof of deletion you can demand.

Questions teams ask before exporting from Attio

How much effort does a full export from Attio take?

There is no fixed duration. Effort scales with the size and shape of the workspace: the number of objects, list views, relations between records, enriched fields and total record volume. Each object and view has to be identified, exported, checked and labeled, so a workspace with many lists takes more hands-on time even when each file is small. Enriched fields add work because they can export blank and need a separate source for their values. Before agreeing to any timeline, count your objects and views and confirm current record counts in your workspace. Then ask any provider for a written inventory that matches your count.

Can an internal admin export everything from Attio without outside help?

Usually yes for the basic files. Attio exports data view by view as CSV or Excel, so a team member with export access can download each view that matters. The harder part is completeness. One export covers one view, not the whole workspace, so the admin must list every object and list and repeat the export for each. Confirm in your own workspace who holds export permission, since role settings decide this. Plan time to check the files, because relations, enriched fields and attachments may not appear the same way they do on screen. Outside help becomes worthwhile when the inventory is large or when the data must be mapped into another system.

What does outside help usually cover in an Attio export?

Outside help usually covers the steps that are easy to miss, not the download itself. A provider can build the inventory of objects, list views and fields, set the export order, run and store the files, check row counts and column headers, and document where each file came from. If the target is a self-hosted platform, the work can extend to mapping objects and relations into that system and importing the records. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask that the scope name the objects, views and fields covered and the checks used to close the work.

What do business owners need to provide during an Attio export?

Business owners decide what the data means and what must survive the move. Each object or list usually needs a named owner who can say which records are current, which are duplicates and which can be retired. Before the export runs, they should:

Confirm which views and fields are in scope, including retired ones still needed for reporting.
Approve how fields map to the target system, including names and required values.
Identify enriched data they want to keep and the source they will use to refresh it.
State retention or legal hold rules for contact and deal history.
Sign off the completeness checklist before the old workspace is closed.

How can you confirm nothing was missed in an Attio export?

Compare the export against the workspace, not against memory. Keep a written inventory of every object and list view, then check each export file for row count, column headers and a sample of records traced back to Attio. Record which fields are known to export blank, such as enriched data, and store those values or their source separately. Check attachments and linked records on their own, because they may not travel in the same file. A short sign-off sheet with the owner's name, the date and the file location makes the result auditable. Repeat the checks after the final export run, since records changed during the project will not appear in an earlier file.

Is exporting from Attio enough to move to another CRM?

No. Export files carry records, not the structure around them. Enriched data is one known gap, and you should confirm what else stays behind in your own workspace. Plan on recreating object definitions, relations, views, permissions and automations in the target. For Twenty, the supplied facts show it supports custom objects and fields, workflow automation, email and calendar sync and role-based permissions, but those settings still have to be built and tested in the new system. Plan the import, rebuild automations and compare key reports between old and new before switching users over. Treat the export as one step in a migration plan.

What makes an Attio export project cost more or less?

Cost follows effort, and effort follows scope. The largest cost is usually internal time: someone must inventory the workspace, run exports, check files and make decisions. External cost, if you buy help, rises with the number of objects and views, relations, enriched fields, the amount of mapping the target needs and the number of checks the business requires. The export and checks are one-time work. Recurring costs belong to the target platform, such as hosting, upgrades and administration, and should be costed separately. Ask any provider for a quote that lists each object and view in scope, the fields that need mapping, who performs each check and what is handed over at the end.

How DeployOpen scopes an Attio data exit

DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure, so an export from Attio becomes a written, tested and documented piece of work rather than an ad hoc download. We start by agreeing what leaves Attio, where it lands and how completeness is proven before any work begins.

How we scope

Inventory every Attio object, list and saved view, and record which ones hold data you must keep
Confirm which enriched or integration-sourced fields will not export and plan how to capture them
Agree in writing who on your team may run exports and which roles hold admin rights during the move
Define the target environment, whether cloud account, data center or air-gapped network, before fixing deliverables

How we build

Prepare the export procedure per object and view, with record counts reconciled against Attio before and after
Set up the self-hosted target for Twenty or another agreed platform on PostgreSQL and Redis inside your environment
Map exported fields, relations and attachments to the target data model and test the import on a copy first
Rebuild required automations and permissions and test them against the migrated data

How we hand over

Deliver an export runbook with a per-object checklist, reconciliation results and the list of known gaps
Document the target configuration, backup routine, upgrade steps and access model for your operations team
Record which data stayed behind, who approved that decision and where any residual copies are stored
Walk your administrators through the handover and confirm acceptance against the written scope

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
A quote follows from the written scope, so ask for the components priced separately, such as migration, hosting and testing
Confirm with your legal or compliance team how retained exports should be handled once Attio access is closed

How to export your data from Attio