What OpenProject customization covers
Customization in OpenProject means changing how the platform models your delivery work without changing its source code. The main levers are custom fields on work packages and projects, work package types with their own attributes, status and workflow configuration that controls which transitions each role may perform, project templates that stamp out a consistent structure for new projects, branding, and API-based integrations with other systems. Each lever has different consequences for upgrades and for who can maintain it, so the first decision is which of these your teams actually need.
Customization is usually triggered by one of four situations: reporting needs that the default fields cannot answer, teams that deliver in different ways (for example, a sprint-based product team next to a stage-gated project office), a move from another tool such as Jira or Redmine that carries existing conventions, or a branded rollout to a wider organization. Before building anything, list the statuses, types and fields each team uses today and identify which ones have no equivalent in OpenProject.
Some work fits an in-house administrator well: adding a custom field, creating a type with a standard set of attributes, or copying a project template. Other work benefits from a partner, including workflow designs that mix permissions and status transitions across many roles, integrations that write to external systems, and any change that must be tested against an upgrade path. Confirm with the vendor which branding and workflow features sit in the Community edition and which require Enterprise, since OpenProject lists custom branding among its Enterprise features.
Ask any partner to show the configuration as an exported, documented change set, with a test project that proves each workflow and field behaves as specified. Ask which items will need rework when you move to a newer OpenProject release, and who will own the API tokens and integration accounts after go-live. Those answers determine the maintenance effort, which often matters more than the initial build.
What the work includes
OpenProject customization changes how work is modeled, routed and reported inside your instance. Each area below ends in a deliverable your administrators can review, test and operate after the engagement closes.
Data model design
We map your reporting needs to custom fields, work package types and the attributes each type carries, then check how those choices appear in project forms, filters and Gantt views. The client receives a configuration specification listing every field, type and its project assignments. Confirm which field formats and type options your edition and current release provide before committing to a design.
Workflow and permission design
Status transitions and role permissions decide who can move a work package forward and who can only view it, so they need to match your approval practice. We document each workflow per work package type and role, then test edge cases such as reopening closed items. The client receives a permission matrix and a tested workflow change set. Confirm which workflow and permission controls sit in your edition, since some administration features differ between plans.
Project templates
Templates store the modules, types, statuses, custom fields and starter work packages a new project begins with, which keeps delivery teams from rebuilding the same setup each time. We define which templates exist, who may create projects from them and what must be reviewed afterward. The client receives a template catalog with a setup checklist. Confirm how template copying handles custom fields and permissions in the release you run.
Branding and access controls
Branding covers logos, colors and login presentation, and it is often tied to the Enterprise plan, so the plan decision comes first. We also check that branding changes do not expose internal naming or alter the way administrators navigate settings. The client receives a branding specification and a change record for each visual setting. Confirm the branding options your edition permits before design work starts.
API integrations
Integrations with other systems usually rely on the OpenProject API to read or write work packages, projects and users. We define the data flows, authentication method, service accounts and error handling for each integration, then test them against a staging instance. The client receives a tested integration change set and the credentials inventory needed to operate it. Confirm which API endpoints and authentication options your release supports for each planned flow.
Admin automation and runbook
Repeatable admin tasks, such as bulk user changes, group updates or scheduled housekeeping, reduce manual error when they are scripted and reviewed. We document which tasks are automated, who approves them and how they are rolled back. The client receives a runbook for administrators covering each automated task and its recovery steps. Confirm which administrative actions your installation method and edition expose to scripts before promising automation for them.
What drives cost and duration
This table lists the decisions that most change OpenProject customization effort, why each one matters and how to keep it contained before the build starts.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Custom fields and types | Each custom field must be designed, tested in forms, filters and reports, and migrated if data already exists. Work package types multiply the field sets and workflows that must be maintained. | Reuse existing types where possible. Add custom fields only when a report or decision needs them, and list every field with its owner before the build. |
| Workflows and role permissions | Status transitions, role-based permissions and project-level overrides interact. Each combination needs test cases, and changes often surface in unrelated projects. | Start from the default workflow and change only transitions that a named team needs. Document the permission matrix by role and project type and sign it off early. |
| Project templates | Each template carries its own types, statuses, fields and sub-project structure. Templates that differ slightly from each other become separate maintenance items. | Limit templates to the distinct delivery models in use. Build shared settings once and vary only what the model requires. |
| Integrations (inbound, outbound, identity-linked) | Each integration needs an API contract, credentials, error handling and monitoring. Identity-linked connections such as SSO and group sync depend on your directory structure and on Enterprise features. | Write integration contracts before development, including data fields, direction, frequency and owner. Confirm which identity features your edition includes. |
| Branding and Enterprise-only features | Custom branding and single sign-on are listed among Enterprise features, so they add licensing and configuration work. Branding also adds review of emails, login pages and documents. | Confirm the required edition with OpenProject before scoping. Limit branding to logo, colors and login page unless legal or brand teams require more. |
| Environments (development, staging, production) | Each environment needs its own installation, database, configuration sync and access controls. Keeping them aligned takes ongoing effort, and drift between them causes defects at release. | Keep configuration in version-controlled exports or scripts, and promote changes through environments in the same order every time. Confirm how many environments the quote covers. |
| Testing scope and pilot users | Test effort grows with the number of roles, projects, integrations and pilot groups. Pilot feedback often leads to a second round of configuration changes. | Define test cases by role and workflow, limit the pilot to named groups, and set exit criteria before the pilot starts. |
| Upgrade frequency during the project | OpenProject publishes frequent releases. Each upgrade during the build means re-testing customizations, checking API and integration behavior and repeating the migration rehearsal. | Agree a fixed target release at the start and freeze it for the build. Plan a separate upgrade step after go-live and check release notes for each change that touches your customizations. |
Project phases and outputs
Six phases take the configuration from stated requirements to a production instance that your team can run and change.
Run requirements and configuration audit
Your team and ours review the current OpenProject instance or planned setup, list the teams, project types and reporting needs, and record which features the work needs and which edition provides them. The closing output is a requirements register and a configuration audit that lists every setting, role and custom field in use, so each later decision traces back to a stated need.
Design the data model and workflows
We design work package types, custom fields with their types and options, status transitions, and the roles allowed to change each one. Your process owners review and approve the design. The outputs are a field and type catalog, a workflow matrix that maps each type and role to allowed status changes, and a recorded sign-off before any build starts.
Build in a non-production instance
We configure types, fields, workflows, project templates and branding in a separate non-production instance installed in your infrastructure, and log every change in a configuration record. Where custom code or plugins are needed, we build and review them in the same environment. The output is the built instance, template definitions and a test log showing each design item was checked against the approved matrix.
Build and contract test integrations
We build the API integrations and any identity or Nextcloud links the design requires, then test each one against agreed request and response contracts, including error cases and permission boundaries. Confirm which integration features your edition supports before design closes. The output is an API test suite and an interface specification that your team can rerun after upgrades.
Pilot with live teams
Selected teams use the configured instance for their day-to-day work over an agreed period, and we collect defects, usability feedback and gaps against the requirements register. Each issue is logged, triaged and either fixed or accepted with a named owner. The output is a pilot report listing resolved defects, open items and a go or no-go recommendation for production.
Roll out to production and hand over
We apply the tested configuration to the production instance, run the onboarding and data steps agreed in the plan, and verify access, templates and integrations after cutover. Your administrators receive runbooks, a rollout and rollback plan, and training on configuration changes. Handover closes when your team makes a change through the documented process without our help.
In-house or with a partner
This table shows which customization tasks an OpenProject client team usually keeps and which a partner usually takes, with the skills each side needs for the work.
| Customization work | Usually handled by | Skills needed |
|---|---|---|
| Defining reporting needs | Client team | Business analysis, knowledge of which work package fields matter, OpenProject administration basics, change control |
| Owning custom field values and lists | Client team | Process ownership, OpenProject administration, data quality checks, change control |
| Approving workflows and status transitions | Client team, with partner documentation | Process design, OpenProject administration, approval routing, change control |
| Day-to-day administration of users, projects and templates | Client team | OpenProject administration, role and permission model, onboarding and offboarding procedures |
| Data model design against OpenProject data structures | Partner | Relational data modeling, OpenProject work package types, custom fields and project hierarchy, PostgreSQL basics |
| API integration build | Partner | REST API work, token or OAuth authentication, error handling, test data in non-production environments |
| Environment setup and configuration handling | Partner, with client-provided infrastructure access | Linux administration, Docker or package installation, PostgreSQL basics, secrets handling |
| Regression testing after upgrades | Shared: partner runs scripted tests, client signs off | Test case design, reading release notes, PostgreSQL basics, change control |
What usually goes wrong
Most OpenProject customization problems are not technical failures on day one. They appear months later, when the configuration has grown without owners, reviews or tests. Each card below names a failure pattern and the step that prevents it.
Too many custom fields
Custom fields added one request at a time split the same concept across several fields, so project and work package reports stop matching. Assign a named owner for each field, require a reporting use case before creation, and review the field list at a fixed interval to merge or retire duplicates.
Workflows that block valid status changes
Status transitions limited by role or type can stop a team from closing work that is legitimately done, which pushes people toward workarounds. Write the expected transition map for each work package type before editing workflows, and test each transition with a representative user from every role that needs it.
Permissions set per person
Granting rights to individuals instead of roles creates access that nobody can explain during a review and that persists after people change teams. Define roles per project type, map identity groups to those roles, and audit role assignments against the access policy rather than against individual requests.
Templates that drift from live configuration
Project templates copied from an older project gradually stop matching the current types, statuses and fields, so new projects start with broken or outdated setups. Keep the template definition in version control, and run a test case per template that creates a project and checks types, statuses, fields and permissions.
Integrations built on undocumented behavior
Scripts that depend on internal responses, unpublished endpoints or field ordering can fail silently after an update. Build integrations only against documented API endpoints, record the OpenProject version each integration was tested with, and keep an integration test suite that runs before every upgrade.
Enterprise features assumed on a lower plan
Single sign-on, LDAP group synchronization and custom branding are listed among Enterprise features, so a design that assumes them on Community or a lower plan will not work as planned. Confirm each required feature against the current pricing page and the edition quoted before the design is approved.
Configuration broken by a minor release
Minor releases such as 17.7.0, 17.8.0 and 17.9.0 can change behavior that custom workflows, templates or scripts rely on. Run a pre-upgrade regression pass on a staging copy with production-like data, and review the release notes for each version between your current release and the target before scheduling the change.
How the work changes by situation
When a team moves configuration and history from another tracker, the mapping work comes first. Scope grows with how much of the source setup has to be recreated, not only the data.
- Scope: map statuses, work package types, custom fields and workflows from the source tool before any import runs. The Jira Migrator is in beta and covers Jira Data Center 10.x and 11.x only, so other sources need their own plan.
- Test: run trial imports into a non-production instance and check work package counts, relations, users and groups by sampling real projects with the teams who use them.
- Operating burden: items the importer does not carry, such as workflows and permissions in the current beta, remain manual work that your team or a partner must finish and verify.
- Ask: what the source system exports and through which API, and which configuration must be rebuilt by hand.
When an existing Community installation is extended, the main risk is breaking what already works. Scope is defined by the changes on top of a live configuration.
- Scope: add custom fields, types and workflows on top of existing projects, and confirm early which needs (single sign-on, LDAP group synchronization, custom branding) require the Enterprise edition.
- Test: clone the production database into staging and run regression checks on permissions, existing reports, Gantt views and time tracking before each change reaches users.
- Operating burden: configuration changes persist across releases, so each minor upgrade requires a review of custom fields, workflows and any integrations that depend on them.
- Ask: an inventory of current customizations, plugins and integrations, with an owner for each.
A multi-department rollout with separate templates is mainly a governance problem. Scope depends on which settings are shared across departments and which belong to one team.
- Scope: design project templates per department, decide which work package types and custom fields are global, and size the edition by named users, since Enterprise plans are priced per named user.
- Test: build a role-based test matrix for each department and confirm that instantiating each template produces the expected project structure and permissions.
- Operating burden: each department will request its own fields and workflows, so a change board, template owners and a review step for new global fields need to exist before rollout.
- Ask: who approves template changes, and how a change to a shared field affects existing projects.
Docker is the recommended installation method, and customizations in a container setup must survive the container lifecycle. Scope depends on how configuration and assets are supplied to the image.
- Scope: decide which customizations are delivered through mounted configuration, environment settings or a derived image, and confirm which mechanism your release version supports.
- Test: rebuild the deployment from scratch in staging and confirm that branding, fields and integrations persist after containers are recreated.
- Operating burden: image versions must be pinned, and each upgrade replaces containers, so configuration belongs in version control with a documented rollback path.
- Ask: how the vendor documents custom assets and whether any customization requires rebuilding the image.
A packaged deployment uses .deb or .rpm packages on the host, so customizations live in the filesystem and configuration files of the operating system. Scope depends on the distribution and its release.
- Scope: confirm that your distribution and release are on the supported list, including Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and that PostgreSQL 16 or later with the required extensions is in place.
- Test: validate every customization on the same operating system release and database version used in production, since package behavior can differ between them.
- Operating burden: operating system patching and package upgrades are linked, so host changes, package pinning and maintenance windows must be planned together.
- Ask: which host paths hold customized files, and how they are backed up and restored.
In an air-gapped environment, every integration must resolve inside the network. Scope is shaped by what the platform would otherwise reach outside the boundary.
- Scope: identify every external dependency, including identity providers, mail relays, Nextcloud or other integration endpoints, and branding assets, and plan internal alternatives for each.
- Test: run egress checks to confirm that the instance makes no outbound calls it was not designed to make, and test integrations using internal certificates.
- Operating burden: updates and packages arrive by controlled transfer, so release review, a staging path and certificate renewal become fixed recurring tasks.
- Ask: how the vendor delivers release artifacts to offline networks, and which features need external services.
What you need to provide
Most customization delays come from missing inputs, not from the build itself. Before work starts, we need a named product owner who can make decisions about the data model: which custom fields exist, which work package types a team uses, and which statuses and transitions match how work actually moves. Without one person empowered to sign off, each open question waits for a meeting, and the schedule slips. The quote assumes this role is filled by the client and is not shared across several part-time stakeholders.
We also need admin access to a non-production OpenProject instance where changes are built and tested, plus the current process documentation or the tool the work is moving from. For workflows, that means the existing status path and who moves items between states. For reporting, it means sample projects and the reports people request today, with real structure but no sensitive content. Each missing sample adds discovery time, and each unclear rule tends to become rework after UAT. Ask for these in writing at scoping, and confirm which parts of your process are informal.
Integration endpoints and test credentials are the next dependency. Any API integration needs endpoints, scoped test credentials and a named contact who can change the other system when a test fails. Credentials should be limited to the test scope, not production. The edition decision also drives scope: Community includes the core work package, board and reporting features, while custom branding and single sign-on sit in the Enterprise plans. Confirm the edition and, for Enterprise on-premises, the per-user plan and user count, since pricing is set per named user with minimums. Finally, name the approvers for workflow and permission changes, because access rules are the most sensitive changes and need a formal sign-off path.
Frequently asked questions
How much does OpenProject customization cost in general terms?
Cost depends on the scope agreed in writing, and DeployOpen does not publish prices. Effort rises with the number of custom fields, work package types, workflows and project templates, plus any API integrations, branding and identity work. Licensing is a separate recurring cost. The OpenProject pricing page lists Enterprise on-premises plans per named user per month: Basic at 5.95 euros, Professional at 10.95 euros (25-user minimum) and Premium at 15.95 euros (100-user minimum), with Corporate on request for 250 or more users. Ask any quote to separate one-time work from recurring licenses and support.
How long does an OpenProject customization project take?
The timeline depends on scope, so no single duration fits every project. A small set of custom fields and one project template is far simpler to plan than workflows for several work package types, API integrations and branding across multiple teams. Most DeployOpen engagements are fixed-scope, meaning phases, deliverables and timelines are agreed in writing before work starts. Ask each provider which items are included, how testing and sign-off are counted, and which steps depend on your reviewers or identity team.
Can our in-house admin customize OpenProject without outside help?
Often partly, depending on the admin's experience and the change. Common settings such as custom fields, work package types, statuses and project templates are generally managed in the administration area, while workflow design, API integrations and identity work need engineering skill. Branding and single sign-on also require an Enterprise plan. Confirm for your release which settings the admin interface supports and which need the API or code, and test each change in a non-production instance before applying it to production.
Which OpenProject features need an Enterprise plan?
The OpenProject pricing page lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding as Enterprise features. Confirm each feature's edition on the pricing page for your version before scoping, because feature lists change between releases. The Nextcloud integration page also describes OpenID Connect single sign-on as an Enterprise add-on. Work packages, Gantt charts, agile boards, time tracking and dashboards are included in the free Community edition.
What must our team provide before an OpenProject customization starts?
Your team typically supplies named process owners, written requirements for each work package type, workflow and template, and sample projects that reflect real data. You also need a test instance, administrator accounts, network access to the environment and, for single sign-on, access to your identity provider. Branding assets and reviewers with time booked for sign-off are needed as well. Ask the quote to list each client-side dependency with an owner and a date, so delays in your own team are visible early.
How do OpenProject customizations hold up during version upgrades?
Each upgrade needs a check of your customizations, because no one can promise that every change carries over unchanged. OpenProject ships minor releases often, including 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026. Review the release notes for each version, retest custom fields, workflows, templates and API integrations in staging, and confirm with your provider how upgrade testing and rollback are scoped. Record which customizations rely on the API, since those are most exposed to endpoint changes.
How DeployOpen works on this
DeployOpen plans, builds, tests, documents and supports OpenProject customizations inside your own infrastructure, so custom fields, types, workflows, templates and API integrations stay under your control. Engagements are fixed-scope, with the work agreed in writing before it starts.
How we scope
- The written scope lists each custom field, work package type, workflow, project template and branding change to be delivered.
- Each customization is checked against the edition in use, since some features such as custom branding require an Enterprise plan.
- Integrations with Nextcloud, identity providers or other APIs are named with their data flows, owners and access rights before build.
How we build
- Customizations are built and tested in a non-production instance that mirrors your OpenProject version and installation method.
- Workflow and permission changes are reviewed against each role, project and group your teams use before they reach production.
- API integrations are developed against documented endpoints, with error handling, credentials stored outside code and test data only.
How we hand over
- Deliverables include configuration records, change notes, the API integration code and an updated runbook for your administrators.
- Your team walks through each customization with test cases so acceptance is recorded against the written scope.
- Changes are deployed with a rollback path, and the handover states what your administrators maintain after go-live.
How we support
- Ongoing support, upgrades and testing after handover are available as a retainer, scoped separately from the build.
- Customizations are retested when OpenProject releases a new version, so upgrades do not silently break fields, workflows or integrations.
- Confirm with DeployOpen which support tier and response terms apply to your environment before signing the written scope.
