Migrate from OpenProj to Asana

OpenProj Projects are top-level containers that hold modules, members, and roles. Asana uses a two-level structure: a Workspace (organizational unit) containing Projects. We map each OpenProj Project to an Asana Project within the customer's primary Workspace. Project-level members and roles migrate as Asana project members with project-level permissions. OpenProj's module activation flags have no Asana equivalent; we note which modules were active per project as a project description annotation so the customer's admin knows which feature set to replicate.

Work packages are the core task entity in OpenProj with a fixed schema of type, status, priority, subject, description, assignee, responsible, start date, due date, estimated hours, and spent time. We map each work package to an Asana Task, preserving subject as name, description as notes, start/due dates as start and due dates, and the original OpenProj type and status as tags. Estimated hours and spent time migrate as custom fields since native Asana time tracking requires a paid add-on. The OpenProj priority field maps to the Asana priority numeric or enum field.

OpenProj types (Task, Feature, Bug, Milestone, Phase, Epic, User Story) are defined globally and assigned per work package. We extract the full type list from OpenProj and create corresponding Asana tags with matching names. Each work package in Asana receives a tag from this migrated type list so that type filtering works identically in both platforms. Custom types created in the OpenProj Enterprise edition are preserved in the same way.

OpenProj statuses (New, In Progress, Closed, etc.) are globally defined with optional per-type workflow configuration. We extract the active status list and map each to an Asana Section within the destination project, placing each task in its corresponding section based on the migrated status value. For Asana tiers that support custom status fields natively, we use the custom status enum instead of sections to preserve workflow-level semantics more precisely.

OpenProj Enterprise custom fields (text, integer, float, Boolean, list, date, user, hierarchy) map to Asana custom fields at the project level. We pre-create the destination custom field schema in Asana before migration, matching field types as closely as possible. Note that Asana custom fields are per-project by default; portfolio-level custom fields require the Advanced tier. Enterprise OpenProj custom fields that use the user type map to Asana people fields; hierarchy types map to subtasks or multi-select lists depending on the structure depth. Custom field values that exist only in OpenProj Enterprise are preserved as text notes if no matching Asana field type exists.

OpenProj time entries store hours, rate, and cost linked to work packages. Asana does not have a native time-tracking entity at the task level in its free and lower tiers; we map time entries to a numeric custom field on each task with the field name matching the source label (e.g., Hours Logged or Spent Time). The original cost value is stored in a companion currency or number field. Customers on Asana Advanced can add the native time-tracking add-on post-migration and map these values into it.

OpenProj files are attached to work packages, wiki pages, or projects. We migrate file metadata (filename, mime type, author, created-at) and download file content via the OpenProj API, then upload to Asana as a task or project attachment via the Asana Attachments API. OpenProj's API limits file link creation to 20 per request; we pre-scan for work packages with more than 20 attachments and batch them into chunks of 20 during migration. File associations are maintained throughout the batching process.

OpenProj users have a fixed schema of name, email, login, admin flag, and avatar. We map users by email match against the destination Asana workspace. Admin users in OpenProj receive Admin privileges in Asana where applicable. Any OpenProj user without a matching Asana account goes to a reconciliation queue for the customer to provision before the membership migration phase begins.

OpenProj memberships assign a user to a project with a specific role. We map project memberships to Asana project members. OpenProj's role-permission model (global roles and per-project membership) maps to Asana's project-level member roles (Editor, Commenter, Viewer). Where a user held multiple roles across projects, we preserve all role assignments. Note that Asana does not have a global admin-role assignment system outside of Organization-level admin; we flag any globally scoped permissions that require manual assignment post-migration.

OpenProj wiki pages belong to a project and store Markdown content with attachments. Asana has no native wiki module; we migrate wiki page content as the Asana project description field. Pages with significant content are split into separate tasks within the project, with the page title as the task name and the full Markdown content in the task notes. Any wiki attachments are linked to the corresponding Asana task or project attachment. Customers who rely heavily on wikis should consider connecting Confluence or Notion via an Asana integration post-migration.

OpenProj meetings hold title, date, duration, location, attendees, and minutes text as a first-class object. Asana has no native meeting module. We migrate meeting records as tasks with the meeting title as the task name, date and duration in the start and due fields, and minutes content in the task notes. Attendee information is stored as a custom field or tag. Customers who need native calendar integration can connect Google Calendar or Outlook via the Asana integration directory to surface meeting tasks alongside existing calendar entries.

OpenProj versions (milestones) group work packages and carry a name, description, status, and target date. We map each version to an Asana Milestone attached to the corresponding project. The version description migrates to the milestone notes field, and the target date maps to the milestone due date. Work packages assigned to the version receive an Asana dependency rule linking them to the milestone task so that completion tracking remains intact.

OpenProj cost entries store labour costs, unit costs, and budget values per work package. Asana has no native budget or cost-tracking entity. We migrate available cost data as numeric custom fields on the corresponding Asana tasks (e.g., Estimated Cost, Actual Cost, Budget Variance). Customers with complex cost tracking needs should plan to use the Asana Premium + Resource Management add-on post-migration, which supports capacity planning and budget tracking at the project portfolio level.

OpenProj dependency chains (precedes, follows, blocks, blocked by, copied to, duplicated by) link work packages in a dependency graph. We map these to Asana task dependencies using the Asana dependencies API, preserving the dependency type as a tag on the dependent task. Note that Asana supports blocks and blocked-by semantics through its standard dependency types (predecessor and successor). Circular dependency detection is performed during scoping and flagged before import so that no invalid dependency chain blocks the migration.