How OpenProject BIM for construction fits project teams that exchange models and issues
OpenProject BIM for construction can serve as the shared project record on infrastructure you control, provided the edition covers the model viewing, issue exchange and Revit connection your teams need. Owners and contractors whose design, coordination and site teams work across several BIM tools often end up with issues split between model viewers, spreadsheets and email. The question is whether one self-hosted instance can hold the issues, the linked models and the decisions behind them, so that a BCF topic raised in one tool can be traced to a work package and a site action. Confirm this against the edition documentation before scoping, because the answer depends on which IFC, BCF and Revit functions the edition provides.
For project controls, the main change is that issues with schedule or cost consequences stop living in a separate register. Work packages can carry status, dates and responsibility, so controls staff can report from the same records that BIM coordinators close. Document control gains a clearer link between a drawing or model revision and the issue it triggered, but the document management system of record may still be needed for formal transmittals and approvals. Plan that boundary early. BIM coordinators take on the most change: they must agree which discipline owns each BCF topic, how model revisions are named, and who closes an issue once a clash is resolved in the authoring tool.
Before scoping, confirm the following in the edition documentation: which IFC formats the browser viewer reads and how it handles large files, which BCF versions the import and export support, whether the BCF exchange works with the authoring tools on your project, and whether the Revit add-in is included or needs a separate license or Enterprise plan. Ask the vendor for these answers in writing. Then test each one with a sample model from your own project, including the naming conventions and federated structure your teams actually use, so the test shows how the edition behaves on your data.
Hosting and access decisions follow from those answers. The Docker-based installation is the recommended route, and the system requirements call for PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Single sign-on and LDAP group synchronization are listed among Enterprise features, so partners who need federated sign-in should include that cost in the per-user comparison. The sizing guidance is written by user count and does not address model file size, so test storage, backup duration and viewer response with your largest federated model before rollout.
Which construction requirements shape the OpenProject build
This table maps common construction project requirements to the OpenProject facts that shape the build, and marks BIM-specific capabilities that still need vendor confirmation. Read each row as a decision to settle before deployment starts. The main takeaway is that identity, hosting and database choices are fixed early, while model viewing and issue exchange should be tested with your own BIM tools in a pilot.
| Requirement | Supplied OpenProject fact | What it means for the build |
|---|---|---|
| Model sharing (IFC models in the browser) | IFC model viewing is part of the BIM edition scope. Confirm which edition and plan include it. | Confirm with the vendor which edition provides browser IFC viewing, supported file types and file size limits. Size the file storage on your own servers for large model files. |
| Issue exchange with other BIM tools (BCF) | BCF exchange is part of the BIM edition scope. No BCF version or tool compatibility is confirmed here. | Confirm the supported BCF version and import and export behavior with the vendor. Test a round trip with each BIM authoring tool your project teams use before committing to a workflow. |
| Access for external designers and subcontractors | Enterprise SSO and LDAP group synchronization are Enterprise features. Pricing is per named user per month. | Plan external users as groups in your directory so project access follows membership. Confirm with the vendor whether external users can be provisioned through SSO and how they count toward named-user licensing. |
| Single sign-on | Enterprise SSO covers SAML, OIDC, CAS, Kerberos and Okta. LDAP group synchronization is also an Enterprise feature. | Choose the identity source before installation, since SSO and group sync require the Enterprise plan. Confirm which protocol your identity provider uses and test group mapping with a sample project team. |
| Data residency | OpenProject is hosted on premises. Docker is recommended, with .deb and .rpm packages, and Kubernetes with Helm charts for horizontal scaling. | Host the instance in your data center or in a cloud account you control. Choose the deployment method your operations team can run, and confirm which packaged Linux distributions your standard images match: Ubuntu 22.04, Debian 12, RHEL 9 or SUSE Linux Enterprise Server 15. |
| Backups and database recovery | OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. | Back up the PostgreSQL 16 database and the file storage together so they can be restored to a consistent point. Confirm the supported backup procedure and restore testing steps with the vendor before go-live. |
Modules, identity and integrations that matter on construction projects
Most of a construction setup rests on a few OpenProject settings: issue tracking, scheduling, file links, and the identity and branding choices that decide who sees what. Several of these sit in the Enterprise plan rather than the Community edition, so confirm module availability in the current edition before you commit to a design.
Work packages for RFIs and issues
Work packages hold requests for information, punch-list items and design issues as trackable records with types, statuses, assignees and custom fields. This is available in the Community edition. Map the statuses and types to how your contract handles an RFI, including who answers and which status comes next. Agree on the custom fields you will report from before records exist, because changing them later adds migration work.
Schedule and project controls
Gantt charts show the construction schedule as dated work packages with dependencies, and dashboards summarize progress for project controls meetings. Both are included in the Community edition. A Gantt view is only as reliable as the dates and relations entered behind it, so confirm that the dependency types cover your scheduling practice. Test the dashboard widgets on a pilot project before stakeholders rely on them.
Nextcloud linking for drawing folders
The Nextcloud integration links files and folders to work packages and can create project folders automatically, so drawings and specifications sit beside the issues that reference them. This linking is available in the Community edition. Decide early which Nextcloud folder structure maps to each project and who may create links, since permissions in Nextcloud and OpenProject are checked separately. Single sign-on for this integration is an Enterprise add-on.
LDAP group synchronization for internal teams
LDAP group synchronization maps directory groups to OpenProject groups, so project roles follow the people who already hold them in your directory without manual invitations. This is an Enterprise feature. Before you enable it, confirm which directory groups represent project teams, how departing staff are deprovisioned, and whether subcontractors exist in that directory at all. Mapping errors grant access quietly, so review group membership after the first sync.
SSO for subcontractors and designers
Single sign-on through SAML, OIDC, CAS, Kerberos or Okta lets external subcontractors and designers sign in with their own organization's identity provider, so access ends when their employer removes them. SSO is listed among the Enterprise features. Confirm which identity provider each partner uses, whether guest accounts still need local passwords, and how multi-factor authentication applies to external users. Test the sign-in path for each partner before access is granted to live drawings.
Custom branding for client-facing portals
Custom branding changes the logo, colors and product name shown to users, which matters when a client or owner reviews progress in an OpenProject instance. It is listed among the Enterprise features. Confirm which branding elements the current edition allows, and have legal review any product naming or footer text before it goes live. Check that branded pages and notification emails still identify the sending system clearly to recipients.
Which BIM parts need the Enterprise add-on
Start by listing the BIM-related functions your project needs, then check each one against the edition that includes it. The free Community edition covers work packages, Gantt charts, agile boards, time tracking and dashboards, and it includes the Nextcloud integration that links files and folders to work packages. A team that only needs to plan model-related tasks, track hours and attach drawings to work packages can run those functions without the add-on. The Enterprise features in the supplied list work differently. Single sign-on, LDAP group synchronization, custom branding and OIDC-based Nextcloud SSO govern how people sign in and how access is administered, so the decision depends on your identity setup as much as on the BIM workflow.
The identity features deserve their own check because they affect every user, not only the BIM team. Single sign-on and LDAP group synchronization decide whether access follows your directory, so removing a subcontractor from a directory group can also remove their OpenProject access. Without them, administrators maintain accounts and group memberships by hand in OpenProject and in Nextcloud. Note the split for Nextcloud: linking files is in Community, but signing into Nextcloud through an OpenID Connect provider is Enterprise. A site that already uses shared Nextcloud folders can keep linking them and still need the add-on if it wants one sign-in across both tools.
OpenProject's pricing page licenses Enterprise on-premises per named user per month. It lists 5.95 euros per user for Basic, 10.95 euros for Professional with a 25-user minimum, and 15.95 euros for Premium with a 100-user minimum, with Corporate available on request for 250 or more users. Before comparing these figures, confirm which tier includes each feature you selected, since the vendor's feature matrix is the reference for that mapping. Count named users as the vendor defines them, including external consultants and contractors who will log in. Minimums can make a small team pay for seats it does not use, so ask whether the minimum applies to the whole contract or to each tier you buy.
Three BIM functions need separate verification: IFC model viewing, BCF issue exchange with other BIM tools, and the Revit add-in. Do not assume any of them comes with Community or with a given Enterprise tier. Check each one against the current release notes and the pricing page on the day you decide, because the release line moves quickly. The most recent releases this page relies on are 17.9.0 (September 30, 2026) and 17.9.2 (October 15, 2026), so a feature described as planned in an earlier release may have changed. Record the release version and check date next to each finding so your procurement file shows what was verified and when.
Put these questions to OpenProject or your implementation partner in writing. Which tier includes single sign-on over OIDC, LDAP group synchronization and custom branding, and does OIDC for Nextcloud sit in the same tier? Are IFC viewing, BCF exchange and the Revit add-in part of Community, part of an Enterprise tier, or delivered separately, and in which release? How are named users counted for external reviewers, and does a read-only stakeholder use a seat? Does the per-user minimum apply to the whole contract? What changes when you move between tiers, and does the switch need a planned maintenance window? Ask whether the quote shows taxes and support as separate lines.
How a construction BIM rollout moves from pilot to site teams
The sequence moves from a written scope and integration inventory to a pilot on one live project, then configuration, external party access and a wider rollout. Each phase depends on the agreed written scope, and each closes with a check that the project owner signs off.
Agree scope and inventory integrations
DeployOpen and your project leads list the live and planned construction projects, the BIM and CAD tools in use, the file storage and identity sources to connect, and the models and BCF exchanges each team needs. We confirm which features each need under the OpenProject Community or Enterprise editions, using the current pricing page, and record the sizing inputs such as expected user counts. The output is a written scope and integration inventory that the client approves before any installation starts.
Install the pilot environment in your infrastructure
DeployOpen installs OpenProject in your cloud account, data center or air-gapped network, using the Docker-based method or a supported packaged install on a supported Linux distribution. The database runs on PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and compute is sized against the user count recorded in the inventory. The output is a running pilot instance with backups configured and a checklist showing that the database extensions, storage paths and network access work as planned.
Run the pilot on one live project
The pilot covers one live project with a small group of named users drawn from the design, coordination and site roles who will use it. The group opens IFC models in the browser, runs BCF issue exchanges with the BIM tools in the inventory, and tests the Revit add-in if it is in scope. DeployOpen logs every failed import, mismatched issue and usability problem against the scope. The output is a pilot log with each issue classified as fixed, accepted or deferred, and a go or no-go decision recorded by the project owner.
Configure work packages and folder structures
Using the pilot results, DeployOpen configures work package types, statuses, custom fields and project folder structures that match how your teams name and store drawings, models and issues. Where you use Nextcloud for file storage, the folder linking and automatic project folder management are set up at this stage, and the team confirms the link behavior. Configuration is kept in a version-controlled record so later changes can be traced. The output is an approved configuration document and a test project that the pilot group has checked end to end.
Set up identity and access for external parties
DeployOpen defines roles per project and sets up access for designers, consultants, subcontractors and other external parties who will not sit in your directory. Single sign-on through SAML, OIDC or other supported protocols and LDAP group synchronization are Enterprise features, so the client confirms which of them the chosen edition includes before this step begins. Each role is tested with a sample account to confirm that external users see only their assigned projects. The output is a signed access matrix and test results showing that each role works as the matrix describes.
Roll out to site teams with training and support
DeployOpen expands access in agreed waves to the remaining project teams and site users, and delivers role-based training with materials that match the configuration in your environment. A support route is agreed in writing, covering who receives user questions, how issues escalate, and what the client team handles directly. Backup restores and upgrade procedures are handed over as a runbook so your staff can operate the system. The output is a handover record, the training attendance list and the signed acceptance of the rollout.
Moving existing project data from Jira or other tools into OpenProject
Before you commit to a cutover date, decide which Jira data the OpenProject Jira Migrator can carry and which items you must rebuild by hand. The migrator reads only Jira Data Center 10.x and 11.x. Jira Cloud is outside its scope, so the first check is your Jira deployment type and version. If coordination runs on Jira Cloud, you need a different extraction path, and that choice affects the schedule more than any other decision in this section.
The migrator is in beta, and its documentation advises using it only in test setups. For a construction project with live requests for information, submittals, and defect lists, treat the first runs as rehearsals. Migrate into a non-production OpenProject instance, compare record counts and field values for a sample of projects, and have the project controls lead sign off on the results. Confirm the current status of the migrator in the migration documentation or with OpenProject before you fix a date, because beta status can change between releases.
The migrator imports projects, issues, versions, custom fields, users, groups, statuses, and types. Check the mappings closely. Jira versions may need to become delivery phases or milestones in your plan, and custom fields for discipline, package, or contract references must exist in OpenProject before the import runs. Status and type names from Jira will rarely match your BIM workflow vocabulary, so agree the mapping with the people who run design coordination. Users and groups come across, but access to work packages depends on roles and permissions that the migrator does not yet move.
Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are planned for later. On a construction project, relations often carry predecessor and successor logic or links between dependent packages, so losing them changes schedule behavior. Plan a manual rebuild from a Jira export for these items, or run both tools in parallel for a defined period. Name an owner for each data type who decides which system is authoritative. The one-time rebuild effort depends on how many relations and sprints you hold, so ask any implementation partner to price this item separately in the written scope.
Records, access and retention decisions construction teams must define
These choices sit with the owner or contractor and need to be settled before the first design package or model is uploaded. Each card names a decision, the part of OpenProject BIM for construction it affects, and the check to run before go-live. Obligations come from your contracts and advice from legal counsel, so the configuration should follow those decisions.
Retention periods for contract and design records
Decide how long contract correspondence, design submittals and model revisions must be kept in OpenProject BIM for construction and in any linked file storage. Retention obligations come from your contracts and advice from legal counsel, so record the period for each class of record and the person who approves deletion. Also decide whether closed projects are archived or removed. Check that the same rules apply to exports and backups.
Access logs and audit trails
Confirm which events the deployment records, such as permission changes, uploads, downloads and edits to work packages, and how long those logs are kept. Check who can read them and whether they can be forwarded to a central log platform you operate. Settle these questions before the project starts, because gaps in audit history are difficult to reconstruct later. Ask counsel which entries your contracts require you to produce on request.
Visibility of project folders
Define which roles can see which project folders, work packages and model files. The Nextcloud integration can create project folders automatically and link them to work packages, so folder permissions and OpenProject roles must agree. Test with users from each subcontractor and confirm that a removed member loses access to files as well as to tasks. Confirm which parts of this setup need the Enterprise plan.
Identity lifecycle with SSO and LDAP
Decide which directory is the source of truth for user accounts and how quickly access ends when someone leaves a project or company. OpenProject lists single sign-on and LDAP group synchronization among its Enterprise features, so group membership in your directory can drive project roles. Test joiner, mover and leaver scenarios with real directory changes in a staging environment. Confirm the exact Enterprise plan each feature requires before you commit to it.
Backup and restore expectations
Agree recovery targets with the project owner before go-live, including how much recent work can be lost, how quickly a restore must finish and whether the database and file storage are restored to the same point. OpenProject requires PostgreSQL 16 or later, so database backups and file storage backups must be planned together. Ask your provider for evidence of a completed restore in your environment, along with the backup job logs.
Data residency for model files
Choose where IFC and other model files are stored, which copies exist and who can download them. A self-hosted deployment keeps the application in infrastructure you choose, but backups, linked file storage, exports and browser downloads can create additional copies. Map each location against your contracts and any residency terms set by owners or regulators, and confirm the mapping with counsel before the model library is populated.
Sizing OpenProject for site, head office and partner users
Start with the sizing guide that OpenProject publishes, which maps user counts to hardware: 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. Count every account that will sign in to the same instance, including head office planners, site engineers and staff at partner firms. Partner users are the figure most often underestimated, because contractors and designers often need access to models and issues for their own scope. Decide early whether partners get named accounts or access through a separate gateway, since the count changes which tier applies. Treat the tier as a shortlist entry, not a final hardware order.
Registered users tell you less than concurrent sessions. A site team may open an IFC model on tablets during a walk-through while head office reviews the same issues from desktops, so the peak matters more than the headcount. File attachments add load in two ways. Uploads consume memory and disk I/O while they transfer, and large IFC or PDF files attached to work packages grow database and file storage over time. Integrations add background work, including Nextcloud file links, directory synchronization and any API clients that poll the instance. The sizing guide does not size these factors separately, so confirm with OpenProject how each one should shift the tier and base your estimate on your own usage pattern.
Docker is the recommended way to install OpenProject, and it suits a first environment where one team operates a small number of hosts. Packaged installs use .deb or .rpm files on supported 64-bit Linux distributions. The current system requirements list Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Kubernetes with Helm charts is the option for horizontal scaling, so you can add application instances as site access grows. That model brings cluster operations, ingress, storage classes and cluster upgrades into your team's scope. Choose the deployment model by asking who will run it after go-live, and confirm the supported versions against the system requirements page when you order infrastructure.
OpenProject supports PostgreSQL 16 or later from release 16.0.0 onward, and the database must have the pg_trgm, btree_gist and unaccent extensions available. Check this before you select a managed database service, since some providers restrict which extensions can be enabled. Size the database alongside the application tier, because attachment metadata, work package history and BIM issue data all grow with use. Agree on backup and restore testing for the database, and confirm which team owns PostgreSQL major version upgrades, since moving to a newer version also affects the application upgrade plan.
What construction firms ask before hiring a partner for OpenProject BIM
What does an OpenProject BIM implementation cost and what drives it?
The software itself has no license fee in the Community edition, which is free under the GPL-3.0 license. Your cost comes from three places: the implementation service (planning, configuration, BIM and integration work, data migration, testing and training), the infrastructure where OpenProject runs in your cloud or data center, and any Enterprise subscription plus support. Implementation and migration are usually one-time costs, while Enterprise subscriptions, hosting, patching and support retainers recur. User count, the number of integrations, migration scope and your support model move the price most. DeployOpen plans most work as fixed scope and does not publish a price list, so a quote follows the written scope. Ask each bidder to itemize these components so you can compare them.
How long does an OpenProject construction rollout usually take?
Duration depends on the scope you agree in writing, so the honest answer is that it varies with the work. The main drivers are how many BIM workflows you configure, how many external tools you connect, how much project history you migrate, and how many rounds of testing and user training your teams need. A rollout limited to one pilot project with a few users moves faster than a company-wide deployment with several integrations. Ask any partner for a phased schedule with milestones for infrastructure readiness, configuration, integration testing, pilot use and go-live, and confirm which dependencies sit on your side, such as access approvals and sample data delivery.
What must our team supply before an OpenProject BIM build starts?
Plan to supply four categories of input before build work begins. First, your BIM standards, including naming conventions, model and file structure, and the rules for issue status and ownership. Second, user lists with roles and project memberships, plus any group structure from your directory. Third, named contacts for each integration, such as the people who administer your BIM authoring tools, file storage and identity provider. Fourth, representative sample models in the IFC formats your teams use, and the BCF exchange examples you expect to pass between tools. Confirm the exact file versions and authoring tool versions with your teams, because those choices affect testing.
Can our internal IT staff run OpenProject BIM without a partner?
Internal staff can run it alone if they have the skills and time to own the platform. The operating work includes installing and upgrading OpenProject, keeping PostgreSQL current with the required extensions, managing backups and restore tests, configuring single sign-on, and watching capacity as users grow. OpenProject supports Docker-based installation, which is the recommended route, as well as packaged installs and Kubernetes with Helm charts. Teams without that experience often choose a partner for the initial build and a support retainer afterward. Decide before the build which operating tasks stay in-house, which go to a retainer, and who signs off on upgrades.
Which OpenProject Enterprise tier and per-user price apply to us?
OpenProject's pricing page lists Enterprise on-premises per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Choose the tier by your user count and by the Enterprise features you need, such as single sign-on through SAML or OpenID Connect, LDAP group synchronization and custom branding. Confirm on the pricing page which tier includes each feature you need, and ask your vendor about taxes and contract terms. These are list prices, and your quote will reflect the scope agreed with DeployOpen.
Which BIM features need the Enterprise plan instead of Community?
The supplied sources do not give a complete feature split for IFC viewing, BCF issue exchange or the Revit add-in, so verify this before you buy. Start with the OpenProject pricing page and the release notes for the version you plan to install, then test each BIM workflow on a non-production instance. Confirm with OpenProject which modules and integrations are included in the Community edition and which require a paid plan. Record the answer for each workflow in your scope document, since a feature that needs Enterprise changes both your license count and your support obligations.
How does user count and integration load change the OpenProject server size?
OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB RAM for about 500 users, and 16 cores and 16 GB RAM for about 1,500 users. These figures are starting points for the core application, so add capacity for heavy file handling, large IFC models, reporting and integrations that run frequently. Plan PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and size storage for model files and backups. Ask your partner to confirm the sizing with a load test that uses your real model sizes and concurrent users.
Can we move our Jira project history into OpenProject?
The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not from Jira Cloud. The migrator is in beta, and its documentation advises using it only in test setups. It can import projects, issues, versions, custom fields, users, groups, statuses and types. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are planned for later. For construction teams, this means project planning history can move, but BIM models and their file links need a separate migration plan. Test the migration in a non-production environment and document which records you accept as manual rework.
How DeployOpen works on this
DeployOpen scopes OpenProject BIM for construction as a written, fixed-scope engagement inside your own infrastructure, whether cloud accounts, data centers or air-gapped networks. We plan the IFC, BCF and Revit add-in parts with your project teams, and confirm which features need the Enterprise add-on before any build starts. The steps below show what is scoped, built, handed over and supported.
How we scope
- The written scope names which BIM workflows run in OpenProject, such as IFC model viewing and BCF issue exchange.
- Scope maps each feature to the Community or Enterprise plan, so licensing is settled before procurement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Hosting is set up in your environment using Docker, packaged Linux installs or Kubernetes, as agreed in the scope.
- PostgreSQL 16 or later is provisioned with the pg_trgm, btree_gist and unaccent extensions enabled.
- BIM features are configured and tested against sample IFC models and BCF exchanges agreed with your tool owners.
How we hand over
- Handover covers the documentation listed in the written scope, including the admin runbook for your operators.
- Your team receives walkthroughs of model upload, issue review and BCF import and export for site and design roles.
- Upgrade and rollback steps are written down for the release channel your organization chooses.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover patching for new OpenProject releases, such as 17.9.2, after your own testing.
- Ask the quote to state response expectations, Enterprise license needs and how BIM feature updates are handled.
