Migrate from Oracle Project Management Cloud to Asana

Oracle Projects map to Asana Projects as the top-level container. The Oracle Project Number, Name, Status, Project Manager, Start Date, and End Date transfer directly. Oracle classifications (Project Type, Project Template, and transaction controls) map to Asana custom fields. Active Projects migrate as active; Closed Projects migrate at the customer's request only if they carry pending financial transactions, link to active Programs, or are referenced by billing records in scope.

Oracle Project Tasks with WBS hierarchy migrate to Asana Tasks. The WBS parent-child relationship maps to Asana's section and subtask nesting: Oracle task parents become Asana parent tasks with subtasks preserving the WBS depth structure. Oracle task codes, names, planned start and finish dates, and task type (type of work) transfer to Asana task fields and custom fields. Task Followers from Oracle migrate as task assignees in Asana; the subscription-style notification model does not have a direct equivalent so we map followers to the assignee set.

Oracle Resources assign people or equipment to Tasks with allocation percentage, role, and assignment dates. Asana has no standalone resource pool: assignees are embedded at the task level. We resolve Oracle Resources to Asana workspace members by email match, then attach each resolved resource to the corresponding task as an assignee. Oracle role and allocation percentage map to Asana custom fields. If a task has multiple Oracle resources at different allocation percentages, we create multiple assignee entries with a custom allocation custom field to preserve the split.

Expenditure Batches are cost transactions imported from subledgers and third-party systems into Oracle Project Costing. They require a Requires Expenditure Batch Approval workflow step before committing to the financial record. Asana has no financial management, cost tracking, or approval routing for expenditure data. We extract Expenditure Batch headers and flag the total count and value for disposition planning, but these records do not migrate into Asana. Customers with active expenditure processing should close or transfer open batches before migration cutover.

Oracle Project Budgets are versioned financial plans at the Project level with baseline and forecast variants stored in a dedicated planning cube. Asana has no budget tracking, financial planning, or versioned cost-forecast objects. We extract budget row totals and map them to Asana project-level custom fields (budget_amount, budget_version) for reference, but budget line-level detail does not transfer as structured data.

Oracle Project Contracts define billing terms, milestones, and revenue recognition rules as part of Project Contracts Cloud Service. Asana has no contract management, milestone billing, or revenue recognition features. Contract header information (contract number, customer, contract value, billing terms) migrates as a project-level custom field note for reference, but the contract record and billing schedule do not transfer.

Oracle Project Billings capture invoiced amounts against Project Contracts as AR invoices linked to Projects. Asana has no invoice, billing, or accounts receivable objects. We extract billing header totals and map them to project-level custom fields, but line-level invoice details do not transfer. Customers should resolve all open AR invoices in Oracle before migration cutover.

Oracle Descriptive Flexfields extend standard objects with key-value segments defined as setup data. We extract DFF values during export and map them to Asana custom fields of equivalent type (text, number, date, dropdown, checkbox). Segment codes become custom field names; segment values become field values. DFF segment definitions must be present in the destination Asana project before data loads to avoid silent drops. We sequence custom field schema creation before any record migration and validate that all DFF segments map to a valid Asana custom field type before the data phase begins.

Oracle attachments stored in Oracle Content and Experience (OCEC) or FBL file storage download to a staging location and re-upload to Asana as task attachments. Asana's API enforces a 100 MB per-file attachment limit. Files exceeding this threshold are flagged in the attachment inventory and not loaded; the customer's admin resolves these manually post-migration. Attachment metadata (created by, created at, modified by, modified at) migrates as custom fields on the attachment record.

Oracle Configuration Packages (ZIP archives of setup XML containing lookups, profile options, flexfields, and workflow rules) migrate between Oracle environments. Asana has no configuration package or setup data export/import model. We extract the package contents and produce a written configuration inventory that documents the active lookups, flexfield segment definitions, and profile options requiring manual reconfiguration in Asana as custom fields or project-level settings.

Project approval and notification workflows in Oracle Fusion PM are built on BPM Worklist with approval hierarchies and assignment configurations stored as workflow definitions. Asana has no workflow automation engine comparable to BPM Worklist. We do not migrate workflows as code. We deliver a written inventory of every active Oracle BPM workflow with its trigger, approval chain, and conditions, mapped to Asana equivalents (due date reminders, assignee assignments, or the customer's chosen automation tool) for the admin to rebuild post-migration.

Oracle Task Followers represent subscription-style notifications for specific tasks, accessible via /child/TaskFollowers under ProjectTasks. Asana has no follower or subscription model: the equivalent visibility mechanism is task assignment. We map Oracle Task Followers to Asana task assignees, with the follower relationship preserved as a custom multi-select field follower_set for audit. Any follower without a matching Asana workspace member goes to the reconciliation queue.