Migrate from OpenText Project and Portfolio Management (PPM) to Trello

OpenText PPM Portfolios aggregate Programs and Projects for executive governance with top-down budget rollups and strategic alignment data. Trello has no portfolio object. We create a written Portfolio Inventory document listing every Portfolio, its member Programs and Projects, total budget allocation, and strategic theme. For small portfolios, a single Workspace can serve as the umbrella with board naming conventions (e.g., prefix: [Program Name]) that preserve grouping logic in the customer's operational documentation.

Programs group related Projects under shared governance and financial rollup. Trello does not natively group Boards. We document every Program-to-Project membership in a Program Registry and optionally create a Trello Workspace per Program where the Program Manager serves as Workspace Admin. Projects within the Program map to Boards within that Workspace, preserving the grouping relationship through Workspace structure rather than a data field.

OpenText PPM Projects map directly to Trello Boards. We migrate Project name (Board title), Project description (Board description), start and end dates (stored as custom fields or card due dates on the first card), owner (Workspace Member or Board Admin), and custom properties (encoded as Power-Up Custom Fields or Board Labels). Project status (active, on hold, closed) maps to Board visibility (public/private/archive) or a Status label on the board's first list.

OpenText PPM task work breakdown structure items map to Trello Cards on the relevant Board List. Task name becomes Card title, task description becomes Card description, assigned resource becomes Card member, start and due dates become Card dates, and task hierarchy (parent-child) maps to Card hierarchy using Trello Cards Power-Up or checklist-based sub-tasks. Dependencies to other Projects cannot be represented as native Trello card links; we document these as cross-board references in the card description and in the Dependency Registry delivered with the migration.

OpenText PPM Demands represent incoming work requests or ideas that feed project intake. Trello has no native demand management object. We migrate active Demands as Cards in a dedicated Backlog or Inbox List on the relevant Board, preserving demand title, requestor, priority, and status. Intake workflow routing information documents separately as the customer's demand management process handoff guide.

Requests are workflow items in the demand-management intake process with submission data, approval status, and associated requestor. Active Requests migrate as Cards in an Intake or Request Queue list on the relevant Board, with approval status captured as a label or Custom Field. Workflow state transitions do not migrate; these are documented for the PMO to implement in Trello Butler or as a separate intake tool if the process is complex.

OpenText PPM Resources (staff members with skill profiles, availability calendars, and role assignments) map to Trello Workspace Members. We migrate resource name, email, and role. Skill profiles and availability calendars have no native Trello equivalent; we deliver a Resource Skills Register documenting skills, proficiency levels, and allocation percentages for the PMO to use in resource planning. Workload visualization requires a Power-Up or external resource management tool.

Cost and benefit financial lines at the portfolio, program, and project level cannot be stored natively in Trello Boards or Cards. We extract financial line data (cost type, amount, period, category) as a structured Financial Data Register delivered as a CSV and PDF inventory. Customers who require financial tracking in Trello use a Power-Up integration with an external financial tool or maintain cost data in a linked spreadsheet referenced from the Board description.

OpenText PPM cross-project and cross-task dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) are preserved in a Dependency Registry during migration. Within a single Board, Cards can use the Cards Power-Up dependency feature to establish blocking links. Cross-Board dependencies document in the registry with a link reference in the dependent Card's description. This is a known limitation; Trello's dependency representation is less formal than OpenText PPM's dependency tracking.

Stage-gate workflow definitions governing project approval transitions do not have a Trello equivalent. Trello Butler supports rule-based triggers (when a card moves to list X, set due date to Y, notify member Z) but does not model multi-stage approval chains. We deliver a Stage-Gate Workflow Inventory listing every project lifecycle stage, approval gate, and transition condition for the PMO to implement manually in Butler or to use as a guide for manual governance.

OpenText PPM custom properties vary by instance and can exist on Demands, Projects, Resources, and other objects. We enumerate every active custom property and data type during schema discovery, then encode each as either a Trello Custom Field (for text, number, date, checkbox, dropdown) or a Label (for categorical values with fewer than 50 distinct values). Power-Up Custom Fields require the Standard or Premium Trello tier; if the destination Workspace uses the free tier, categorical custom properties fall back to Label encoding.

Documents attached to Projects, Programs, or Tasks in OpenText PPM's file management layer require a parallel transfer stream. We extract file metadata (filename, type, size, storage path) and re-upload attachments to Trello Cards using the Card Attachments feature or a linked Power-Up document management layer. Association to the correct Card is resolved by matching the source record ID. Binary files stored in OpenText PPM's document repository are transferred as a file package alongside the data migration, with a manifest mapping file to Card.