Open source project portfolio management

Why open source project portfolio management is a different job for a PMO

A PMO running many projects at once needs one place where those projects, their shared people and their budgets can be seen together, and that place is usually the hardest part of the stack to replace later. Several concurrent projects compete for the same engineers, designers and approvers, executives expect budget figures that reconcile across programs, and the project data itself often includes staff time, client names and cost details that many organizations do not want stored in a US-hosted SaaS tool. For self-hosted portfolio work, OpenProject should be the first platform to evaluate. Plane and Redmine are narrower alternatives that may fit specific teams, but neither should be the default choice for a portfolio view across the whole organization without a proof of concept.

The OpenProject Community edition, licensed under GPL-3.0, already covers much of the core portfolio job: work packages, Gantt charts, agile boards, time and cost tracking, budgets, custom fields, workflows and project templates. Single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding sit in the Enterprise plans instead. For a PMO, that split changes the decision. If executives will sign in through the corporate identity provider and project membership must follow directory groups, the edition choice is made before any template is built. Confirm with the vendor which edition covers each requirement on the current pricing page, and test cross-project reporting against a realistic copy of your data before committing.

Which requirements a portfolio platform must meet and what they mean for the build

This table maps the requirements a PMO platform typically has to meet to the configuration, hosting and edition decisions each one creates in OpenProject. Read it as a checklist: confirm each requirement with your auditors, security team and records owner before choosing an edition or hosting model.

Requirement	What it means for the build	Evidence to keep or confirm
Cross-project status and budget reporting	Portfolio dashboards and cost tracking are part of the Community edition, but confirm the report depth and export options you need against the current OpenProject feature list before standardizing on them.	Sample portfolio report, budget versus actuals export, and a documented reporting owner for each program
Program hierarchies	Model programs as parent work packages or projects with subprojects and confirm that roll-ups behave as expected at the depth your PMO uses; test this with a copy of real structure before rollout.	Approved program structure diagram and a test record showing roll-up totals
Reusable project templates	Use OpenProject project templates to enforce standard phases, custom fields and workflows so each project starts with the same status and budget fields.	Template inventory with version and owner, and change log for template edits
Audit of changes to budgets and status	Budgets, status and cost entries are the records most likely to be questioned. Confirm which change history is retained, for how long, and whether it can be exported without database access.	Change history export sample, admin log retention setting, and a named reviewer for budget changes
Access control by portfolio	Restrict visibility by project membership and role. Confirm that roles can limit who sees budget fields, and document the admin accounts that can change permissions.	Role matrix per portfolio and a periodic access review record
Retention of project records	Project records, comments and attachments may fall under internal retention schedules. Where a regulated firm keeps business communications about projects, SEC Rule 17a-4(b)(4) requires preserving those communications for not less than three years, so confirm with counsel whether project comments count and set backup and archive rules accordingly.	Written retention schedule, backup restore test, and legal hold procedure
Audit controls on systems with health data	If project records contain ePHI, the HIPAA Security Rule audit controls in 45 CFR 164.312(b) require mechanisms that record and examine activity. Confirm log coverage, forwarding to your SIEM and who reviews it.	Audit log configuration, log forwarding evidence and review sign-off
Single sign-on and directory sync	SAML, OIDC, Kerberos and LDAP group synchronization are listed as OpenProject Enterprise features. Confirm which identity method your directory requires before choosing the Community or an Enterprise edition, because identity wiring affects offboarding and access reviews.	Identity design note, group mapping table and offboarding test result
Hosting location and transmission security	Self-hosting in your own cloud or data center keeps project data under your controls. Transmitted project data must be protected in transit under 45 CFR 164.312(e)(1) where ePHI is involved, so confirm TLS termination, PostgreSQL connections and backup transfer paths.	Network diagram, TLS configuration and PostgreSQL connection settings

Which platforms fit portfolio work and why

Portfolio management depends on cross-project views, programs, templates and reporting, not just task boards. The three platforms below differ mainly in how deep their portfolio layer goes and how much of it sits in the free edition. Confirm each capability against the vendor before you rely on it in a PMO design.

OpenProject for portfolios

