Migrate from workspace.pm to Asana

workspace.pm Projects map directly to Asana Projects. We extract Project name, description, status, start date, target end date, owner, and cost fields. Archived or completed Projects migrate with their completion status preserved. The Project container is created before any child Tasks so that the parent-project lookup is satisfied at Task insert time.

workspace.pm Tasks map to Asana Tasks with title, description (migrated as Notes rich text), status, assignee, due date, start date, and priority preserved. Task status mapping depends on workspace.pm's status vocabulary (Active/On Hold/Complete or custom) and is resolved to Asana's completion boolean during the transform phase.

workspace.pm Subtasks nested under Tasks map to Asana Subtasks. The hierarchy is preserved using Asana's parent task reference. For destinations without native subtask support, we flatten subtasks into task records with a parent_reference custom field and preserve ordering through a sequence number field.

workspace.pm Milestones map to Asana Milestones where available (Premium and above). For Starter/Basic tier destinations, Milestones are migrated as Tasks with a milestone_label custom field set to true and the due date preserved. The associated project linkage is maintained through the parent Project reference.

workspace.pm predecessor-successor task relationships migrate to Asana Dependents using Asana's dependency endpoint (api/1.0/tasks/{task_gid}/addDependencies). We capture the dependency type (Finish-to-Start is the most common) and reconstruct it in the destination. Circular dependency detection runs as a pre-flight check against the extracted pairs.

workspace.pm custom fields at project and task level migrate to Asana Custom Fields. We extract field name, data type (text, number, date, dropdown, checkbox), and picklist options from the workspace.pm export. Dropdown values map to Asana enumerated custom field options. Asana's 100-custom-field-per-project limit is checked during scoping. Picklist field value mappings are handled explicitly during the mapping phase.

workspace.pm's Resource allocation records (user, role, allocation percentage, date range) map to Asana Assignee fields on Tasks. The allocation percentage is stored in a numeric custom field allocation_pct__c on the task because Asana natively shows only the assignee without a capacity percentage. Where a workspace.pm Resource has no corresponding Asana User, the record is held in a reconciliation queue.

workspace.pm Time Entries (user, date, hours, description, linked task or project) migrate to Asana Tasks with a time_tracked custom field or to a separate time_entry object if the destination uses an Asana native time-tracking integration. Where Asana's native time tracking is unavailable, time entries are stored as a custom field group (hours_logged, date_logged, user) for admin reconstruction.

workspace.pm discussion threads on Tasks and Projects migrate to Asana Stories on the Task. Author, timestamp, and body text are preserved. Where the Asana API creates comments under the migration account rather than the original author, we note this limitation explicitly and store the original author in a custom field comment_author__c for audit.

workspace.pm file attachments linked to Tasks or Projects migrate as Asana Attachments. We transfer filename, uploader, upload date, and the file URL or binary reference. Asana's API rejects attachments exceeding 100MB; files over this threshold are flagged for the customer to re-upload manually post-migration, and a reference list is included in the migration deliverable.

workspace.pm Portfolio-to-Project associations migrate to Asana Portfolios where the destination org has Portfolio access (Premium and above). Where Portfolio is unavailable or the customer prefers a lighter-weight grouping, we reconstruct the association as Tags on Projects, with each Portfolio becoming a Tag and Project membership preserved. The choice is made during scoping based on the destination tier and reporting requirements.

workspace.pm Kanban board configurations are presentation-layer views, not independent data objects. The underlying task data (status, assignee, due date) is migrated as part of the Task export. Board column definitions, WIP limits, and swim lane layouts do not migrate. We document the board structure during scoping so the customer's admin can recreate the board layout in Asana's Board view post-migration.

Gantt chart visualizations in workspace.pm are derived from task dates, dependencies, and milestones. The underlying scheduling data migrates as part of Task records. The Gantt layout itself is not a migratable object. We ensure that start_date, due_date, and dependency fields are populated so that Asana's Timeline view renders correctly post-migration.

Dashboard reports and portfolio analytics in workspace.pm are aggregate, read-only views generated from project and task data. These do not migrate. We extract the underlying data that powers critical reports and provide a written inventory of each dashboard's component metrics with recommended Asana reporting equivalents (Portfolio dashboards, custom report builders, or third-party BI tools).