Project Management migration
Field-level mapping, validation, and rollback between Planview AgilePlace and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.
Planview AgilePlace
Source
Microsoft Project
Destination
Compatibility
8 of 10
objects map 1:1 between Planview AgilePlace and Microsoft Project.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Migrating from Planview AgilePlace to Microsoft Project is a structural reconception, not a record copy. AgilePlace organizes work on Kanban boards with Lanes, Swimlanes, and WIP limits; Microsoft Project structures work as Tasks on a Gantt chart with Start/Finish dates, Duration, and predecessor dependencies. We do not move Kanban boards as visual boards — we decompose each board into a Project plan, each Lane into a Summary Task or phase, each Card into a typed Task, and preserve WIP limit logic as a custom field so PMs can reason about flow in the new environment. Card Dependencies migrate as predecessor links, Card Comments become Task Notes, Card Attachments are re-uploaded to SharePoint or Project Online document libraries, and Card Timestamps (Created, Moved, Updated) are preserved in custom fields. We do not migrate Card Automation, cross-board mirror cards, or Jira/GitHub integration metadata — these require manual reconstruction by the customer's PMO.
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 AgilePlace object lands in Microsoft Project, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Planview AgilePlace
Board
Microsoft Project
Project file or Project Online project
lossyEach AgilePlace Board maps to a standalone Microsoft Project file (.mpp) or a Project Online project within a PWA. We extract board metadata including board name, description, and Lane structure during the first pass. If multiple boards represent phases of a single program, we consolidate them into one Project plan with Summary Tasks per board. The customer's PMO defines the consolidation boundary during scoping.
Planview AgilePlace
Lane
Microsoft Project
Summary Task or Phase
lossyAgilePlace Lanes map to Summary Tasks in Microsoft Project, preserving the hierarchical relationship between parent Lanes and child Swimlanes. Each Lane's WIP limit is stored as a custom field WIP_Limit__c so PMs can reason about flow. Lane color coding maps to a Text field Color_Code__c. Swimlanes within a Lane become sub-summary tasks. If the destination is a flat task list without WBS hierarchy, Lanes map to a Phase label custom field on individual tasks.
Planview AgilePlace
Card
Microsoft Project
Task
1:1AgilePlace Cards map to Microsoft Project Tasks. Card title becomes Task Name. Card description (rich text) migrates as Task Notes. Card type maps to a Text custom field Card_Type__c. Card priority maps to Priority (1-5 in MS Project). Due date on the Card becomes the Task Finish date; if no due date exists, the card is placed in the Lane without a scheduled date and the PM schedules it post-migration. Created, Moved, and Updated timestamps from AgilePlace are stored in custom fields Orig_Created__c, Orig_Moved__c, and Orig_Updated__c for audit and cycle-time reporting.
Planview AgilePlace
Card Dependency
Microsoft Project
Task Predecessor
1:1Card Dependencies in AgilePlace are stored as a separate API relationship linking child cards to parent cards. We export these as a dependency table keyed by Card ID, then map each dependency to a Microsoft Project predecessor link (FS, SS, FF, SF). We resolve predecessor IDs after task creation using the temporary ID mapping table generated during import. Circular dependency detection runs against the graph before insertion to prevent invalid schedule structures.
Planview AgilePlace
Card Assignee
Microsoft Project
Task Resource or Assignee field
1:1Card Assignees map by email address to Microsoft Project resources. If the destination is Project Online, we match against the PWA resource list. If the destination is desktop MS Project with no connected PWA, we create local resources from the assignee list. Unmatched assignees (cards assigned to inactive or archived AgilePlace users) are flagged in a reconciliation report for the customer's PMO to resolve before final import.
Planview AgilePlace
Custom Fields
Microsoft Project
Custom Fields
1:1AgilePlace Custom Fields are defined per-board. We export field definitions alongside card data and map each to a Microsoft Project custom field of equivalent type: Text fields to Text, number fields to Number, date fields to Date, and dropdown values to Flag or Outline Code. Note that AgilePlace Custom Field edit permissions are role-gated — a user without project-level write access cannot update a custom field. We detect permission-sensitive fields during discovery and ask customers to confirm the migration user has write access to all custom fields at the board level.
Planview AgilePlace
Comments
Microsoft Project
Task Notes (appended)
1:1Card Comments are appended to the Task Notes field in Microsoft Project, separated by a timestamp and author line (Author: name | Date: ISO date). If Task Notes already contains content, comments are appended to the existing text. If the destination is Project Online, comments may alternatively be stored in the associated SharePoint task list for a more collaborative experience.
Planview AgilePlace
Tasks (Sub-tasks)
Microsoft Project
Subtasks
1:1AgilePlace Tasks (sub-items within a Card) map to Microsoft Project subtasks (Outline Level > 1). Completion status and assignee are preserved. If a Card has more than 20 sub-tasks, we flag it as a scope-risk item during scoping because deeply nested WBS structures in MS Project can degrade performance in the desktop client.
Planview AgilePlace
Tags
Microsoft Project
Text custom field or Flag field
1:1AgilePlace Tags are flat string labels. In desktop MS Project, tags map to a Text custom field Tags__c storing comma-separated values. In Project Online, tags may map to a multi-select Flag field if the customer's PWA supports that configuration. Tags used for card-type classification map to Card_Type__c instead.
Planview AgilePlace
Card Attachments
Microsoft Project
SharePoint document library or file attachment
1:1File attachments on cards are downloaded from AgilePlace and uploaded to the associated SharePoint document library (for Project Online) or a shared network location (for desktop MS Project). The original file name and AgilePlace card reference are preserved in a Text field Attachment_Ref__c on the Task. Large attachment volumes increase migration duration and require storage capacity planning, particularly for Project Online where SharePoint storage has org-level quotas.
| Planview AgilePlace | Microsoft Project | Compatibility | |
|---|---|---|---|
| Board | Project file or Project Online projectlossy | Fully supported | |
| Lane | Summary Task or Phaselossy | Fully supported | |
| Card | Task1:1 | Fully supported | |
| Card Dependency | Task Predecessor1:1 | Fully supported | |
| Card Assignee | Task Resource or Assignee field1:1 | Fully supported | |
| Custom Fields | Custom Fields1:1 | Mapping required | |
| Comments | Task Notes (appended)1:1 | Fully supported | |
| Tasks (Sub-tasks) | Subtasks1:1 | Fully supported | |
| Tags | Text custom field or Flag field1:1 | Mapping required | |
| Card Attachments | SharePoint document library or file attachment1:1 | Mapping required |
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 AgilePlace gotchas
Card Automation cannot mirror or copy cards between boards natively
Custom field permissions are role-gated, not globally editable
Relations Summary fields can display ERROR for large record sets
Reporting API is tier-gated to Advanced and Enterprise editions
Portfolios integration requires Planview Hub as a separate license
Microsoft Project gotchas
Project for the web is being retired and merged into Microsoft Planner
Planner-tier portfolio features are incomplete despite Plan 5 labeling
Web app constraint controls are weaker than the Windows desktop client
Project requires a separate license not bundled with standard Microsoft 365
Project Online API is edition-gated and inconsistently documented
Pair-specific challenges
Migration approach
Discovery and board inventory
We audit every AgilePlace board in the customer's account: board count, Lane count, card volume per board, Custom Field definitions, Card Type taxonomy, Card Dependency graph, active Card Automation rules, and user list. We confirm the AgilePlace tier (Teams vs Scaled Teams) to determine whether the Advanced Reporting API is available for bulk extraction. We also confirm the Microsoft Project destination: desktop MS Project (Standard or Professional one-time license) or Project Online cloud with a PWA tenant. The discovery output is a written migration scope with board-to-project mapping, lane-to-summary-task mapping, and a card-to-task row estimate per destination project.
Schema design and WBS mapping
We design the destination schema in Microsoft Project. For each AgilePlace board, we create a Project plan (or PWA project in Project Online). Each Lane becomes a Summary Task; Swimlanes become sub-summary tasks. WIP limits are stored as custom Number fields. Card Types map to a Text custom field. We define custom fields for all AgilePlace Custom Field values with equivalent types (Text, Number, Date, Flag). The customer's PMO reviews and approves the WBS mapping before we begin data extraction. If the customer uses Project Online, we deploy the custom fields to the PWA enterprise project plan during this phase.
Card extraction and dependency graph resolution
We extract Cards from each board via the AgilePlace API, including Card ID, title, description, type, priority, due date, assignees, timestamps (Created, Moved, Updated), Custom Field values, Comments, and Attachments. Card Dependencies are extracted as a separate relationship table keyed by Card ID. We build a dependency graph, run circular dependency detection, and generate a topological sort order for insertion into Microsoft Project. This ensures that when we insert Task 2 with a predecessor link to Task 1, Task 1 has already been created and has a stable ID.
Sandbox import and reconciliation
We run a full import into a test Project file (desktop) or a sandbox PWA (Project Online) using a representative sample of boards and cards. The customer's PM lead reviews the WBS structure, validates that Lane-to-summary-task mapping matches their expectations, spot-checks 25-50 random Cards against the source AgilePlace records, and confirms that Custom Field values and Comments transferred correctly. Any mapping corrections are documented and applied to the production import script before cutover.
Production migration in dependency order
We run production migration in topological order: Project files created first, Summary Tasks (Lanes) inserted second, Tasks (Cards) inserted third using the resolved dependency graph, predecessor links established after all Tasks have stable IDs, Custom Field values populated per Card, Comments appended to Task Notes, and Attachments uploaded to SharePoint or file location. Each phase emits a row-count reconciliation report. A delta pass captures any cards modified during the migration window between the initial extraction and the final insert.
Cutover, validation, and automation handoff
We freeze writes in AgilePlace during cutover, run a final delta migration, then deliver the completed Project files or confirm the Project Online tenant is live. We provide a Card Automation inventory document listing every active automation by board with its trigger, conditions, and actions, plus a recommended manual reconstruction approach using Microsoft Power Automate if the customer uses Project Online. We do not rebuild Card Automations as Power Automate flows inside the migration scope. We support a one-week hypercare window for reconciliation issues raised by the PMO.
Platform deep dives
Planview AgilePlace
Source
Strengths
Weaknesses
Microsoft Project
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 1 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 AgilePlace and Microsoft Project.
Object compatibility
1 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 AgilePlace: Not publicly documented on the public-facing API page.
Data volume sensitivity
Planview AgilePlace 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 AgilePlace to Microsoft Project migration scoping. Not seeing yours? Book a call.
Walk through your Planview AgilePlace to Microsoft Project 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 AgilePlace
Other ways to arrive at Microsoft Project
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.