Migrate from OpenText Project and Portfolio Management (PPM) to monday Work Management

OpenText PPM Programs map to monday.com Boards at the top level of the migration hierarchy. Each Program becomes a Board with a descriptive name, and the Program's description, start/end dates, and custom properties migrate as Board-level columns or the first Item's fields. Program-level financial rollup lines migrate to a dedicated Financial Summary group within the Board or to a separate Finance tracking Board linked by Board Integrations. The Program's linked Projects migrate as Groups within the same Board or as Items at the Board root, depending on the complexity of the program's project count.

OpenText PPM Projects map to monday.com Items within a Board (representing the parent Program). Project name, description, start and end dates, status, priority, owner, and budget fields migrate as Item column values. Project-level task hierarchies (WBS) migrate as subitems within each Item, preserving the task name, assignee, start/end date, and dependency references. Cross-project dependencies (finish-to-start, start-to-start, etc.) from OpenText PPM map to monday.com's dependency feature using the Depend On / Blocks column type, maintaining the dependency type and lag where the destination column type supports it.

OpenText PPM Portfolios aggregate Programs and Projects for executive governance. In monday.com, portfolios are only available on the Enterprise plan and serve as a board aggregation layer. We map Portfolios to either a monday.com Portfolio (if the customer has Enterprise licensing confirmed) or a consistent top-level folder/tag convention across all migrated Boards. Portfolio-level financial cost and benefit lines migrate as a dedicated Finance tracking Board linked to each constituent Program Board. We flag during scoping whether the Enterprise Portfolio feature is required because it affects licensing decisions.

OpenText PPM Demands represent incoming work requests or ideas that feed into project intake. Demands map to monday.com Inbox items (for active intake tracking) or Workdocs (for richer demand descriptions and supporting context). We preserve demand status, priority, requestor name, submission date, and any custom demand-type fields as Inbox item fields or Workdoc properties. Active Demands in an approval workflow are flagged as requiring manual workflow rebuild in monday.com Automations because the stage-gate routing logic does not migrate.

OpenText PPM Requests are workflow items used in the demand-management intake process. Active Requests migrate as monday.com Inbox items, preserving submission data, approval status, associated requestor, and request type. Request workflow state transitions from OpenText PPM (Pending, In Review, Approved, Rejected) map to Inbox item status columns. The approval history is flagged as a partial-migration item because not all transition timestamps are exportable from the OpenText PPM workflow audit trail.

OpenText PPM Resources (staff members, equipment, or capacity units) map to monday.com User accounts on the destination account. We resolve Resources by email match where available, creating User invitations for any Resource without an existing monday.com account. Skill profiles, role assignments, and availability data migrate as custom columns on a Resource Management Board or as user-level profile fields. OpenText PPM resource allocation percentages per project map to the Assigned To column and subitem assignments on each project Item. Note that monday.com has no native capacity planning heatmap; this data is preserved as a structured Resource Board that the customer's PMO references manually.

OpenText PPM Financial Lines (cost lines and benefit lines at the portfolio, program, and project levels) migrate as structured data records mapped to custom number or currency columns on the relevant Board or Item. Portfolio-level rollup lines migrate to a Finance tracking Board. Cost and benefit values transfer with their associated period, category, and line type fields preserved as separate columns. We flag that monday.com does not natively support multi-level budget rollup across boards; top-down and bottom-up budget aggregation requires manual reference to the Finance Board or a third-party BI integration.

OpenText PPM extends its base schema with custom properties on Demands, Projects, Resources, Programs, and other objects. Each custom property is enumerated during the pre-migration schema discovery pass, typed (text, number, date, dropdown, checkbox, etc.), and mapped to an equivalent monday.com column type. Dropdown custom properties map to monday.com Dropdown or Tags columns. Date fields map to Date columns. Boolean fields map to Checkbox columns. Custom property groups in OpenText PPM map to monday.com column groups within each Board. We explicitly flag any custom properties that cannot be represented in monday.com's column schema (e.g., complex relational fields) as requiring a note column or external reference.

OpenText PPM project-level and task-level dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) are preserved as monday.com dependency records using the Depend On and Blocks column types. We map the dependency type and any lag value where the column supports it. Dependencies that cross Board boundaries require a Board Integrations connection or are documented as a cross-board dependency note in both Items. Lag values that cannot be represented natively in the monday.com dependency column are preserved in a separate lag days column on the dependent Item.

Documents and attachments associated with OpenText PPM Projects, Programs, or Requests are stored in the platform's file management layer. We extract file metadata (filename, upload date, uploader, file type, and storage path) during the pre-migration file audit and re-upload files to monday.com Item file columns during the migration stream. Binary file transfer runs as a parallel stream to the record migration to avoid blocking the main data import. We preserve the file's association to the correct Item and document its original OpenText PPM storage reference in a notes column for audit continuity.

Time logged against OpenText PPM Projects or tasks migrates as numeric values in a custom Hours Logged column on each Item or subitem. We preserve the time entry date, hours logged, and resource assignment. Approval status on time entries is flagged as a partial-migration item. If the customer uses a monday.com time tracking integration (e.g., a third-party time tracking app from the monday.com Marketplace), we note this as a post-migration configuration step rather than a direct migration target.

OpenText PPM stage-gate program and project lifecycle definitions govern workflow transitions and approval gates. These are not migrated as executable code because monday.com's stage model uses Status columns rather than formal stage-gate templates. We deliver a written inventory of every active stage-gate definition (stage names, gate criteria, approval requirements, and transition rules) mapped to a recommended monday.com Status column configuration and Automations equivalent. The customer's PMO admin rebuilds the stage-gate logic as monday.com Automations post-migration. This is a manual rebuild scope item, not a data migration item.