OpenProject is the strongest starting point for a PMO, licensed under GPL-3.0 and available on premises or in the cloud. The free Community edition lists work packages, Gantt charts, agile and Kanban boards, budgets, time and cost tracking, project templates, custom fields and workflows, which covers much of the per-project layer. Confirm which portfolio and program views, cross-project reports and roll-ups are in the Community edition versus Enterprise before you commit to a design.

Enterprise identity for PMO access

Single sign-on through SAML, OIDC, CAS, Kerberos or Okta and LDAP group synchronization are listed among OpenProject Enterprise features, not the Community edition. For a PMO, this matters because portfolio visibility should follow directory groups rather than manually maintained memberships. Price the Enterprise tier per named user from the start, since the per-user price depends on the user count tier, and confirm that the directory and identity provider you use are covered.

Plane for issue-tracking teams

Plane is licensed under AGPL-3.0 and its latest release in the supplied facts is v1.4.2, published on August 23, 2026. It is built around issue tracking, cycles and modules, which suits delivery teams that want fast backlogs. Its portfolio depth is the item to verify: confirm whether it offers program-level roll-ups, budget tracking, baselines and cross-project reporting that a PMO requires, and whether those features sit in a paid tier.

Redmine as a fallback

Redmine is a long-established open source project tracker that many organizations already run. Its core covers issues, versions and time tracking, but several portfolio views and cross-project reports are usually added through plugins. Each plugin adds an upgrade and support obligation, so list every plugin your reporting depends on, check its compatibility with the Redmine version you plan to run, and confirm who maintains it after go-live.

Hosting and sizing constraints

Portfolio data is sensitive because it reveals budgets, staffing and strategy, so hosting choices carry weight. OpenProject supports Docker-based installation, packages for Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15, and Kubernetes with Helm charts. Its sizing guide gives 4 cores and 4 GB RAM for up to 200 users, and PostgreSQL 16 or later is required. Confirm sizing for your largest portfolio before procurement.

How a PMO rollout moves from pilot portfolio to full reporting

The sequence moves a PMO from an inventory of projects and reporting needs to a tested pilot, a settled identity and edition choice, a checked data migration and a handover that leaves the portfolio team able to report on its own. Each phase ends with a named output that the next phase depends on.

Inventory projects, budgets and reporting needs
The PMO lists every active and planned project, its sponsor, owner, budget lines, status cadence and the reports that leadership and finance receive today. Engineering or IT staff confirm which existing tools hold project data and whether any of it is in spreadsheets. The output is a written inventory with one row per project and a list of required portfolio reports, each tied to a named consumer. The step is done when the PMO lead and finance sign off that the list covers every report currently sent to steering committees.
Design templates and programs
The team turns the inventory into a small set of project templates covering common work types, plus programs that group related projects under one sponsor. Each template defines work package types, statuses, custom fields for budget and risk, and the workflow approvals the PMO needs. Program structure and custom field names are agreed with finance so that budget figures mean the same thing in every project. The output is a template library and a program hierarchy approved by the PMO and one business owner for each program.
Pilot with two or three active portfolios
Two or three live portfolios run in OpenProject alongside their current tools for a fixed period agreed in advance. Project managers record status, work packages, time and costs in the new templates, and the PMO checks that the cross-project views produce the same totals as the existing spreadsheets. Problems with custom fields, permissions or report layouts are logged and fixed before any wider rollout. The output is a pilot findings log and a signed decision from the PMO on which template changes are required before expansion.
Decide identity and edition
Before wider rollout, the team confirms how users sign in and whether directory groups must drive project membership. Single sign-on through SAML or OIDC and LDAP group synchronization are listed by OpenProject as Enterprise features, so the choice of edition depends on whether these are mandatory. The team also confirms the user count per tier and the support requirements with the vendor and the implementation partner. The output is a written edition decision and an identity design that names the identity provider, group mapping and who approves access changes.
Migrate project data with checked scope
Data moves from existing tools in batches, starting with the pilot portfolios. Where the source is Jira, the team must confirm the instance type first, because the OpenProject Jira Migrator is in beta, imports only from Jira Data Center 10.x and 11.x, and is not supported for Jira Cloud. The documentation advises using it only in test setups, so production migrations for in-scope instances need a manual or partner-led approach agreed in writing. For every batch, the team compares record counts, owners, dates, budgets and attachments against the source. The output is a reconciliation report per batch, with each gap either fixed or accepted by the sponsor.
Cut over and hand over reporting
The PMO sets a cutover date for each portfolio, freezes edits in the old tool, runs a final delta migration and switches status reporting to OpenProject. Portfolio dashboards and cross-project reports replace the old pack, and the PMO runs one full steering cycle from them before the old reports are retired. Administrators receive runbooks for user onboarding, template changes and backups, and the PMO team is trained to build and adjust reports without vendor help. The output is a signed cutover record and a handover pack that the PMO can operate without the implementation team.

