Migrate from Planview PPM Pro to monday Work Management

Planview Portfolios are top-level strategic containers with alignment scores and portfolio-level financials. monday.com has no Portfolio object. We create a dedicated Workspace per Portfolio or flatten the Portfolio into a parent Board using Groups to represent Programs. Portfolio alignment scores and portfolio-level budget totals migrate as read-only number columns on the parent Board for executive reference. The customer decides during scoping whether to maintain one Workspace per Portfolio (preserving the hierarchy) or consolidate into a single Workspace with a Portfolio column filtering per strategic entity.

Programs in Planview group related Projects under a Portfolio with their own budget, status, and owner. monday.com has no native Program object. We map each Program to either a separate Board (preserving Program-level budget as a number column) or a Group within the parent Portfolio Board. Group naming conventions are set during scoping. If the customer has Program-level reporting requirements, we create a Program Status board linked via monday's Integrations or a custom column reference to the Projects board.

Planview Projects are the core work unit with status, start/end dates, priority, owner, budget, and strategic alignment fields. Each Project maps to a monday.com Board. We create the Board with standard columns (Status, Priority, Assignee, Date, Timeline) and then map Planview custom User-Defined Fields to monday's corresponding column types (text, number, date, dropdown, checkbox). Gantt dependencies between Projects are preserved as monday's Dependency column relationships. The Project owner maps to the monday User who is the Board subscriber.

Planview Tasks belong to Projects and carry start/end dates, percent complete, assignees, effort hours, and WBS hierarchy. Tasks map to monday.com Items within the Project Board. We preserve the Work Breakdown Structure (WBS) hierarchy using monday's Subitems or by nesting Items in Groups. Gantt dependency links (Finish-to-Start, Start-to-Start, etc.) from Planview migrate to monday's Dependency column with a note indicating the dependency type — complex dependency chains are flagged for manual review because monday's dependency model supports fewer relationship types than Planview's WBS model.

Planview Resources are people or roles with capacity, skills, utilization data, and availability calendars. Each Resource maps to a monday.com User by email match. Capacity heatmaps and utilization percentages do not have a native monday.com equivalent — we map the current allocation percentage to a number column on the User's profile item in a Resource Board, and flag that the workload view in monday shows assignment load only, not true capacity. Role-based Resources (non-person) are mapped to monday.com Person-type columns on the relevant Items as placeholders.

Planview Time Entries record hours logged against Projects and Tasks with dates, hours, cost codes, and billable/non-billable flags. monday.com's Time Tracking column is available on Pro plans and above. We map Time Entries to Items (the equivalent Task) using the date and hours. The billable flag from Planview maps to a separate checkbox column in monday.com since the native Time Tracking column does not expose a billable flag. If the customer uses multiple cost codes, we create a text column carrying the cost code reference.

Planview Demand Requests capture project intake before formal approval — including requester, estimated effort, priority, and scoring status. monday.com has no demand management or intake funnel object. We create a dedicated intake Board and migrate Demand Requests as Items within it, preserving requester, estimated hours, priority, and status. Scoring matrices and approval gates are documented as a written handoff note for the customer's admin to rebuild using monday's Automations. Teams that rely heavily on Planview's demand intake gate should plan for a separate process redesign in monday.com.

Planview supports User-Defined Fields of type Text, Number, Date, and Dropdown on Projects and Tasks. Custom field definitions migrate as monday.com column configurations — text to Text, number to Number, date to Date, and multi-select dropdowns to Dropdown or multi-select Dropdown. Single-select Dropdown maps to a monday Label column. We handle attribute-level data type conversion during the transform step and flag any Dropdown values that exceed monday's 255-character label limit.

Planview Project budgets include planned cost, actual cost, labor cost, and expense line items. monday.com has no native financial management module. We migrate budget data as read-only Number columns on the Project Board — Planned Cost, Actual Cost, Labor Cost — and flag that expense line items with currency codes should be stored as Text columns to preserve multi-currency context. Multi-level budget hierarchies (parent-child budgets) cannot be represented natively; these flatten to a single number or are documented for reconstruction in a connected BI tool.

Planview PPM Pro does not expose a public API endpoint for downloading file attachments. We cannot retrieve attachment binary content programmatically. We document every Project and Task record with an attachment as a manifest listing the file name, record reference, and file size so the customer's team can manually download and re-upload. The manifest is delivered alongside the migration output as an auditable step that remains outside our automated scope.

Planview Dashboards and saved reports are proprietary application configurations tied to Planview's reporting engine. These do not migrate as code. We export the underlying data (Projects, Tasks, Time Entries, financials) so reports can be rebuilt in monday.com's Dashboard views or connected BI tools. We deliver a written inventory of every active Dashboard and Report with its filters, metrics, and chart types for the customer's admin to reconstruct as monday.com Dashboard widgets.

Planview User records include name, email, role, and active/inactive status. Each User maps to a monday.com User by email address. Active status maps directly; inactive Planview users map to inactive monday.com Users so historical assignments and time entries reference valid users without orphaned records. Role-to-permission translation depends on monday.com's Workspace permission model (Owner, Admin, Member, Viewer) which is less granular than Planview's role-based access. We flag any Planview role that has no direct monday.com equivalent during scoping.