How to migrate from Asana to OpenProject without losing project history
Moving Asana projects into OpenProject is feasible for task names, sections, assignees, dates and notes, using Asana's per-project CSV export as the starting file. Dependencies, automation rules, portfolios, goals and some views do not carry over as data, so they must be rebuilt by hand or reconstructed from the export. Teams usually arrive here because of a renewal, a data residency requirement or concern about lock-in, and they need to know early which parts of the project history come across intact and which become a planning exercise. The export includes task ID, dates, name, assignee, due date, tags, notes and parent task, which covers the core of most project plans. It does not cover comments, attachments or activity history in a form that maps cleanly, so confirm those needs before you commit to a cutover date.
In practice, the work is usually done by an internal platform engineering or project management operations team, often with an implementation partner who handles the import scripts, the OpenProject installation and the reconstruction of Gantt timelines. The first decision is the mapping: decide whether Asana sections become work package hierarchy, phases or custom fields, and who owns each assignee once Asana users are matched to OpenProject accounts. Build a small pilot project, check the import against the source, and only then move the remaining projects. Plan for duplicate assignee accounts, date fields that were optional in Asana and dependencies that exist only as task links. Note that OpenProject's Jira Migrator is not an Asana path: it is in beta, supports only Jira Data Center 10.x and 11.x and does not support Jira Cloud, so it does not help with Asana data.
OpenProject Community is free to use and includes work packages, Gantt charts, agile boards, time tracking and dashboards, so licensing cost is not the main variable. Costs come from hosting, the installation and configuration effort, the migration scripting and testing, and the ongoing administration of upgrades and backups. Enterprise plans are needed for single sign-on, LDAP group synchronization and portfolio features, so ask any partner to state which of these you need and whether they are in scope. Ask for a written scope that names the source exports, the mapping rules, the pilot size, the validation steps and the acceptance criteria. Keep Asana read-only during the parallel run so that the history you signed off on remains the reference.
Which Asana features move cleanly to OpenProject work packages
This table maps Asana's main project features to their closest OpenProject equivalents and labels each as clean, needs rework or gap. Use it to scope which data moves from a CSV export, which needs manual rebuilding and which has no direct home in the Community edition. Confirm dependency and custom field import behavior against the current OpenProject documentation and a test export before you commit to a cutover plan.
| Asana feature | OpenProject equivalent | Migration status |
|---|---|---|
| Projects | Projects with work packages as the main work item | Clean: project names and structure carry over through import |
| Sections | Work package grouping, or parent work packages used as phases | Needs rework: sections are not a native import field, so map them to a column or parent item |
| Tasks and subtasks | Work packages with parent-child relations | Clean: hierarchy can be preserved, but confirm depth and relation import in a test export |
| Assignees | Work package assignee field tied to project members | Needs rework: users and project memberships must exist before assignment |
| Due dates and start dates | Work package start and finish dates | Clean: date fields map directly; check time zone and blank date handling |
| Dependencies | Predecessor and follows relations | Needs rework: confirm how the CSV export expresses dependencies and whether they import |
| Timeline view | Gantt chart in the Community edition | Needs rework: rebuild the Gantt view from imported dates and relations |
| Boards | Agile boards in the Community edition | Needs rework: recreate board columns and filters by hand |
| Tags | Labels or custom list fields | Needs rework: map tags to a custom field and check the import behavior |
| Notes and attachments | Work package description and attachments | Needs rework: CSV export carries notes text, but attachments must be retrieved separately |
| Custom fields | Custom fields on work packages | Needs rework: basic custom fields are the reliable target, so confirm types in a test export |
| Portfolios and goals | Portfolio and program management in Enterprise plans | Gap in Community: portfolio views need an Enterprise plan and rebuilding by hand |
| Rules and automations | Workflows and notifications, not one-to-one rules | Gap: Asana rules must be recreated or dropped and tested |
What data can leave Asana and what must be rebuilt
Asana gives you two documented ways to take data out, and neither moves everything. Plan the migration around what the export carries and treat integrations, attachments, rules and portfolios as work to rebuild or confirm in OpenProject.
Per-project CSV export
Each Asana project can be exported to CSV from its project actions menu. The file carries task ID, dates, name, assignee, due date, tags, notes and parent task, which covers the core of a task list. Map the parent task column to OpenProject parent work packages, and confirm how Asana sections are represented in your export before you decide where they become groups or phases.
Organization export limits
The complete organization export returns gzipped JSON, but only service accounts in an Enterprise+ organization can run it. If your account is on a lower plan, the CSV route is your documented path. Ask your Asana administrator whether that export is available to you before you plan around it, because it is the only route that carries a fuller picture of the workspace.
API extraction for custom needs
Asana's API provides a programmatic route when the CSV fields are not enough, for example to pull custom field values, subtasks at depth or comments in a structured form. Someone must write and run that script, handle pagination and rate limits, and validate the output against Asana before import. Budget that engineering as a separate item from the OpenProject work.
Attachments need a separate pull
Attachments are not part of the CSV export, so files attached to tasks must be downloaded and re-attached in OpenProject. Confirm the file count and total size per project, check which links point to external storage, and decide whether those files move into work package attachments or stay in a linked file store such as Nextcloud.
Integrations and rules to recreate
Asana rules, automations and integrations with tools such as Slack, Google Drive or Jira do not transfer with the project data. List every active rule and connected app, then rebuild the ones you still need in OpenProject with its own notifications, webhooks or automation options. Confirm each feature exists in your OpenProject edition before you commit.
Portfolios, goals and permissions
Portfolios, goals, custom fields and team membership structures sit outside the task export and must be modeled by hand. Rebuild the portfolio view as OpenProject projects or programs, reassign roles and groups, and review which features need an Enterprise plan such as SSO or LDAP sync. Record each decision so reviewers can trace how access was set.
Migration sequence from Asana inventory to decommission
This sequence moves Asana projects into OpenProject in stages, so each mapping is tested on a pilot, reconciled against the source, and signed off before the Asana workspace is frozen and retired. Each step produces a named artifact that the next step depends on.
Inventory projects, owners and fields
Start by listing every Asana project in scope, with its owner, team, number of tasks, sections, custom fields, tags, subtasks and dependencies. Run a CSV export for each project from the project actions menu, and note which fields the export includes and which it leaves out, such as attachments and comments that need separate handling. Record the result in an inventory sheet, then ask each owner to confirm which projects still need to move and which should be archived. This step is done when every in-scope project has an owner sign-off and a row in the inventory.
Build the field and mapping sheet
Using the inventory, write the mapping tables that connect Asana concepts to OpenProject: sections to work package groups or statuses, assignees to OpenProject users with matching email addresses, due dates and start dates to work package dates, tags and custom fields to types, attributes or custom fields, and parent tasks to parent-child work packages. Mark every field that has no direct equivalent and decide how it will be kept, such as in a description or a custom field. The output is a signed field mapping sheet that the pilot will test.
Run a pilot in a test OpenProject instance
Install OpenProject in a test environment that matches the production design, then import one representative Asana project using the mapping sheet and the CSV files. Review the imported work packages against the source, including hierarchy, assignees, dates, Gantt dependencies and any comments added by hand. Adjust the mappings and repeat the import until the pilot project reads the same in both tools. Because OpenProject's own Jira Migrator is in beta and does not cover Asana, expect to build this import path yourself or with an implementation partner. The output is a pilot reconciliation report listing each difference and how it was resolved.
Import the full project set and reconcile
Import the remaining projects in batches, following the approved mapping sheet and the rules proven in the pilot. After each batch, compare task counts, assignee totals, date ranges and parent-child structure between the CSV export and OpenProject, and log any exceptions. Confirm that Gantt charts show the dates and dependencies your teams expect, and that attachments and comments were moved or linked as agreed. The output is a reconciliation report per project with a sign-off from the project owner.
Run a parallel period with both tools live
Keep Asana and OpenProject open at the same time for a period agreed with the business owners, and direct new work to OpenProject while Asana remains the record for anything not yet migrated. Track users who report missing tasks, duplicate items or permission gaps, and fix the import or the OpenProject configuration accordingly. Confirm that single sign-on, user provisioning and any notification settings work as intended for the users involved, noting that SSO and LDAP synchronization are Enterprise features. The output is a parallel run log with every open issue closed or accepted.
Freeze Asana and approve the cutover checklist
Produce a final CSV export of every in-scope project after the last working day of parallel use, and run the final import and reconciliation against it. Set Asana projects to read-only or restrict edit access according to the Asana admin settings available on your plan, and communicate the cutover date to users. Approve a cutover checklist that covers the final export, reconciliation, user access, backup of the OpenProject database and support contacts. The output is an approved cutover checklist with named approvers and the frozen export stored in the retained archive location.
Decommission Asana and retain archives
After the cutover checklist is complete, remove Asana users and integrations that are no longer needed, and confirm with the subscription owner when the commercial agreement ends. Store the frozen CSV exports, the mapping sheet, the reconciliation reports and the cutover approval in a retained archive that your records policy governs, and confirm how long your organization must keep them. Ask Asana, in writing, how it handles your data after cancellation before you rely on that answer. The output is a decommission record that lists what was removed, where archives are held and who approved the closure.
How the migration changes by team size and starting point
A small team with a handful of Asana projects usually gets the most value from a manual rebuild. Export each project to CSV from the project actions menu, review the task rows, and recreate the work in OpenProject as work packages in the free Community edition. The CSV carries task names, notes, assignees, dates, tags and parent tasks, so the structure is already on paper when you start. Recreating a few projects by hand keeps the team in control of which tasks come across, and it lets people clean up stale work instead of carrying it into a new tool.
- Scope the projects first: Decide which projects are active and which can be archived in Asana, so the rebuild covers only current work.
- Map sections to phases or types: Treat Asana sections as work package grouping, and decide whether they become phases, parent work packages or filtered views.
- Rebuild dates and dependencies by hand: Enter start and due dates on work packages and set predecessor relations so the Gantt chart reflects the plan.
- Keep SSO out of scope at first: Community edition has no SSO, so accounts are local until you decide whether an Enterprise plan is needed.
Before you start, confirm with OpenProject which features your team needs from the Community edition and which need an Enterprise plan.
A mid-size organization with many projects, shared templates and dozens of people per workspace is unlikely to finish a manual rebuild cleanly. The practical route is scripted extraction: call the Asana API to pull projects, tasks, sections, custom fields and users, store the results in a staging format, then transform them into OpenProject work packages through its API. The effort sits mainly in mapping and validation rather than in typing, and it recurs for each batch of projects you move. Expect to test on a pilot project before running the full set.
- Build a mapping table: Record how each Asana field maps to an OpenProject field, status, type or custom field, and keep it under version control.
- Match users before importing: Map Asana assignees to OpenProject accounts, and decide how to handle people who have left the organization.
- Plan for Enterprise features if needed: LDAP group synchronization and SSO are Enterprise features, so account mapping may depend on which plan you buy.
- Use portfolio features selectively: Portfolio and program management sit in paid Enterprise plans, so confirm whether you need them before you rebuild Asana portfolios.
Ask your implementation partner to estimate the scripting effort for your data volume and to write the validation checks before any production import.
An Enterprise+ customer can run the organization export, which returns the organization's complete data as gzipped JSON. This route captures more than the per-project CSV, so the extraction stage is more complete, but the JSON still has to be parsed and mapped to OpenProject before it can be imported. The export is limited to service accounts of an Enterprise+ organization, so confirm with Asana that your account can run it and that your security team approves the storage and handling of the output file.
- Confirm who can run it: Only service accounts of an Enterprise+ organization can start the export, so check access before planning the work.
- Treat the file as sensitive: The export contains the organization's complete data, so store it encrypted and restrict access to the people doing the migration.
- Parse before mapping: Build a parser for the JSON structure, then map the results to work packages, users and relations in the same way as a scripted extraction.
- Plan identity and access early: SSO, LDAP group synchronization and SCIM provisioning are Enterprise features in OpenProject, so decide on the identity model before user records are created.
Confirm the export's contents and format with Asana's documentation and your own data owners, since the exact structure should be checked against your organization before you design the mapping.
What drives the cost and duration of an Asana to OpenProject move
This table lists the main drivers behind the effort and cost of moving Asana work into self-hosted OpenProject, with the cost component each one affects. Use it to see which inputs your quote must state, since the scope, not the software licence, usually sets the total.
| Driver | Why it changes cost or effort | How to keep it down or what to confirm |
|---|---|---|
| Number of projects and tasks | Each Asana project needs a CSV export, mapping to types and statuses, and a check of imported work packages. Volume drives import runs, cleanup and reconciliation time. | Archive completed or stale projects before export. Ask the quote to state project and task counts from an inventory. |
| Dependency density | Asana dependencies must be recreated as OpenProject work package relations so Gantt charts show the right sequence. Dense chains need manual review. | Export dependency data where your Asana plan allows it, and confirm with DeployOpen how relations will be rebuilt and verified. |
| Custom fields and tags | Asana custom fields and tags have no one-to-one match. Each needs a decision: a work package attribute, a custom field, or a type. Mapping choices multiply test cycles. | Limit mapping to fields used in reporting. Ask for a field-mapping table as a written deliverable before import. |
| Attachments and comments | Asana CSV exports do not carry attachment binaries, so files must be retrieved and re-attached through separate steps. Storage and transfer time grow with file volume. | Confirm the attachment retrieval method, storage location and total size in your environment before scoping. |
| Portfolios, goals and rules | Asana portfolios, goals, rules and forms are not part of a CSV project export and must be rebuilt as OpenProject views, programs or automations. Rebuild effort depends on how many exist. | Inventory each rule and portfolio by owner. Decide which ones the new setup must reproduce. |
| Identity mapping | Assignees, guests and inactive accounts must map to OpenProject users. Matching by email across identity sources adds review work. | Ask for an agreed user mapping list. Confirm whether SSO or LDAP sync is in scope, since those need Enterprise plans. |
| Hosting size and OpenProject sizing guide | OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Larger user counts raise infrastructure and admin cost. | Match the user count to the sizing tier. Ask the quote to separate infrastructure you provide from services DeployOpen provides. |
| PostgreSQL 16 setup and extensions | OpenProject supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Database provisioning, backups and upgrades are a recurring operational task. | Confirm whether you have a managed PostgreSQL service able to enable these extensions, or whether a self-managed database is needed. |
| Enterprise plan choice (per-user pricing) | The Community edition is free. Enterprise on-premises plans are priced per named user per month: Basic at 5.95 euros, Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users (OpenProject pricing page). This is a recurring cost. | Compare the features you need, such as SSO, LDAP group sync or portfolio management, with the tier. Confirm current prices on the OpenProject pricing page before budgeting. |
| Parallel run length | Running Asana and OpenProject side by side adds licence cost for the overlap period and doubles some update work. The length is set by your cutover policy, not by the tool. | Agree the parallel period and cutover criteria in writing. Ask the quote to show who keeps each system updated during the overlap. |
What usually goes wrong when moving Asana work to OpenProject
Most Asana-to-OpenProject problems come from the export itself, not the import. CSV exports carry a limited set of fields, so dependencies, hierarchy, identities and dates need deliberate handling before any data moves. The cards below cover the risks we see most often and a check to run against each one.
Dependencies dropped in transit
Asana's CSV export includes task fields such as parent task, dates and assignee, but dependency links are not a column you can rely on for a full rebuild. Relationships that exist only in Asana's timeline view can disappear silently. Before import, list every dependency from the timeline view and record it in a spreadsheet, then recreate those relationships as work package relations in OpenProject's Gantt chart and check each one against the source project.
Subtask hierarchy flattened
Asana tasks can nest subtasks several levels deep, and a flat CSV import can place every item at the same level. The parent task field in the export shows the link, but it is not an import instruction. Map each Asana parent to an OpenProject parent work package before you load data, and spot-check that the outline in OpenProject matches the Asana list view for at least one deep branch.
Assignees that do not match accounts
The assignee column in the export holds names or emails as Asana recorded them, which may differ from the accounts in your identity provider or from the OpenProject user list. Unmatched assignees leave work unowned or create duplicate users. Build a mapping table of Asana email addresses to OpenProject accounts and confirm it with team leads before import. Keep in mind that SSO and LDAP synchronization are Enterprise features, so account matching is a manual step on Community.
Dates shifted by timezone
Due dates exported from Asana are date values, but tools that parse them with a timezone can move tasks by one day, especially for teams spread across regions. The effect is subtle: Gantt bars look right in summary but milestones land on the wrong day. Load a small test project first and compare start and due dates for ten tasks across at least two timezones against Asana before loading the full dataset.
Attachments and comments left behind
CSV exports carry task text and metadata but do not reliably carry the files attached to tasks. Attachments stored in Asana may need to be downloaded separately and re-attached, and comment threads may not transfer in full. Ask whether your import method keeps attachments and comments, and record the count of attached files per project in Asana so you can confirm the count in OpenProject after load.
Rules, forms and automations not rebuilt
Asana rules, forms and approval workflows do not move with a project export. Teams often assume that automations will keep running, then discover that intake forms and status notifications have stopped. Inventory every rule and form in each project before cutover and decide, for each one, whether OpenProject's workflows, notifications or an external automation tool will replace it. Recreate and test them in a staging instance.
Work kept in both tools
The most expensive failure happens after the import: some teams keep updating Asana while others start in OpenProject, and the two copies drift apart. Set a cutover date per project, freeze Asana for write access on that date, and keep the export file as the agreed record. Name one owner per project who signs off that the OpenProject copy is the working copy.
Questions buyers ask before moving from Asana to OpenProject
How much effort and cost does a move from Asana to OpenProject involve?
The effort depends on the cost components, not on a fixed figure. OpenProject's Community edition is free to download and run, so the main costs are the infrastructure you host it on, the Enterprise subscription if you need SSO or LDAP sync (priced per named user per month on OpenProject's pricing page), the time to export and clean Asana data, the time to build the OpenProject project structure, and the admin time to run the system afterward. Costs rise with the number of projects, the amount of custom field and dependency data, the number of users who need Enterprise features, and the number of environments you run. Ask for a quote built from a written scope that lists each of these components separately.
How long does it take to move projects from Asana to OpenProject?
Duration is set by the volume and complexity of the data, the number of people who must validate it, and how much of the timeline has to be rebuilt by hand. No supplied figure gives a standard duration for an Asana move, so treat any number you hear as a claim to test. Factors that lengthen the work include many projects with custom fields, tasks with dependencies that must become Gantt relationships, portfolios and goals that need to be recreated, and integrations you have to re-create. Ask for a phased plan with a pilot project first, then confirm the sequence and acceptance criteria in the written scope before work begins.
What does our team need to provide for an Asana to OpenProject migration?
You need to provide access to the Asana data, a named owner who can decide how sections, tags and assignees map to OpenProject, and people who can confirm that migrated work packages match what they tracked. In practice that means CSV exports from each project, or an organization export if your Asana plan allows one, plus a list of active users so assignees can be matched to OpenProject accounts. You also need a hosting environment, such as Docker on a Linux host, that meets OpenProject's system requirements. Confirm each of these inputs with OpenProject and your own infrastructure team before scheduling.
Can our own admins migrate Asana projects to OpenProject without a partner?
Yes, a capable internal team can do the work, but it helps to be honest about the skills required. Your admins need to run OpenProject on Docker or a supported Linux package, manage PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, handle backups and upgrades, and write a mapping from Asana's CSV fields to work packages, statuses, types and dates. Asana's CSV export does not bring over everything, so someone must decide how to handle items that are not carried across. If your team has no time for this, an implementation partner can plan, implement and document the move under a fixed-scope agreement.
Does the OpenProject Jira Migrator work for moving data from Asana?
No. The OpenProject Jira Migrator imports only from Jira Data Center 10.x and 11.x, and it does not support Jira Cloud or any other source, including Asana. It is also in beta, and OpenProject's documentation advises using it only in test setups. For Asana, the practical route is the CSV export from each project, mapped into OpenProject work packages, with a script or manual import that you test on a copy first. Check the current OpenProject migration documentation before you plan any tooling, because the supported sources can change between releases.
What do the OpenProject Enterprise plans add over the Community edition?
Enterprise plans add features that matter to larger organizations, while the Community edition already includes work packages, Gantt charts, agile boards, time tracking and dashboards. According to OpenProject's pricing page, Enterprise features include single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding. The pricing page also lists SCIM provisioning and portfolio and resource management in paid plans, and the Jira Migrator sits under Enterprise plans from Basic upward. On-premises plans are priced per named user per month, with minimum user counts for some tiers, so confirm the current tier and user count in writing.
What should we check after migrating Asana tasks into OpenProject?
Check that every project, section-derived grouping, assignee, due date and dependency arrived where your team expects it, and that nothing was silently dropped. Compare sample projects field by field, confirm that archived or completed tasks were handled as you intended, and verify that Gantt charts reflect the dates your team actually planned. Also test user access and permissions, since OpenProject roles differ from Asana's team and project membership. Record these checks as evidence for your change log, and agree on acceptance criteria with the project owners before you retire Asana access.
Who keeps OpenProject running after the migration is complete?
Your organization owns the running system, whether the work is done in-house or by a partner. Ongoing tasks include applying OpenProject releases, such as the 17.9.x series, keeping PostgreSQL and the host operating system supported, monitoring capacity against OpenProject's sizing guide, and maintaining backups and restore tests. Support depends on your edition, since the Community edition comes with community support and Enterprise plans include vendor support. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which you can scope separately from the initial migration.
How DeployOpen scopes and runs an Asana to OpenProject migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted OpenProject inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. For an Asana move, the scope document should name the projects in play, the Asana export method for each (per-project CSV or the organization export, which only Enterprise+ service accounts can run), the target edition, and who signs off each stage. The first decision to settle is the edition: the free Community edition covers work packages, Gantt charts and boards, while SSO, LDAP group synchronization and custom branding sit in paid Enterprise plans. Confirm that choice with your identity and procurement teams before the scope is written.
The written scope should also split the work between the stages where errors usually appear. These are the mapping of Asana sections, assignees, due dates and dependencies onto OpenProject work packages, the rebuild of timelines as Gantt charts, a test import into a non-production instance, and a reconciliation of task counts and owners against the Asana source. Because OpenProject's Jira Migrator does not support Asana, DeployOpen would treat the Asana import as a scripted or manual process, and the scope should say so plainly. Ongoing support, upgrades and continuous testing are available as retainers, which is useful if you want someone to handle OpenProject release upgrades after go-live. No price list is published. A quote follows from the written scope, so ask for the cost components to be itemized: discovery, mapping and import work, hosting and hardening, documentation, and any retainer. DeployOpen is not an OpenProject partner or reseller, and it does not issue audit reports or certifications.