Which OpenProject edition fits which PMO situation

A PMO that manages its own user accounts, has no central directory it needs to tie into, and does not require single sign-on can often start on the free Community edition. The Community edition includes work packages, Gantt charts, agile and Kanban boards, Scrum, time and cost tracking, budgets, project templates, custom fields, workflows and the REST API, so portfolio planning and cross-project tracking do not by themselves require a paid license. The trade-off is that identity administration stays manual and support is community-based.

Account administration: Users are created and deactivated inside OpenProject, so joiners and leavers must be handled by a process your PMO owns.
Feature coverage: Portfolio planning, budgets and templates are part of the Community edition according to the OpenProject pricing page.
Support model: Community support is the default, so response expectations must be set by your own internal ownership.
Growth path: Moving to Enterprise later is possible, but confirm how the upgrade, license activation and data stay in place for your deployment.

Before committing, check the OpenProject pricing page for the current feature list and confirm with OpenProject that the Community edition meets your audit and access review needs.

Deployment pattern and integration points for a PMO instance

A PMO instance of OpenProject is mostly a question of where it runs, what database it depends on and how it connects to the files and reports around it. The cards below cover the supported install paths, the database prerequisites, sizing by user count, scaling, the Nextcloud link and the REST API that feeds cross-project reporting.

Docker as the default install

OpenProject documents Docker-based installation as the recommended path, so most PMO teams should start there unless their operations standard requires packages. A container install keeps the application, its dependencies and the upgrade steps in a defined form that your platform team can version and back up. Check who owns image pulls in an air-gapped or restricted network, and confirm how the vendor publishes each release so you can stage upgrades in a test environment before production.

Packaged installs on supported Linux

If your standard requires operating system packages, OpenProject provides .deb and .rpm packages for 64-bit Linux. The documented supported distributions are Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Confirm that your base image matches one of these versions, because an unsupported host is a common reason an upgrade stalls. Record the distribution and version in your configuration baseline so that audit and patching reviews can match it to the supported list.

PostgreSQL 16 and required extensions

Since OpenProject 16.0.0, PostgreSQL 16 or later is the officially supported database. The installation also requires the pg_trgm, btree_gist and unaccent extensions, so a managed database service must allow them before you schedule the install. Ask your DBA to confirm extension availability, backup and point-in-time recovery, and the maintenance window for minor upgrades. A missing extension is found at install time, so verify it in a staging database first.

Sizing bands by user count

OpenProject's sizing guide gives starting points: 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Treat these as the vendor's baseline, not a capacity plan. Portfolio dashboards, large Gantt charts and heavy reporting queries raise load beyond headcount, so ask your implementation partner to validate the band against your project count and expected concurrency before you commit to hardware.

Kubernetes and Helm for scaling

For horizontal scaling, OpenProject supports Kubernetes deployment with Helm charts. This suits PMOs that already run a cluster and need several application replicas across sites or peaks in reporting use. Be clear about what you own: the cluster, persistent storage, the database, ingress and certificate management all stay with your team, and a Helm upgrade still needs a tested rollback path. A single well-sized Docker host is often simpler to operate for a single PMO.

Nextcloud link for project files

OpenProject's Nextcloud integration lets work packages reference documents stored in Nextcloud, so project charters, budgets and contracts stay in the file system your organization already governs. Check which accounts and folder permissions the integration uses, because a link can expose a file to people who see the work package but not the folder. Confirm single sign-on across both systems and the edition needed for it before you design the folder structure.

REST API for cross-project reporting exports

