Migrate from PlanZone to Asana

PlanZone Projects map directly to Asana Projects. We extract project name, description, start date, due date, status, and owner assignment from the CSV export. In Asana, the project is created first so that the project_gid is available for task parent references during the load phase. PlanZone project-level custom properties map to Asana project-level custom fields. Projects with no tasks export as empty Asana projects, which is valid in Asana.

PlanZone Tasks map to Asana Tasks. The parent_project reference resolves to the Asana project_gid. Task name, description, due_date, start_date, status, and priority migrate. PlanZone's stage/status field maps to an Asana custom field or the task's completion status. Assignee handling is described in the User Assignment mapping below. Tasks without a due_date become undated Asana tasks, which is valid in Asana's data model.

PlanZone Milestones are flagged task types with a target date. We export them as Tasks in Asana with the milestone field set to true and the due_date set to the milestone target date. The milestone name migrates as the task name. Subtask relationships under milestones do not exist in PlanZone's milestone model, so no additional transform is required.

PlanZone stores dependencies as a parent-reference field on the child task. Asana models dependencies as explicit relationship records with a dependency_type (finish_to_start, start_to_start, finish_to_finish, start_to_finish). We transform the flat parent link into Asana Dependency records during a post-task-ID resolution step. Since PlanZone task IDs are not preserved in Asana, we resolve the task by name and project context before writing the dependency relationship. This mapping step must be validated against Asana's dependency API before the load phase begins.

PlanZone reusable project templates define a starting structure of tasks and milestones. We export the template as a Project skeleton in Asana with all template-derived tasks included, and flag the template origin in a custom field template_origin__c. The customer receives a written template reconstruction guide that maps each skeleton project to an Asana template for repeatable use. Templates with conditional or dynamic task generation cannot be fully reproduced in Asana without manual configuration.

PlanZone custom fields on Projects and Tasks are discovered during the schema audit step (before export). We map each PlanZone custom field to an Asana custom field of the matching type: text to text, number to number, date to date, dropdown to enum. Asana's global custom fields are available across the organization; local custom fields are scoped to a single project. The customer's admin chooses scope during scoping. Custom fields with unsupported data types (if any) are flagged as manual-recreate items.

PlanZone task comments are threaded text entries with author and timestamp. We export them as a flat list attached to the task. In Asana, we create a comment on the task using the Asana stories API, preserving the author name, timestamp, and comment body as a story note. Rich text formatting that does not map to Asana's comment format is simplified to plain text.

PlanZone allows multiple assignees per task. Asana permits exactly one assignee per task. For tasks with multiple PlanZone assignees, we split into one Asana task per assignee, each carrying the full task content. The original assignee list is preserved in a custom field original_assignees__c listing all PlanZone-assigned users. The customer can consolidate to a primary assignee or use subtasks to restore the multi-assignee model post-migration.

File attachments on PlanZone tasks are stored as URL references. We export the attachment manifest (file name, URL, task association, upload date). During the load phase, we download each file from the PlanZone URL and re-upload to Asana's attachment storage, linking each file to the migrated task. Files without accessible URLs (private-share links) are flagged as manual-recreate items in the scope agreement.

PlanZone uses status-driven Stages within a Project (e.g., Not Started, In Progress, Completed). Asana uses Sections to group tasks within a project. We map PlanZone Stages to Asana Sections by name. Tasks are assigned to their corresponding Section during import. If a PlanZone Stage name has no matching Section in Asana, we create the Section dynamically before task assignment.

PlanZone project owners are referenced by email in the CSV export. We resolve each owner email against the Asana destination workspace members list. If the user exists in Asana, they are added as an Editor to the project. If the user does not exist, we flag them for the customer admin to provision before production migration begins. Asana does not have a project-owner role equivalent to PlanZone's owner field, so this becomes a project member designation.

PlanZone priority values (e.g., Low, Medium, High, Critical) are exported as a text or enum field. We map these to an Asana custom field of enum type with the same priority labels. If PlanZone uses a numeric priority scale, we convert to a labeled enum for readability in Asana's interface.