Migrate from OpenProject to Asana

OpenProject Projects map to Asana Teams (for organizational grouping) or Workspace Projects (for work scope). If the OpenProject instance uses project hierarchies or parent-child project structures, we map the top-level project to an Asana Team and child projects to Projects within that Team. Project permissions via Member-Role assignments are not directly migratable to Asana's member-per-project model, so we add all identified project members to the corresponding Asana project during migration and document the original role matrix for the customer's admin to reconfigure in Asana.

OpenProject Work Packages map directly to Asana Tasks. Each task receives the original Work Package subject, description (as rich-text notes), start and due dates, estimated hours, and custom field values. Parent-child Work Package relationships map to Asana Subtasks (for single-level nesting) or the parent task's task dependencies (for cross-branch hierarchies). Assignee maps to the Asana assignee by resolving the OpenProject user email to the migrated Asana user. Responsible maps to the Asana task's follower list or, if the destination uses a custom field, to a responsible-person custom field.

OpenProject Work Package Types (Task, Bug, Feature, Phase, Milestone) are customizable per project. Asana has no native Task Type equivalent, so we create a dropdown custom field named Task Type on the destination project and populate it with the source Type names. Type-specific field visibility rules (which fields appear per Type) do not migrate; we document the original configuration and recommend Asana custom fields or project-level templates as the equivalent.

OpenProject Statuses (New, In Progress, Closed, etc.) and their Type-specific workflow transitions are configurable. Asana uses Sections for visual grouping and task status fields for automation triggers. We map OpenProject Status to an Asana Section per project, placing each task under the section matching its status. If the customer uses Asana Status (the beta structured status feature), we map statuses to those values. Workflow transition rules (which transitions are allowed per Type) do not migrate and are documented for the admin to rebuild in Asana's task dependency rules if needed.

OpenProject Versions (milestones or sprints) group Work Packages and carry target dates. Asana has no native Version object. We map Versions to Asana Projects (for multi-sprint scenarios) or, more commonly, to Sections within a single project named after the Version. Version target dates migrate as due dates on a milestone task created within the corresponding Section. If the customer uses OpenProject's sprint feature with burndown charts, we document the sprint structure and recommend Asana's Timeline and Workload views as the reporting equivalent.

OpenProject custom field definitions (name, type, options, required flag) are instance-specific and do not exist in Asana by default. We extract the full custom field schema during discovery, pre-create equivalent custom fields in the destination Asana project (text, number, date, person, or enum types matched to the OpenProject type), and map values during the task migration. Dropdown options from OpenProject list-type custom fields become Asana enum choices. Required-flag enforcement is not migratable; we document required fields for the admin to set in Asana project settings post-migration.

OpenProject Boards store Kanban-style columns derived from Work Package queries and store column-to-status mappings as view metadata. Asana does not have a native Kanban board separate from its list view, but its Sections simulate column grouping. We map OpenProject board columns to Asana Sections named for the original column, preserving which status values land in which column. Board card ordering within columns does not migrate; we sort tasks by the original OpenProject work_package rank field within each Asana Section.

OpenProject time entries log hours against Work Packages with cost type and rate. Asana Business and Enterprise tiers include built-in per-task time tracking; Standard and Premium tiers do not. For destinations without native time tracking, we export time entries as a CSV structured by Work Package ID, user, date, hours, and cost type, and attach it to the corresponding Asana task as a reference document. For Asana Business/Enterprise destinations, we migrate time entries as Asana time tracking entries using the Asana API's time tracking endpoints. Note: OpenProject logs in hours only with no day-based option; we preserve this faithfully.

OpenProject Cost Entries track unit costs and rates against Work Packages with configurable cost types per instance. Asana has no native cost tracking. We export Cost Entries as a structured CSV keyed to Work Package ID, including cost type, unit cost, quantity, and total cost, and attach it to the corresponding Asana task. For customers who need cost reporting in Asana, we recommend Asana's Workload view combined with a connected spreadsheet or an AppExchange cost-reporting integration, and we document the recommended configuration in the handoff document.

OpenProject Wikis store formatted content per project with embedded work package lists. Asana has no native wiki. We export each OpenProject wiki page as an HTML file (preserving heading structure, text formatting, and embedded links) and attach it to the corresponding Asana project. Embedded work package references convert to task links using the migrated task IDs. The customer can host the exported HTML in a linked Confluence, Notion, or Google Docs page if ongoing wiki access is required.

OpenProject Forums and their message threads (author, timestamp, content) migrate as structured attachments. Each forum becomes a JSON file containing the thread hierarchy, author, post timestamps, and message body, attached to the relevant Asana project. If the customer uses forums primarily for team discussion rather than archival, we recommend replacing them with Asana's task comment threads or a connected Slack channel; we document the recommended mapping in the handoff document.

OpenProject Documents are project-level file containers with title, description, and attached files. We migrate the document metadata (title, description, attached-by user) and their binary attachments to the corresponding Asana project. Large files (over 100 MB) may require out-of-band transfer via shared storage if Asana's attachment size limits are encountered; we handle this in coordination with the customer during migration.

OpenProject users carry email, name, login, admin status, and global roles. We map user accounts 1:1 by email address. If a user exists in OpenProject but not yet in Asana, we create a placeholder user record and flag it for the customer's admin to provision or deactivate. Work package ownership, time entries, and forum posts are reassigned to the corresponding migrated user during migration.

OpenProject Members are user-project assignments carrying a Role. Roles define permission sets per project. Asana project membership has two levels: Member (can view and edit tasks) and Guest (limited access). We map all OpenProject Member-Role assignments to Asana project Members and document the original Role matrix in the handoff document so the admin can configure Asana's advanced member permissions or third-party permission tools post-migration.

OpenProject attachments on Work Packages, Wiki pages, and Documents are stored either in the database (small files) or on disk (large files). We extract attachment metadata and binary content, then attach files to the corresponding migrated Asana task. Disk-path remapping is handled during extraction; URL references in wiki content are updated to point to the migrated attachment location. We flag any attachment exceeding Asana's size limit for manual out-of-band transfer.