The REST API, included in the Community edition, is the usual route for pulling work packages, projects and time entries into a data warehouse, BI tool or finance system for portfolio reporting. Decide early which fields the PMO needs, who holds the API tokens, and how often extracts run, since a scheduled export is a service account with broad read access. Test the export against your largest project set and confirm how it handles custom fields and archived projects.

Evidence a PMO or auditor will ask for, and which component produces it

This table maps the records a PMO, internal audit or an external assessor is likely to request for a portfolio, to the OpenProject feature, operating record or operations process that produces each one. Read it as a checklist to settle ownership before an assessment starts. DeployOpen prepares the systems, controls and evidence, but auditors or certification bodies issue any assessment or attestation.

Evidence requested	Component that produces it	What to confirm before an assessment
Change history on budgets and cost items	OpenProject work package and cost journal history, with time and cost tracking enabled on the relevant projects	Confirm which budget changes are recorded in the platform and which still need an approval record kept outside it
Access reviews by portfolio and project	Project membership and role assignments exported through the OpenProject REST API or admin views, reviewed on a set schedule	Confirm the review owner, the review cadence and where signed review records are stored
Role and permission definitions	OpenProject roles and workflow configuration, documented as code or configuration exports held under change control	Confirm which roles are standard, which were customized, and who approved each permission set
Single sign-on and directory mapping records	Identity provider configuration and LDAP group synchronization, which are Enterprise features on-premises	Confirm the edition supports the required SSO and directory sync, and keep the identity provider's own logs alongside
Backup and restore test records	Database and attachment backups of the PostgreSQL instance and file storage, plus logged restore tests	Confirm a restore has been tested into a separate environment and that the test result is recorded, not only the backup job
Release and patch records for the OpenProject version in use	Installed version recorded in the deployment configuration, matched against the OpenProject release notes, for example 17.9.2 published October 15, 2026	Confirm the change ticket for each upgrade, the test environment used, and the date the instance was patched
Platform hardening and system requirements evidence	Host and database configuration checked against the OpenProject system requirements, including PostgreSQL 16 or later and required extensions	Confirm the baseline configuration is documented and that deviations were approved
Audit logs of administrative and privileged actions	OpenProject administration logs combined with host, container and database logs forwarded to a central store	Confirm retention periods with the policy owner, since these are set by the organization rather than the product

What do buyers ask before hiring a partner for portfolio management?

What drives the cost of an OpenProject portfolio implementation?

The cost is driven by scope, not by the software license. The Community edition is free to download and run, so you pay for the work around it: planning the program and template structure, configuring portfolio views, custom fields and workflows, setting up hosting, and migrating existing project data. Costs rise with the number of projects, the number of report definitions, the number of integrations (such as Nextcloud or single sign-on), and the number of legacy tools being retired. Ask any partner for a fixed-scope quote that lists each deliverable, who performs it, what is one-time, and what recurs, such as hosting, upgrades and support. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How long does it take to get a working portfolio in OpenProject?

The timeline depends on how many projects, programs and budget owners must be modeled and how clean the existing data is. A working portfolio needs an agreed project inventory, a set of program and project templates, defined status and budget fields, and a first cross-project report that the PMO accepts. Confirm with any partner which of these are in the fixed scope, how many review rounds are included, and when the portfolio goes live versus when it is fully populated. No duration should be accepted without a written plan that ties each milestone to a named deliverable.

What must the PMO provide before a partner starts work?

Three inputs decide most of the early effort. First, a project inventory: every active and planned project, its owner, its status, and the systems where its data lives. Second, named budget owners who can confirm planned and actual budgets and approve the cost fields. Third, report definitions: the specific portfolio views, roll-ups and exports that leadership uses today, with a sample of each. A partner can build templates and dashboards faster when these exist in writing. If they do not, expect a discovery phase before configuration starts, and ask for it to be priced separately in the quote.

Can our own team self-host OpenProject without a partner?

Yes, a capable platform team can install and run OpenProject alone. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, Docker-based installation is recommended, and Kubernetes with Helm charts is available for horizontal scaling. The team must also run PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, size the servers (the sizing guide suggests 4 cores and 4 GB RAM for up to 200 users), and own backups, patching and upgrades. Ask yourselves whether those duties have an owner before deciding to build in-house, partner, or buy a hosted service.

