Project Management migration
Field-level mapping, validation, and rollback between Planview ProjectPlace and Asana. We move data and schema; workflows are rebuilt natively in Asana.
Planview ProjectPlace
Source
Asana
Destination
Compatibility
9 of 14
objects map 1:1 between Planview ProjectPlace and Asana.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Planview ProjectPlace to Asana is primarily a structural consolidation: ProjectPlace's Workspaces, Kanban boards, Gantt views, and Agile sprints all map to Asana's Project-centric data model, but the two platforms handle dependency chains, milestone anchoring, and time tracking differently. ProjectPlace automatically recalculates downstream dates when upstream tasks shift, a behavior Asana does not replicate; we freeze the current calculated schedule at export time and replay it as static start/end dates in Asana's Timeline so milestone anchors are preserved. Time entries are a full-migration object in ProjectPlace but have no native equivalent in Asana — we map them to task-level notes with hours and user attribution. Custom fields migrate as typed fields (text, number, enum) but the custom field definitions must exist in the destination workspace before values can be written, which requires a pre-import schema build. Automations and workload view aggregations do not migrate; we deliver a written inventory for the customer's admin to rebuild in Asana's rule builder.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Planview ProjectPlace object lands in Asana, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Planview ProjectPlace
Workspace
Asana
Team + Project
1:manyProjectPlace Workspaces map to Asana Teams as the organizational unit and Asana Projects as the project container. We map Workspace-level settings, description, and start date to the Project. Member lists migrate as Project members with the Asana Team as the parent grouping. Organizations with more than 50 active Workspaces may prefer to map each Workspace to a standalone Asana Project without Team grouping; we confirm the preferred structure during scoping.
Planview ProjectPlace
Task (Activity)
Asana
Task
1:1ProjectPlace Activities map directly to Asana Tasks with assignees, due dates, status, and subtask hierarchy preserved. Subtasks in ProjectPlace map to Asana subtasks. Assignee resolution uses email matching against the Asana destination workspace. Any Activity without a matching Asana user is flagged in the reconciliation report for the customer's admin to provision before import.
Planview ProjectPlace
Kanban Board
Asana
Board View / Section
lossyProjectPlace Kanban boards map to Asana's Board view within each Project. Board columns map to Asana Sections or custom columns if the customer uses an integration. Card-level metadata (card name, description, assignee, due date, labels) migrates as task fields. Card ordering within each column is preserved as section ordering in Asana. Note that Asana Board view is view-level only; there is no separate card object separate from Task.
Planview ProjectPlace
Gantt Dependency
Asana
Task Dependency
lossyProjectPlace Gantt task dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) map to Asana dependencies using the Asana Tasks API dependency endpoints. We freeze the current calculated dependency chain before export because ProjectPlace's automatic date recalculation would otherwise replay the recalculation at the destination incorrectly. Start and end dates replay as static values in Asana's Timeline. Any circular dependency detected in ProjectPlace is flagged for manual resolution before migration.
Planview ProjectPlace
Milestone
Asana
Milestone
1:1ProjectPlace milestones map to Asana Milestones. We freeze milestone dates before export to prevent ProjectPlace's downstream recalculation logic from unanchoring fixed dates during the migration window. Milestone name, date, and associated tasks migrate. Tasks linked to milestones in ProjectPlace are associated with the corresponding Asana Milestone via the milestone association field.
Planview ProjectPlace
Custom Field
Asana
Custom Field
1:1ProjectPlace per-Workspace custom fields map to Asana custom fields. We enumerate the full custom field taxonomy during scoping, map each ProjectPlace field type (text, number, date, enum) to the matching Asana custom field type, and pre-create field definitions in the destination Asana workspace before any task values are written. OTB sync field limitations in ProjectPlace mean we must query the full API surface directly rather than relying on any standard export; any custom fields not exposed via API are flagged for supplemental manual export from Planview support.
Planview ProjectPlace
User (Team Member)
Asana
Member
1:1ProjectPlace user accounts map to Asana workspace members by email address. User display name and email migrate. Role-based permissions in ProjectPlace may not have a direct Asana analog; we flag permission gaps and recommend a post-migration review of Asana project member roles and guest access settings.
Planview ProjectPlace
Document
Asana
Attachment / Project Description
1:1ProjectPlace documents stored within Workspaces — including file name, uploader, upload date, and URL — migrate as Asana Attachments. Binary file blobs require a separate file transfer step; we catalog attachment references and filenames during the schema scan and orchestrate parallel file migration alongside the object migration. Project-level documents migrate to the Asana Project description or as pinned attachments.
Planview ProjectPlace
Time Entry
Asana
Task Subtask or Note
1:1ProjectPlace task-level time entries (hours logged, date, user attribution) migrate as Asana Task-level custom fields (time logged) or as structured subtasks with a note containing hours and date. Asana has no native time tracking object; the customer chooses the carry-forward strategy during scoping. Reporting aggregations from ProjectPlace time logs are not transferred and must be reconstructed in Asana's reporting module or via a time-tracking integration.
Planview ProjectPlace
Comment (Conversation)
Asana
Comment
1:1ProjectPlace task-level comments and board conversations migrate as Asana Comments on tasks. Author, timestamp, and comment text are preserved. Nested reply threads in ProjectPlace flatten into a linear comment sequence in Asana. @mention formatting is stripped during migration because Asana @mentions resolve against its own user table.
Planview ProjectPlace
Attachment
Asana
Attachment
1:1Task-level file attachments in ProjectPlace migrate as Asana Attachments on the corresponding task. We catalog attachment references and filenames during the schema scan, then orchestrate parallel file transfer alongside the object migration. Attachments larger than 100 MB are flagged for chunked upload via the Asana Attachments API.
Planview ProjectPlace
Agile Board (Sprint / Iteration)
Asana
Project Section + Tags
lossyProjectPlace Agile boards with sprint cycles map to Asana Projects using Sections to represent sprints or using the Portfolio's sprint-tracking view. Sprint names, start and end dates, and backlog items migrate as tasks with section membership. Velocity and burndown data from ProjectPlace are not carried forward; Asana calculates its own velocity once the team begins using the sprint structure. The customer chooses whether to use Asana native portfolios or a lighter section-based approach during scoping.
Planview ProjectPlace
Status and Label
Asana
Tag
lossyProjectPlace custom status values and color-coded labels per Workspace are enumerated during scoping and mapped to Asana Tags. Tag color is preserved where Asana supports it. Any status value without a direct Asana tag equivalent is flagged for the customer's admin to review and assign.
Planview ProjectPlace
Workload View data
Asana
Custom Portfolio or Report
1:1ProjectPlace's workload visualization aggregates task assignments per user across all Workspaces. We export the underlying task-assignee data so workload balance can be reconstructed at the destination using Asana's Portfolio view or a custom report. The aggregated workload percentages themselves are not transferable and must be recalculated in Asana's reporting layer.
| Planview ProjectPlace | Asana | Compatibility | |
|---|---|---|---|
| Workspace | Team + Project1:many | Fully supported | |
| Task (Activity) | Task1:1 | Fully supported | |
| Kanban Board | Board View / Sectionlossy | Fully supported | |
| Gantt Dependency | Task Dependencylossy | Fully supported | |
| Milestone | Milestone1:1 | Fully supported | |
| Custom Field | Custom Field1:1 | Fully supported | |
| User (Team Member) | Member1:1 | Fully supported | |
| Document | Attachment / Project Description1:1 | Fully supported | |
| Time Entry | Task Subtask or Note1:1 | Fully supported | |
| Comment (Conversation) | Comment1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Agile Board (Sprint / Iteration) | Project Section + Tagslossy | Fully supported | |
| Status and Label | Taglossy | Fully supported | |
| Workload View data | Custom Portfolio or Report1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Planview ProjectPlace gotchas
Out-of-the-box sync field set is extremely limited
API rate limit of 25 req/s is org-global, not per-user
Date recalculation causes milestone drift
CSV import validates WBS references strictly
Asana gotchas
Automation rules have no export representation
API rate limits cap bulk migration throughput
Portfolios are view-only objects that do not hold data
Custom field enum options cannot be updated via API
Subtasks do not appear in project views by default
Pair-specific challenges
Migration approach
Discovery and workspace inventory
We audit every active ProjectPlace Workspace: task counts, milestone counts, Gantt dependency depth, custom field definitions (with explicit confirmation that OTB sync exports only a limited set, requiring direct API queries), Agile board configurations, and user membership lists. We pair this with an Asana workspace audit confirming the destination edition (Free, Premium, or Advanced) and whether Portfolio access is available for sprint tracking. The discovery output is a written migration scope with record counts per object and a confirmation of which ProjectPlace automations require a rebuild inventory.
Schema pre-build in Asana
Before any data migrates, we pre-create every custom field definition from ProjectPlace in the destination Asana workspace using the Asana Custom Fields API. We also configure project structure (Teams, Projects, Sections representing sprints) and load the Gantt dependency tree with date-freeze logic. This step validates that Asana's schema can represent all ProjectPlace field types and is a prerequisite for all subsequent import phases. Any custom field not exposed via ProjectPlace's API is flagged for a supplemental manual export from Planview support before this phase begins.
Milestone date freeze and dependency tree snapshot
We take a snapshot of the entire task dependency tree — including all calculated start and end dates, milestone anchors, and Gantt dependency links — before the migration window opens. ProjectPlace's auto-recalculation is suspended during this snapshot to prevent date drift. The frozen dependency tree is stored as the migration source-of-truth so that Asana receives the schedule as the team intended rather than as it would be recalculated during export. Circular dependencies are identified and flagged for manual resolution.
User reconciliation and member provisioning
We extract every distinct ProjectPlace user referenced on tasks, milestones, and comments and match by email against the destination Asana workspace member list. Any ProjectPlace user without a matching Asana member is added to a reconciliation queue for the customer's admin to provision. Migration cannot proceed past this step because task assignee references require resolved Asana user IDs. We also confirm that the migration user has Asana API access with project creation permissions.
Production migration in dependency order
We run production migration in record-dependency order: Asana Teams and Projects first, then Tasks with assignee and custom field values resolved (custom fields exist from the schema pre-build phase), then Milestones with frozen dates, then Gantt dependencies via the Asana dependency API, then Comments, then Attachments, then Agile board sprint data as Section membership. Time entries are imported last as custom field values or structured notes depending on the carry-forward strategy chosen at scoping. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze ProjectPlace writes during cutover, run a final delta migration of any tasks modified during the migration window, then enable Asana as the system of record. We validate record counts, spot-check milestone dates against the frozen dependency snapshot, and confirm custom field completeness on a random sample. We deliver the automation and workload-view inventory document to the customer's admin team and support a one-week hypercare window for reconciliation issues. We do not rebuild ProjectPlace automations as Asana rules inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Planview ProjectPlace
Source
Strengths
Weaknesses
Asana
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Planview ProjectPlace and Asana.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Planview ProjectPlace: 25 requests per second, org-global quota not per-user.
Data volume sensitivity
Planview ProjectPlace doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Planview ProjectPlace to Asana migration scoping. Not seeing yours? Book a call.
Walk through your Planview ProjectPlace to Asana migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Planview ProjectPlace
Other ways to arrive at Asana
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.