Migrate from OnePlan to Asana

OnePlan Plans map to Asana Projects. Plans contain the core metadata (name, description, status, start/end dates) that translates directly to Asana Project fields. We preserve the Plan type hierarchy by organizing Asana Projects into Teams that correspond to OnePlan Areas, and we use Asana's Project Sections to represent sub-plan groupings if the source uses multi-level Work Plan structures within a Plan. OnePlan's Plan-level custom fields map to Asana Project-level custom fields, applied per project from a template.

OnePlan Work Plans within a Plan can represent either task groupings or sub-projects. We map Work Plans that contain task lists to Asana Sections within the target Project for lightweight grouping, or to separate Asana Projects if the customer wants independent task assignment and reporting per Work Plan. This choice is made during scoping based on how the customer uses Work Plans for task ownership and progress tracking.

OnePlan Work Plan Tasks migrate to Asana Tasks. OnePlan Estimated Start and Estimated End dates map to Asana Start Date and Due Date. Task dependencies migrate as Asana dependency links (Finish-to-Start only; Asana does not support other dependency types). Note that OnePlan's multiple resource assignments per task must resolve to Asana's single-assignee model; we create one Asana Task per OnePlan task and assign to the primary resource, with additional assignees noted in the task description or a custom multi-user field if the Advanced plan is in use.

OnePlan Risks migrate to Asana Tasks tagged with a custom Risk field (Asana Custom Field: Type = 'Risk'). Risk-specific properties (probability, impact, status, owner) migrate as Asana custom fields. Risks do not auto-rollup to a portfolio view in Asana the way they do in OnePlan; we document the risk register as a separate Asana Project or as a tagged view within the main project for the customer's PMO to maintain post-migration.

OnePlan Issues migrate to Asana Tasks tagged with a custom Issue field (Asana Custom Field: Type = 'Issue'). Issue properties (severity, status, owner, raised date) map to equivalent Asana custom fields. Like Risks, Issues do not have a native portfolio-level rollup in Asana; we recommend a dedicated Issues project or a tag-based filtered view.

OnePlan Resources map by email match to Asana Workspace Users. Resource properties (role, department, skill) migrate as Asana custom fields on the User profile or as Portfolio membership attributes. We resolve the resource lookup during import so that task assignments point to valid Asana User records. Resources without a matching Asana User go to a reconciliation queue for the customer's admin to provision.

OnePlan's resource allocation over time (allocation percentages by period) does not have a native Asana equivalent. Asana's Portfolio Workload view shows tasks assigned to users but does not store time-phased allocation percentages. We migrate the most recent period allocation as a static custom field on the User (e.g., current_allocation_pct) and include a written summary of the full time-phased allocation table for the customer's admin to use with a third-party resource management tool or a custom Asana integration if needed.

OnePlan financial plan data (budget, actuals, forecast by period) migrates to Asana Project custom fields. We map the current period values (budget, actual spend, forecast) as numeric custom fields on the Project. Historical period data is included in a structured CSV deliverable that the customer's finance team can import into a spreadsheet or BI tool. Asana does not natively support financial period tracking; this is a known limitation that we document rather than attempting a partial workaround.

OnePlan's seven custom field types map to equivalent Asana field types. We create Asana custom fields per Project using a migration template rather than from a centralized field library because Asana does not have org-wide custom field configuration. Each project's template defines which custom fields apply. Choice fields migrate as Asana Enum fields with the same options; Yes/No migrates as a Boolean Enum; Currency and Number map directly to Asana Number fields.

OnePlan User-type custom fields (pointing to a Resource) migrate to Asana User custom fields, available on Asana Advanced plan. The User reference resolves to the migrated Asana User record. If the destination Asana plan is Starter or below (no user custom fields), we fall back to a Text field storing the user's name as a string.

OnePlan Areas (top-level organizational units) map to Asana Teams. Each Area becomes a Team in Asana, with the Plans within that Area becoming Projects within the corresponding Team. This preserves the top-level organizational structure from OnePlan while mapping to Asana's permission and sharing model.

OnePlan Plan Details form data associated with plans migrates as Asana Project custom fields. Custom form layouts do not migrate; we document the form fields and their values so the customer's admin can recreate the form structure in Asana using a Project template if needed.