What does Enterprise cost per user, and what are the minimums?

OpenProject Enterprise on-premises is priced per named user per month. The published tiers are Basic at 5.95 euros and Professional at 10.95 euros, both with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users, according to OpenProject's pricing page. Enterprise features include single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding. Before you choose a tier, confirm which of these features your portfolio truly needs, because the minimum applies even to a small PMO group. Check current pricing with the vendor, since the figures above are the published amounts.

How well does the Jira migrator handle portfolio history?

The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not from Jira Cloud. It is in beta, and the documentation advises using it only in test setups. For a PMO, this means that historical work items, workflows and custom fields may not map one-to-one, and some portfolio reports built on Jira data will need to be rebuilt by hand. Ask a partner to list, object by object, what migrates, what is transformed, and what is left behind, and to run a test migration against a copy of your data before any production import. Confirm the Jira version you run before planning.

How are OpenProject upgrades handled after go-live?

Upgrades are a recurring cost that should be written into the scope. OpenProject publishes regular releases, such as 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026, and 17.9.0 on September 30, 2026, and 17.9.2 on October 15, 2026, and the release notes list changes for each. A supporting partner should test each upgrade on a staging copy, check plugin and integration compatibility, back up the database first, and schedule the change window with your PMO. Ask whether upgrades are included in a support retainer or billed separately, and who signs off before production changes.

Questions to ask an implementation partner before you sign

Start with the portfolio features themselves. Ask the partner to list, feature by feature, which portfolio views, program structures, project templates and cross-project reports they will configure on the Community edition and which depend on an Enterprise plan. The OpenProject pricing page lists work packages, Gantt charts, agile boards, budgets, custom fields, workflows, project templates and the REST API under Community, so a partner should be able to show that list against your PMO requirements. Ask them to name any reporting or roll-up view they plan to build with custom work, such as a configuration or an export script, and who maintains it after handover. A partner who cannot separate edition features from custom code is not ready to quote a fixed scope.

Next, pin down identity before the scope is final. Single sign-on (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are listed as OpenProject Enterprise features, and Enterprise on-premises licensing is per named user with minimums by tier, so the user count drives the edition and the annual cost. Ask the partner which tier they assume, how group-to-role mapping will be set up and tested, what happens to users who leave the directory, and whether the quote includes the licenses. Ask them to confirm the current tier minimums and prices in writing, because they change. Ask how the SSO setup will be checked against your identity provider before go-live.

For Jira Data Center data, ask the partner to state the source version and the importer limits in writing. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not Jira Cloud, and its documentation labels it beta and suitable only for test setups. Ask what they will migrate (projects, work item types, workflows, custom fields, users, attachments, time entries and history) and what they will rebuild by hand or drop. Require a written list of expected losses, a test migration into a non-production instance, and a reconciliation of project counts and open items before cutover. Also ask how they will handle upgrades: which minor releases they test against, in which environment, and how they will confirm that portfolio reports and templates still work after each one.

How DeployOpen scopes, builds and supports a PMO platform

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For portfolio management, we start from the portfolio views, program structures and reporting your PMO needs, then agree the scope in writing before any build work begins.

How we scope

We inventory the programs, projects, templates and reporting packs the PMO must run in OpenProject
We map which features sit in the Community edition and which need an Enterprise plan, confirmed against current vendor pricing
We agree in writing the hosting target, identity integration, data migration boundaries and acceptance criteria before work starts

How we build

We deploy OpenProject in your cloud account, data center or air-gapped network using the installation method your operations team supports
We configure portfolio views, project templates, custom fields, workflows and budget structures to match your governance model
We test permissions, cross-project reports and backup restores, and document the configuration for your administrators

How we hand over

We deliver runbooks covering installation, upgrades, backups, user and group administration and template change control
We train PMO administrators and project managers on the configured templates, reports and portfolio views
We provide the configuration record and test evidence so your auditors or internal assurance teams can review the setup

How we support

Ongoing support, version upgrades and continuous testing are available as retainers agreed separately from the initial scope
We plan upgrades against the vendor release notes and test them in a staging environment before production changes
Support scope, response expectations and service levels are defined in the retainer agreement, which you should review before signing