How to export your data from Asana starts with knowing which path you can use
If a renewal, a pricing change or a data residency requirement is forcing you out of Asana, the first step is knowing which export you can actually run. Asana documents two paths: a per-project CSV export from the project actions menu, which any project member can use, and an organization export that returns complete data as gzipped JSON, but only for service accounts of an Enterprise+ organization. Neither path covers everything a migration needs, so the choice shapes the rest of your plan. Check your plan tier and admin rights before you commit to a timeline, because a standard plan will not give you the full JSON export.
The per-project CSV export includes task ID, dates, name, assignee, due date, tags, notes and parent task, which is enough to rebuild a task list in a new tool. It does not carry everything else you will need. Confirm with your Asana administrator which portfolios, rules, custom fields, attachments and comment threads sit outside the CSV, and whether your tier includes the organization export at all. Ask Asana, in writing, what the organization export contains for your workspace, since the developer documentation describes the mechanism and your contract defines the entitlement.
The rest of this page covers the gaps each path leaves, a sequence for running the exports and a way to verify that counts and fields match once data lands in your new system. Treat the first export as an inventory rather than the final copy: list every project, owner and dependency now, so that anything missing from the files is visible before your access to the workspace changes.
What each Asana export path returns, in which format and with which limits
This table compares the per-project CSV export with the organization export on data covered, who can run each one, output format and documented limits. Read it as a checklist of what you will have in hand before you start a migration. The main takeaway is that the CSV path is open to project members, while the complete organization export depends on an Enterprise+ service account, and neither should be treated as a full backup without checking the gaps.
| Export path | Per-project CSV export | Organization export |
|---|---|---|
| Data covered | One project's tasks with task ID, dates, name, assignee, due date, tags, notes and parent task | Complete organization data, as documented by Asana |
| How to run it | From the project actions menu in Asana | Through the Asana API as an export request |
| Who can run it | Users who can open the project, subject to their own access | Service accounts of an Enterprise+ organization only |
| Output format | CSV file, one file per project | Gzipped JSON |
| Documented fields | Only the fields listed in the CSV article; confirm any others in your own file | Documentation states complete organization data; confirm the object types in your own export |
| Relationships and history | Parent task links are included; confirm whether sections, comments and attachments appear in your file | Confirm how links between projects, portfolios, rules and attachments are represented |
| Main limit for migration | Project by project, so cross-project structure and portfolios must be rebuilt by hand | Requires an Enterprise+ plan and a service account, and output needs parsing before import |
What neither export returns, and how to recover it before you cancel
Neither Asana export is a complete migration package. The CSV covers task fields for one project at a time, and the organization export is limited to Enterprise+ service accounts, so the items below need a separate check and a manual or scripted recovery plan. Confirm each gap in your own workspace with a test export before you set a cancellation date.
Attachments and file content
The CSV holds attachment references and names, not the files themselves, so the actual documents in tasks have to be downloaded separately. Work project by project, record which tasks carry files, and check that each download matches its task ID. Confirm with a test export whether your organization export includes the binary files on your plan, since that determines how much manual download work remains.
Comments and conversation history
Task comments, stories and the activity trail are where decisions get recorded, and a flat CSV export does not preserve their order or authorship in a usable form. Decide which threads matter for audit or handover, then copy them into the target tool or an archive document. Verify in a test export whether comments appear in your output and in what structure before you rely on them.
Custom fields and section layouts
Custom field values come through as columns, but field types, dropdown options and the section groupings shown on a board are not rebuilt by the file. Export one representative project, list each custom field with its type and allowed values, and map board columns to sections in the target. Ask whether any field is a formula or multi-select so you know which values need manual rework.
Rules, workflows and automations
Automation rules that route tasks, set fields or notify people are not included in any export format. Before cancellation, list every active rule with its trigger, condition and action, then record them as written procedures or rebuild them in the target tool. Test each rebuilt rule on a copy of one project so behavior matches the original.
Portfolios, goals and reporting views
Portfolios, goals, dashboards and saved reports carry the roll-up logic leadership relies on, and they do not appear in the project CSV. Capture each portfolio's member projects, goal owners and target values, and each report's filters and columns. Export the underlying data for these views into a spreadsheet so the numbers remain available even when the views are rebuilt.
Project-level permissions and membership
Who can see, edit or administer each project is set in Asana's sharing and team settings, and the CSV carries assignees rather than access rights. Record each project's team, guests and admin roles, plus any restricted teams, before you import. Confirm the target's role model with a small test project so no one gains or loses access during cutover.
The export sequence for a complete Asana exit
This sequence turns Asana's export options into a verified inventory of projects, tasks, attachments and configuration that you can carry into a self-hosted Plane or OpenProject instance. Each stage produces a stored artifact and a check against the source before the next stage begins.
Inventory every project, portfolio and team
List every workspace, team, project and portfolio in scope, along with its owner, approximate task count and whether it is active or archived. Ask each team lead to confirm which projects still hold live work, since archived projects often carry history you may need to keep. The output is a single inventory sheet that becomes your reference for every later check. You know this step is done when each project has an owner and a keep, archive or retire decision.
Confirm admin rights and export eligibility
Identify who holds super admin rights and whether a service account can be created on your current plan. Asana's organization export is only available to service accounts of an Enterprise+ organization, so confirm your plan tier with your Asana account owner before planning around it. Record the name of the person who will run each export and where the output will be stored. The output is a short access record, and the check is that the named operator can open every project in the inventory.
Run per-project CSV exports
Export each project in the inventory to CSV from the project actions menu. The file includes task ID, dates, name, assignee, due date, tags, notes and parent task, which covers the fields most migration tools map first. Save each file under a name that matches its inventory row. The check is a file count that matches the inventory, and a spot comparison of five tasks per project against the live board for name, assignee and due date.
Run the organization export where available
If your organization qualifies, run the organization export through a service account and receive the complete data as gzipped JSON. Store the archive in encrypted, access-controlled storage with a restricted access list and a record of who downloaded it. Do not unpack it into a shared drive. The output is one archive with a checksum recorded in your migration log. If the export is not available on your plan, record that decision and rely on the CSV and attachment steps instead.
Download attachments separately
CSV exports and the organization export handle task data, but attachments need their own download pass. Work through each project and save files under a folder structure that mirrors the project and task, so each file can be traced back to its parent task. Note any attachment that fails to download, along with the task it belongs to. The output is a folder tree and a failure list. The check is that the file count for each project matches the number of attachments you recorded from the source view.
Record rules, portfolios and goals by hand
Document automation rules, custom fields, portfolios, goals, forms, templates and project-level permissions manually. Exports of tasks and projects generally do not carry these configuration objects in a form you can import directly, so screenshot or write down each one with its trigger, conditions and owner. The output is a configuration register that the target tool team can rebuild. The check is a second reviewer confirming the register against the live settings for each project.
Verify each stage against the source
After each export and import, count tasks and compare names, dates, assignees, subtasks and comment counts against the source project for a sample and for every project with a deadline. Keep a written reconciliation log with the source count, the target count and any differences with an owner for each. Do not sign off a stage until its log shows zero unexplained differences. The output is a signed reconciliation record per project, which becomes evidence for the cutover decision.
Which export path fits your Asana plan and team structure
If your organization does not hold an Enterprise+ contract, the organization export is not available to you. Your practical route is the per-project CSV export from each project's actions menu. The file carries task ID, name, assignee, due dates, tags, notes and parent task, so it covers the core of most task lists. Project members or admins with access to each project run the export, and someone on your side owns the inventory of which projects were exported.
- Coverage: Each CSV represents one project. Comments, attachments, custom field detail, rules, portfolios and goals are not part of the standard project export, so list them separately before you start.
- Consistency: Export every project on the same day or in one batch, and record the export date and file name in a shared register so later edits in Asana do not cause mismatches.
- Effort: Plan for manual repetition across projects. The work scales with project count, not with data volume.
- Recurring cost: Keeping the Asana subscription running during parallel work is the recurring cost to plan for, and it is set by your existing contract.
- Confirm with Asana or your admin: Which export options your current plan and admin role expose, and whether any project in your workspace restricts export by permission.
Before you rely on CSV alone, confirm the exact field list against your own project exports, since your templates and custom fields may differ from the documented example.
If your organization is on an Enterprise+ plan, Asana's organization export returns the organization's complete data as gzipped JSON. The export is only available to service accounts of an Enterprise+ organization, so a named admin cannot simply click it as a regular user. Your platform or IT team usually requests the service account, runs the export through the API and stores the archive under your own controls.
- Who runs it: An administrator with service account access, ideally a team that already manages API credentials and secrets for other integrations.
- Completeness: The JSON is a broader source than CSV, so use it as the reference copy and map from it when you build migration files.
- Handling: Store the archive encrypted, restrict access to the migration team and set a retention date, because the file contains the full organization dataset.
- Consistency: Keep the export timestamp with the archive and reconcile it with the final CSV or API pulls taken closer to cutover.
- Confirm with Asana: The export's current limits, how long a run takes for your data volume, the exact JSON schema and whether attachment binaries are included or only referenced.
Ask Asana to confirm the export format and contents in writing, and verify them with a test export before you commit to a migration date.
Organizations with several workspaces, many projects or teams that duplicate projects across departments need a structured inventory before any export starts. Mixing paths here causes the most errors, because the same project may exist in two places, owned by different people. Assign one migration lead and build a register that lists each workspace, project, owner, export method and export date.
- Inventory first: Record every workspace, project, template and archived project. Flag duplicates and decide which copy is the source of record.
- Split by path: Use the organization export for the reference archive where you have Enterprise+ access, and CSV for project-level content where you do not, then cross-check counts per project.
- Ownership: Name one owner per workspace who signs off on the export set, so departments do not change data after the snapshot.
- Freeze window: Agree a cutoff for edits in Asana so the final export matches what the new tool receives.
- Confirm with Asana or your admin: Which workspaces sit under the organization, whether guest and external users are included in exports, and how archived projects are represented.
Illustrative example: a company with eight workspaces would track eight export records, each with its own sign-off, rather than exporting one file and assuming it covers everything.
How to verify an Asana export before you rely on it
Run a short count-and-sample check before anyone builds a migration plan on an Asana export. Start by counting projects and tasks in Asana itself: open each project, note its task count, and record the same figures for the team or workspace you are leaving. Then count the rows in each per-project CSV and the tasks in the organization export. The counts should match. Where they do not, check whether the difference comes from archived projects, subtasks that were exported as separate rows, or tasks that were moved between projects during the export window. Write down every difference you cannot explain, because those gaps are the ones a migration team will hit later.
Next, sample tasks from at least three projects, including one large project and one with heavy use of subtasks. For each sampled task, compare the name, due date, assignee and parent task in Asana with the same fields in the CSV, and confirm the task ID column matches. Then open the gzipped JSON from the organization export, confirm the archive decompresses, and check that it contains the workspace records you expect, such as users, teams and projects. Use a text editor or a JSON viewer for the spot checks, and do not rely on an automated import as the test. The export only proves what it contains. A clean sample does not prove that attachments, automation rules, custom field settings, portfolios or permissions were exported, because the CSV export does not carry those and the organization export contents should be confirmed against Asana's organization export reference before you assume coverage.
Keep a dated record of every export: the date and time, who ran it, the workspace or project list, row and task counts, the checksum of each file, and the sample results. Store it with the files in a location your audit and migration teams can both read. Re-run the check on any later export so the team can see what changed. This record is also the baseline a migration partner will ask for when they plan the import, and it shows an auditor how the data was verified rather than just copied.
What to plan before the Asana renewal or termination date
The export is the easy part to start and the hard part to finish well. These cards cover the contract questions, ownership, storage, target import path and cost drivers that shape how you run the export before the date arrives.
Confirm post-termination data access
Ask Asana in writing how long you keep access to workspaces after the subscription ends, and whether exports remain available once billing stops. Check the contract terms and order form rather than relying on help center summaries. Record the exact date after which you lose access, because a failed export on the last day leaves no second attempt. Treat the answer as the deadline for the whole plan.
Assign one export owner
Name a single person accountable for running exports, checking completeness and signing off that the files are usable. Without an owner, per-project CSV runs get split across teams, and nobody notices that a project, attachment set or section structure was skipped. The owner should also hold the Asana admin or service account access needed for the organization export, which is limited to Enterprise+ service accounts.
Set storage and retention rules
Exported CSV and JSON files contain task notes, assignee names and project history, so they are personal and business data. Decide where they are stored, who can read them, how long they are kept and how they are deleted after migration. Keep a checksummed copy of each export run on storage you control, so the migration can be repeated if the target import fails partway.
Map the target import path
Choose the target before exporting, because the import route decides which export you need. Plane has an Asana importer on Plane Cloud and the self-hosted Commercial Edition, while OpenProject works from Asana's CSV project export. Test one representative project end to end, and compare fields such as sections, dependencies and attachments against what the target can hold.
Plan parallel running and cutover
Decide how long both systems run side by side, which team uses which tool for which projects, and how open tasks that changed after the export are reconciled. A freeze date on Asana edits, followed by a final delta export, avoids losing late changes. Write down who approves the cutover and what happens to Asana comments and attachments that do not transfer cleanly.
Price the components of the self-hosted target
Your cost depends on the target edition, the hosting model and admin time, not on a single license figure. Plane's Community Edition is AGPL-3.0, but moving to a paid plan requires the Commercial Edition and a license key. OpenProject's Community edition is free, while SSO, LDAP synchronization and portfolio features sit in Enterprise plans. Ask for each component separately in any quote.
Specify scope in writing for outside help
If you bring in an implementation partner, require a written scope before work starts. It should list the export runs and who performs them, the data inventory and which fields are in scope, the import test plan and sample projects, the handling of attachments and personal data, the hosting and backup responsibilities, the acceptance criteria and the hand-over documentation. Fixed deliverables and timelines make it possible to compare proposals fairly.
Questions buyers ask before exporting data from Asana
Can our team run the Asana export without outside help?
Yes, a team with an Asana admin and someone who can read CSV and JSON files can run the per-project CSV export themselves. The CSV export is run from each project's action menu, so the work is manual and repeats for every project. The organization export is different: it returns complete data as gzipped JSON and only service accounts of an Enterprise+ organization can run it, so the team needs that access before starting. Outside help is most useful when the export has to be verified, mapped to a new tool and documented for an audit trail. Confirm the access level and export format with Asana before you plan the work.
What makes an Asana data export harder or larger?
The main drivers are the number of projects, the number of tasks per project, attachments, custom fields, rules and the permission model. Each project is a separate CSV export, so a large workspace means more files to collect, check and reconcile. The CSV export carries task fields such as task ID, dates, name, assignee, due date, tags, notes and parent task, but attachments, rules and portfolios need separate handling. Custom fields with many options, nested subtasks and inconsistent naming add mapping work. Permissions decide which people can export which projects, so review access before the export begins.
How long does an Asana export take, and what sets the timeline?
The timeline depends on the scope of the export and on the target tool, and no fixed duration applies to every organization. The biggest factors are how many projects must be exported, how much attachment and custom field data needs to be checked, and how many people must approve the results. Scheduling the export around the Enterprise+ access request, the storage location and the verification owner also affects how quickly the work can start. Ask any provider for a written schedule based on your own project count and data inventory, and confirm it against the export tool you plan to use.
Is the Asana organization export available without an Enterprise+ plan?
No. According to Asana's developer documentation, the organization export that returns an organization's complete data as gzipped JSON is only available to service accounts of an Enterprise+ organization. Teams on other plans can still export individual projects to CSV from the project actions menu, but that route does not return the full organization dataset. If you need the complete JSON export, confirm your plan and service account eligibility with Asana before you commit to a migration timeline. The Asana developer documentation on organization exports sets out the requirements.
What does our team need to provide before an export starts?
Four things usually need to be in place before the export starts:
- Admin access to the Asana workspace or organization, with rights to export the projects in scope.
- A service account on an Enterprise+ organization if the complete JSON export is needed.
- Secure storage for exported files, including attachments, sized to the data inventory and placed under your own access controls.
- A named verification owner who signs off that task counts, dates, assignees and comments match the source.
Agree on these owners and locations in writing so that the export and its evidence stay under your control.
What does a scoped DeployOpen engagement cover compared with a DIY export?
A DIY export covers pulling files from Asana and storing them. A DeployOpen engagement is fixed-scope and agreed in writing before work starts, so its deliverables are set in the scope document. Typical scope items include inventorying projects and custom fields, running the exports, preparing the data for the target platform, checking the results with your verification owner and documenting the steps. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ask for the written scope and a quote based on your own inventory.
What do the CSV and JSON exports miss for a migration?
The CSV export is built for reading task data, so it does not capture everything a new tool needs. Expect gaps in attachments, comments history beyond the notes field, rules, portfolios, goals, custom forms and permission structures. The JSON organization export is more complete but still needs mapping to the target data model. Plane offers an Asana importer on Plane Cloud and on the self-hosted Commercial Edition, and OpenProject takes CSV project exports as a starting point, so check each target's import rules before deciding what to export. Compare the export output against the importer's supported fields for your own projects before the cutover date.
How DeployOpen scopes, delivers and supports an Asana data exit
DeployOpen treats an Asana export as a scoped piece of work, not a one-off download. We agree in writing which projects, fields and attachments leave Asana, where the extracted data lands in your own infrastructure, and how it is checked before any cutover to a self-hosted platform.
How we scope
- Inventory every Asana project, team and attachment set you need to keep, including which tasks carry dependencies, custom fields and subtasks.
- Confirm which Asana plan and service account access you have, since the organization export requires an Enterprise+ service account.
- Write down what the CSV project export will not carry, such as rules, portfolios and goals, so those gaps are agreed before work starts.
How we build
- Set up the extraction in your own cloud account or data center so exported JSON and CSV files never pass through a third-party tool.
- Script repeatable exports and record field mappings, so a re-run produces the same output for your reviewers.
- Validate row counts, assignees, dates and attachment links against the source projects before anything is loaded into a target platform.
How we hand over
- Deliver the export files, mapping tables and validation results in a documented format that your team and auditors can read.
- Document the gaps list, including what must be recreated by hand in the target tool, with an owner for each item.
- Walk your administrators through storage, retention and deletion of the exported data, so the copies you hold are under your control.
How we support
- Support after handover is available as a retainer, with scope agreed in writing for any re-exports or added projects.
- Re-run extractions when source data changes during a long migration window, using the same documented procedure.
- Ask us to confirm any Asana plan, export or API behavior against current vendor documentation for your own tenant before you rely on it.
