Migrate from OpenText Project and Portfolio Management (PPM) to Asana

OpenText Programs (top-level containers grouping related projects) map to Asana Portfolio if the customer uses them as executive-level governance containers, or to an Asana Project if the customer uses Programs as delivery-level units. We determine the mapping during scoping by reviewing the customer's OpenText Program usage patterns. Program-linked financial rollups, stage-gate lifecycle status, and owner assignment migrate to custom fields on the destination Portfolio or Project.

OpenText Projects map directly to Asana Projects. We preserve project name, description, start and end dates, status, owner assignment, and cross-project dependencies. Dependencies in OpenText (finish-to-start, start-to-start, finish-to-finish, start-to-finish with lag) map to Asana dependencies using the Dependents API field. Custom fields on OpenText Projects migrate to Asana project-level custom fields.

OpenText Tasks map to Asana Tasks within the target Project. Start date, due date, percent complete, priority, assignee, and description transfer directly. Task hierarchy (WBS levels) migrates as subtasks in Asana where the nesting depth is preserved. We note that Asana does not support multi-level task numbering; if the customer uses WBS codes in OpenText, those migrate as custom text fields.

OpenText Portfolios (top-level governance aggregations above Programs) map to Asana Portfolios. Portfolio-level financial cost lines and budget allocations migrate to custom fields on the Portfolio. Portfolio custom fields in Asana are scoped to the Portfolio level only and do not cascade to child Projects or Tasks; they are a completely separate field namespace from project-level custom fields.

OpenText Resources (staff members, equipment, or capacity units) map to Asana Members. We resolve OpenText resource_email or owner_email to an Asana user account. OpenText skill profiles and availability calendars do not have a native Asana equivalent; skill data migrates as a multi-select custom field on the Asana user profile, and availability data is flagged as requiring manual reconstruction in Asana's workload view.

OpenText budget cost lines, benefit lines, and financial rollups have no native Asana equivalent. We migrate available financial data as numeric custom fields (Budget, Actual Cost, Forecast, Benefit) on the relevant Asana Project or Portfolio. Top-down budget allocations migrate as custom fields with the budget type; actuals migrate as updateable fields for post-migration tracking. If the customer requires ongoing financial management, we recommend a dedicated finance tool integration (NetSuite, Excel connector, or a budgeting platform) as part of the post-migration workflow.

OpenText Demands (incoming work requests or ideas) have no direct Asana equivalent. Active Demands with clear scope migrate as Asana Projects; ill-defined Demands or ideas migrate as Tasks in an intake project that the customer's PMO maintains. Approval status and priority migrate as custom fields. The customer plans a replacement intake process (Asana form, Jira Service Management intake, or manual triage) as part of post-migration setup.

OpenText Requests (workflow items in the demand-management intake process) migrate as Tasks in the intake Project. Submission data, requestor, approval status, and request type migrate as standard or custom fields. Workflow state transitions from OpenText (e.g., Submitted, Under Review, Approved, Rejected) migrate as a custom picklist field representing the request lifecycle.

OpenText time entries logged against Projects or Tasks migrate as Task-level notes or a custom duration field in Asana. Approval history on timesheets is not always fully exportable and is flagged as a partial-migration item. Asana does not have a native timesheet approval workflow; if the customer requires this, we recommend a separate time-tracking integration (Harvest, Toggl, or a custom Asana form-based timesheet process) post-migration.

Documents attached to OpenText Projects or Tasks are extracted from OpenText's file management layer and uploaded to the corresponding Asana Project or Task as attachments. We handle the binary file transfer in a parallel stream to the record migration, preserving the association to the correct project or task. OpenText's internal document versioning does not transfer; the latest version of each document migrates without version history.

OpenText project-level and task-level dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish with lag) migrate as Asana dependencies using the Dependents field on Tasks. Lag values transfer as custom numeric fields where needed. Cross-project dependencies are fully supported in Asana; the destination project must exist before the dependency reference is resolved, so we sequence project migration to resolve references before dependent records are created.

OpenText custom properties on Programs, Projects, Tasks, Resources, Demands, and Requests are enumerated during the pre-migration schema discovery pass. Each custom property maps to an Asana custom field of the matching data type (text, number, date, picklist, multi-select). Portfolio-level and project-level custom fields in Asana are separate namespaces; we assign each OpenText custom property to the correct destination scope. Tier or edition constraints on custom field limits are reviewed during scoping (Asana Starter allows 15 project-level custom fields; Business and Enterprise allow 100+).