Migrate from iPlan to Asana

iPlan Projects export with status, start/end dates, budget, owner, and portfolio hierarchy. We map each project to an Asana Project, preserve the project name and description, set the start_date and due_date from iPlan's planned dates, and assign the project to the corresponding Asana Team. If the iPlan project has a parent portfolio, we note the hierarchy for reconstruction in Asana Portfolios (Advanced+) or as a project-grouping structure in Sections.

iPlan Tasks map to Asana Tasks with name, notes (description), start_date, due_date, completion status, and priority preserved. Assignee resolves by matching the iPlan resource email to an Asana user. Custom task fields (dropdown, numeric, text) map to Asana custom fields created during schema design. Dependencies between tasks are recorded as dependencies in Asana using the /tasks/{gid}/addDependencies endpoint, preserving predecessor-successor relationships from iPlan's dependency chain.

iPlan Milestones map to Asana Milestones attached to the parent Project. Target dates transfer as the milestone due_date. We flag any milestone with no linked tasks during scoping so the customer can decide whether to attach a task before migration. Milestones without a parent project reference are mapped to a catch-all project flagged for manual reassignment.

iPlan Subtasks export as child Tasks in Asana. We create each subtask as a separate Task and attach it to the parent Task using the subtasks relationship in Asana's API. If the destination Asana workspace has subtasks disabled or uses sections for the same purpose, we flatten subtasks into a flat task list with a parent_task_gid custom field for reference.

iPlan Resources (employee database) export with name, role, and availability schedules. We map each iPlan Resource to an Asana User by email address. Availability schedules do not transfer directly since Asana does not have a native resource calendar; we document the availability data in a custom field on the User record (e.g., capacity_percent__c) and flag that workload visualization requires the Asana Advanced tier. Resource allocation percentages per project transfer to task assignments with percent_complete values.

Asana does not include native timesheet tracking in Starter or Advanced tiers without the Time Tracking add-on. We map iPlan timesheet hours to a custom field on Tasks (e.g., hours_logged__c as a number field) and preserve the original date, project reference, and task linkage as metadata. If the customer purchases the Asana Time Tracking add-on, we can remap to native time entries. Timesheet records with orphaned project references are flagged in the reconciliation report for manual resolution.

iPlan custom fields on Projects and Tasks require explicit field-type mapping during scoping. Dropdown, numeric, and text fields map directly to equivalent Asana custom field types. Formula and rollup fields from iPlan are recreated as read-only custom fields in Asana using numeric or text type. Multi-select fields from iPlan map to Asana enum (multi-select) custom fields. We pre-create all custom fields in the destination Asana workspace before data import.

iPlan's earned-value metrics (EAC, VAC, CPI, SPI) derive from timesheet data and are stored as project-level calculated values. We extract these metrics as numeric custom fields on the Asana Project (e.g., earned_value__c, actual_cost__c, schedule_variance__c) so that historical project performance data is not lost. Asana does not have native EVM; these fields are preserved for reporting but require manual formula setup in Asana Dashboards if the customer wants automated variance visualization.

iPlan Knowledge articles export as structured text with category assignments. We import article text into Asana Project descriptions or Section descriptions within the corresponding project, preserving file attachments as links. Category taxonomy from iPlan maps to Asana Tags for cross-project discoverability. We flag articles with no project linkage for assignment during scoping.

File attachments associated with iPlan Projects, Tasks, or Knowledge articles are extracted and uploaded to the corresponding Asana Task or Project using the Asana Attachments API. We preserve original filenames, upload timestamps, and content types. Attachments over 100 MB are noted separately since Asana's per-file limit is 100 MB for standard uploads.

iPlan billing and financial tracking data exports but has no native equivalent in Asana. We preserve billing amounts, currency, and invoice status as custom fields on the Project record (e.g., budget_amount__c, billed_amount__c, billing_status__c). Actual invoice generation and payment tracking require an external accounting tool or a manual reconciliation process post-migration.

iPlan workflow rules encode business logic in a proprietary format that cannot be directly exported. We perform a rules audit during scoping, capture each rule's trigger, conditions, and actions as a human-readable specification document, and provide a recommended equivalent using Asana Rules syntax. The customer's Asana admin rebuilds the automations using Asana's native Rules builder post-migration. We do not migrate rules as code.

iPlan report configurations and dashboards use a proprietary visualization schema that cannot be transferred. We export the underlying data (project metrics, task counts, milestone data, earned-value figures) to CSV and JSON so that Asana Dashboards can be rebuilt with equivalent views. The rebuild is outside migration scope and can be handled by the customer's PMO team or a FlitStack AI follow-on engagement.