Migrate from OmniPlan to Asana

Each .omniplan file maps to one Asana Project. We extract the project-level metadata (name, start date, calendar) as the project container. If the customer has a multi-project portfolio with shared resources, we create an Asana Portfolio and add each migrated project to it, preserving the portfolio view. The Asana project start date is set from OmniPlan's Project Start Date; if OmniPlan uses a Project Finish Date constraint, we reverse-calculate the start date using the critical path duration.

OmniPlan tasks map directly to Asana tasks. We preserve the outline level as the subtask nesting hierarchy. Asana supports subtask nesting up to 4 levels deep; tasks with deeper OmniPlan outline levels are flattened at the fourth level and the remaining hierarchy is stored as a custom field ancestor_path__c for reference. Duration fields migrate as the Asana Due Date offset from start date; we detect work-time vs elapsed-time duration flags from OmniPlan and write an explicit duration_type__c custom field to preserve the original scheduling semantics. Start date and due date both migrate when present in OmniPlan.

OmniPlan milestones (tasks with zero duration) map directly to Asana milestones. We flag them explicitly during migration so Asana renders them as milestone markers rather than calculating a default duration. The milestone name and target date migrate as-is. Multiple milestones in sequence are connected via Asana dependency chains as appropriate.

OmniPlan named resources map to Asana team members. We extract Max Units, Hourly Cost, and Work Calendar from OmniPlan and map them to Asana as follows: resource cost rate becomes a custom number field resource_hourly_cost__c on the member's tasks; work calendar (standard hours per day/week and exceptions) becomes the Asana team's Working Hours configuration. Resources with no corresponding Asana user go into a reconciliation queue; the customer's admin provisions Asana user accounts before member assignment migration begins.

OmniPlan assignments link a resource to a task with an allocation percentage (e.g., 50%) and effort. Asana tasks have a single assignee field. For tasks with multiple resource assignments, we create one Asana task row per assignment and store the additional assignments in a custom multi-select field additional_assignees__c with the allocation percentage appended. Single-assignment tasks map directly with the assignee set from the resource mapping.

OmniPlan Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish dependencies migrate to Asana's equivalent dependency types. Lead and lag time from OmniPlan (expressed in the task's duration format) migrate to Asana's dependency offset field. We flag a known Asana behavior during migration: Asana's dependency date cascading has documented inconsistencies where tasks with complex dependency chains may not recalculate dates correctly when a predecessor is moved manually. We document affected dependency chains and recommend Asana timeline view manual verification post-migration.

OmniPlan Pro custom data fields (text, number, date, enum, checkbox types) map to Asana custom fields of equivalent type. Enum fields migrate as Asana drop-down fields; the customer's admin creates the drop-down values in Asana before migration. Asana enforces a 100-value limit per enum field; we flag any OmniPlan enum exceeding this for the admin to consolidate. Number fields migrate with their unit label preserved as a custom field suffix (e.g., hours__, days__, cost__). Custom fields are scoped at the project level unless the customer has an Asana Enterprise organization where global portfolio fields are available.

OmniPlan multiple baselines store dated snapshots of task start, finish, and duration. We extract the most recent baseline set and write baseline start date, baseline finish date, and baseline duration as three custom fields on each migrated task. Earlier baseline sets are stored as a JSON-serialized custom field baselines_archive__c for reference. We do not create a visual baseline-vs-actual comparison view in Asana as that requires a third-party reporting tool; we document the baseline data location so the customer's admin can configure a portfolio timeline comparison manually.

OmniPlan work calendars define standard hours per day (e.g., 8 hours), exceptions (holidays, custom working time), and overtime settings. We map the standard hours to Asana's team-level Working Hours configuration. Holiday and exception entries are written to a custom field work_calendar_exceptions__c as a structured text list because Asana does not support a native work-calendar exception model. Non-standard working time exceptions (e.g., half-day Fridays) require manual entry in Asana's working-hours override UI per team member.

OmniPlan recurrence rules (daily, weekly, monthly, annual) are parsed and expanded into individual task instances with the recurrence rule stored as a custom field recurrence_rule__c. Asana's native repeating task feature uses a different recurrence syntax; we map common patterns (daily, weekly, monthly on day-of-week) and flag complex OmniPlan recurrence patterns (e.g., nth weekday of month, business-day-only recurrence) for the customer's admin to reconfigure in Asana's rule builder. We generate a representative task instance for each recurrence series as the migration artifact.

OmniPlan split tasks represent discontinuous work segments on a single task. We represent each split segment as a separate Asana task row with a shared custom field split_group_id__c so the customer can visually group them in the Asana timeline or list view. The split segment dates and duration are set from OmniPlan's segment start and finish. This is a known semantic difference: Asana does not natively represent split tasks as a single record, so the customer should understand the grouping identifier as the reconstructive link.

Hammock tasks derive their duration from the span of child tasks. We flatten this by calculating the actual earliest child start date and latest child finish date at migration time and writing a fixed-duration task with those dates. The hammock_type__c custom field is set to 'hammock' to flag the original calculation intent. The customer should verify that the calculated dates match the expected hammock behavior; recalculation of a hammock after migration requires manual update in Asana.

OmniPlan task notes (text content on task) migrate to Asana task descriptions. OmniPlan does not have a comments or @mentions feature in the Standard tier, so there is no comment history to migrate. Pro users who used third-party collaboration tools in conjunction with OmniPlan should export those external conversation threads separately; we do not migrate external tool data unless explicitly scoped. We note this in the pre-migration discovery checklist.

OmniPlan interval cost and effort tracking (per-resource cost per task interval) migrates to Asana as custom number fields task_cost__c and task_effort_hours__c. Asana has no native cost-tracking object; these fields are informational for the customer's finance or PM team to reference alongside the task. If the customer uses Asana's portfolio budget add-on (Advanced tier and above), we can map cost fields to that model upon request during scoping. Earned value metrics (CPI, SPI, EV, PV, AC) are not migratable as they are runtime calculations derived from progress and cost data.

OmniPlan stores file paths and references to attachments. We map file paths to Asana task attachments where the file is accessible via a URL the migration pipeline can reach. Local file paths that are not URL-accessible are flagged in the migration report with the file path preserved in a custom field original_attachment_path__c for manual reattachment by the customer's team post-migration.