Microsoft Project vs OpenProject: which fits your project portfolio
Choose OpenProject on your own servers if your Project Online plans are approaching or past their September 30, 2026 retirement, or if you want to stop depending on a Microsoft stack that your team would have to host and patch itself. Stay with Microsoft's Project Server Subscription Edition if your portfolio relies on Project Web App workflows, schedules built in the Project desktop client, and a SharePoint and SQL Server farm your administrators already run well. Organizations still on Project Server 2019, whose extended support ended on July 14, 2026, need to decide quickly, because an unsupported farm carries risk that grows during any migration window.
The decision turns on five factors. First, Gantt and baseline depth: list how many schedules use baselines, critical path analysis and resource leveling, since these are often the features that matter most after a move. Second, desktop dependence: if planners work heavily in the Project desktop client, a browser-based Gantt will change daily habits. Third, identity integration: single sign-on and LDAP group synchronization sit in OpenProject's paid Enterprise plans, so your directory model affects licensing as well as configuration. Fourth, who hosts and patches the system, which determines whether your own staff or a partner carries upgrades. Fifth, your existing Microsoft investment, because a Microsoft 365 and directory setup you already pay for can make staying the simpler path even when OpenProject fits the features.
Before you choose, run a short test. Export one representative project from Project Server or Project Online, count its tasks with dependencies, baselines and custom fields, and load a copy into a non-production OpenProject instance. The Community edition includes Gantt charts and time tracking, but you should confirm with OpenProject which of your required controls map to Enterprise plans before requesting a quote. Ask your infrastructure team to size the hosting against your expected user count, using the OpenProject system requirements as the starting reference.
Which option fits which scenario
This table matches common Microsoft Project working needs to the option that usually fits better, with the reason and any Enterprise requirement. Read each row against your own workload, then check the Enterprise column before assuming a feature is included in the free Community edition. The main takeaway is that OpenProject fits most self-hosted and per-user needs, while heavy desktop scheduling and Microsoft 365 integration keep Microsoft Project in the picture.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Heavy desktop scheduling with baselines | Stay with Microsoft Project desktop client | Desktop scheduling, detailed baselines and leveling are central to the client. Confirm which baseline and leveling behaviors you need before planning a move. |
| Microsoft 365 and SharePoint estate | Stay with Microsoft or evaluate both | Teams already depend on SharePoint and Microsoft 365 sign-in. Check which integrations your users rely on, since OpenProject connects through its own integrations such as Nextcloud. |
| Project data must stay on servers you control | OpenProject on your own infrastructure | Community and Enterprise on-premises run in your environment with Docker, packages or Kubernetes. Confirm your hosting and backup obligations with your assessor. |
| Small team with per-user budgets | OpenProject Community edition or Enterprise Basic | Community is free and includes Gantt charts, work packages and time tracking. Enterprise on-premises is priced per named user per month, so the cost scales with headcount. |
| Single sign-on or directory sync required | OpenProject Enterprise plan | SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are listed among Enterprise features. Community alone does not meet this need. |
| Portfolio and resource planning | OpenProject Enterprise plan, confirm fit | Portfolio and resource management sit in paid Enterprise plans. Test the views against your portfolio structure before committing to a plan level. |
| Migrating a Jira Data Center estate with OpenProject | OpenProject with caution | The Jira Migrator is in beta, supports only Jira Data Center 10.x and 11.x, and is listed under Enterprise plans from Basic upward. Use it in test setups first. |
How scheduling, baselines and resource planning compare
Microsoft Project has long set the reference for critical path scheduling, with dependency types, lag and lead time, constraints, and automatic recalculation when a task moves. For day-to-day planning, OpenProject arranges work packages in a hierarchy, links them with relations and displays them on Gantt charts, and the Community edition includes these views. Before assuming a plan carries over, list the dependency types and constraints your schedules actually use, because scheduling engines differ most in how they reschedule successors.
- Hierarchy: Parent and child work packages give summary tasks a roll-up structure similar to an outline in Project.
- Relations: Predecessor and successor links drive the schedule view. Confirm which relation types OpenProject offers for your planning style.
- Rescheduling: Move one task in a test project and check how linked successors shift, including any lag you set.
- Constraints: Must-start, must-finish and deadline-style constraints that Project users rely on need explicit verification.
Build a test plan that includes your longest dependency chain and your most constrained milestones, then compare the results with the original Project file before any cutover.
Project baselines store planned start and finish dates, work and cost at a point in time, so variance views and tracking Gantt charts can show how far a schedule has drifted. Many teams rely on several baselines per project across approvals and re-plans. OpenProject's baseline behavior depends on the version you run, and the release notes list changes in each release. Confirm how baselines, snapshots and variance reporting work in your target version before you plan a migration around them.
- Snapshot scope: Check whether a baseline is stored per project and which fields it captures, such as dates, effort and cost.
- Multiple baselines: Confirm whether you can keep more than one planned version and compare them.
- Variance reporting: Test whether schedule and effort variance appear in reports you use for steering meetings.
- Change history: Verify what OpenProject records about work package changes over time, since auditors and steering committees often ask for that trail.
Export the baseline fields from your current Project files, then recreate one baselined project in OpenProject and confirm which values are preserved and which need to be documented as a manual record.
Project maps resources to tasks through work and units, flags overallocation and offers automatic leveling to resolve conflicts. Resource management is a core part of portfolio planning in many organizations, so the tier you license matters here. OpenProject lists portfolio and resource management in its paid Enterprise plans, and the pricing page shows that Enterprise on-premises plans are priced per named user per month with tier minimums. Community users can still plan work and assign people to work packages without that resource layer.
- Capacity planning: Compare how Project's resource pool and OpenProject's resource views would handle your shared specialists and cross-project assignments.
- Leveling: Confirm whether OpenProject offers automatic leveling in your tier, and if not, decide how planners will resolve conflicts manually.
- Overallocation: Test how conflicts appear to planners before and after changes to a schedule.
- Cost drivers: Named-user licensing grows with the number of people planned, so count the planners and resource-managed staff in your quote request.
Ask the vendor for a written list of resource features in the tier you intend to buy, then run one of your busiest resource pools through a pilot to verify behavior.
Project Server and Project Web App support portfolio selection, project roll-ups and timesheets that feed status reporting. Many organizations use these mainly to collect hours and progress. OpenProject's Community edition includes time tracking, dashboards and project-level reporting, and the portfolio and resource management features sit in Enterprise plans. The practical question is which of your portfolio and timesheet workflows must be preserved, and which can move to simpler dashboards once the data is in OpenProject.
- Time entries: Hours logged against work packages carry project-level reporting, which covers most day-to-day timesheet use.
- Portfolio roll-ups: Cross-project views and portfolio selection belong to Enterprise plans, so confirm which roll-ups you need before choosing a tier.
- Approvals: Confirm whether timesheet approval steps in your current process can be reproduced in OpenProject, or whether they need a separate workflow.
- Finance exports: Reports that read Project Server data will need new queries or files, so inventory them early.
Run one full timesheet and status cycle with a pilot group before retiring Project Web App, and confirm each finance export with the people who depend on it.
Capabilities side by side
This table compares the capabilities that matter most when moving schedules, resources and timesheets from Microsoft Project to a self-hosted platform. Where a row says to confirm, check the current feature set in your own Microsoft and OpenProject versions before you rely on it. The main takeaway is that several features that Project Server users expect sit in OpenProject's paid Enterprise plans, so plan the edition before you plan the migration.
| Capability | Microsoft Project | OpenProject |
|---|---|---|
| Gantt scheduling and dependencies | Scheduling engine built around the Project desktop client and Project Server or Project Online plans. Confirm which scheduling options your version exposes in the web client. | Gantt charts and work package relations are included in the free Community edition. Confirm that your import keeps every dependency type you use. |
| Baselines | Baselines are a core Project feature used for variance reporting. Confirm how many baselines your version stores and where they are kept. | Not covered in the supplied OpenProject materials. Confirm baseline support in the current release before you plan to carry baselines over. |
| Resource and portfolio views | Resource management and portfolio views are part of the Project Server and Project Online offering. Confirm the views your licensed plan includes. | Portfolio and resource management sit in paid Enterprise plans. The Community edition does not include them. |
| Timesheets | Timesheets are entered through Project Web App in Project Server. Confirm approval workflows and how finance exports read this data. | Time tracking is included in the Community edition against work packages. Confirm approval options and cost reporting for your edition. |
| Desktop client | The Project desktop client is the authoring tool for detailed plans and offline schedule editing. Confirm the Microsoft licence that includes it. | OpenProject is a web application. Plan for planners who need the desktop workflow to use a browser or an Excel-based round trip instead. Confirm the current options. |
| SSO and LDAP sync | Sign-in and directory sync depend on your Microsoft Entra ID or on-premises Active Directory setup. Confirm the integration you run today. | SSO with SAML, OIDC, CAS, Kerberos and Okta, plus LDAP group synchronization, are listed as Enterprise features. |
| SCIM provisioning | Provisioning runs through Microsoft Entra ID or Active Directory. Confirm which connectors you use for project roles and groups. | Listed among paid Enterprise plan features. Confirm which Enterprise tier includes it before you rely on it for automated joiners and leavers. |
| Custom branding | Branding options depend on your SharePoint and Project Web App configuration. Confirm what your edition allows. | Custom branding is listed among Enterprise features. Confirm the scope of branding in your chosen plan. |
| Migration import paths | Project files and Project Server data export through Project and Excel formats. Confirm the export route that keeps your task hierarchy and links intact. | Excel-based import of work packages with hierarchy and relations is the documented route for Project data. Confirm the current method and its limits in OpenProject's documentation. |
What stays with the Project desktop client
The Project desktop client is the part of the estate most likely to stay, at least for a subset of users. Planners who build large schedules in Microsoft Project often rely on features tied to the desktop application: the Gantt view with its detailed task linking, the Timeline and task inspector panes, offline editing of .mpp files, and the keyboard-driven habits that come with years of use. OpenProject covers the core of this work through work packages, relations, a Gantt chart and a browser interface, but the editing model is different. A team that expects to drag, link and reschedule hundreds of interdependent tasks in one window should expect a retraining period rather than a like-for-like experience. This matters most where a schedule is maintained by a small group of planners who understand every constraint, and where the schedule is the contractual baseline for a capital program, a construction project or a regulated release.
Before deciding, run a pilot with a copy of your most complex real schedule. Export it, rebuild a representative slice of it in OpenProject, and time the operations planners perform most often: inserting a task in the middle of a chain, moving a milestone that drives a dozen successors, and reviewing the critical path after a slip. Check how the Gantt view behaves with your deepest dependency chains and whether planners can work without a steady connection if field teams need offline access. Ask planners to list every desktop-only view or report they open each week, then confirm with the OpenProject documentation and your own test instance which of those have an equivalent. Keep the desktop client licensed for the planners who need it during any transition, and budget retraining hours as a one-time cost. Ask your Microsoft partner and OpenProject sales contact to confirm current licensing terms for each option before you commit.
Where project data lives and who controls it
Microsoft Project data sits in Microsoft-hosted or Microsoft-operated farm infrastructure, while OpenProject runs wherever you deploy it. The cards below cover where schedules, resources and timesheets are stored, how you install and scale OpenProject, how identity connects, and what compliance readiness work involves.
Where the data is stored
Project Online and Microsoft 365 hosted Project data in Microsoft's cloud, so the storage region and operator are set by the Microsoft agreement. Self-hosted OpenProject stores work packages, schedules, time entries and attachments in a PostgreSQL database and file storage on servers or cloud accounts you choose. Check where your Project data, SharePoint sites and exports currently reside, and where backups are kept, before scoping the move.
Docker as the recommended install
OpenProject's recommended installation method is Docker. Packaged installs are available as .deb and .rpm for 64-bit Linux, supporting Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Confirm your operating system baseline with your platform team, because on-premises Project Server farms often run Windows and SQL Server, which OpenProject does not use.
Kubernetes and Helm for scale
For horizontal scaling, OpenProject provides Kubernetes deployment with Helm charts. This matters when user counts grow, because the sizing guide scales from 4 cores and 4 GB RAM for up to 200 users to 16 cores and 16 GB for about 1,500 users. Ask your platform team whether your cluster, storage classes and backup tooling meet these requirements, and who operates the database.
SSO and LDAP in Enterprise plans
Project Server relies on your Active Directory and Microsoft identity services for sign-in. In OpenProject, single sign-on with SAML, OIDC, CAS, Kerberos or Okta and LDAP group synchronization are Enterprise features, not part of the free Community edition. Map your current group-based permissions to OpenProject roles before you pay for a plan, and confirm which identity provider you will federate with.
SCIM and provisioning requirements
SCIM provisioning and portfolio and resource management also sit in paid Enterprise plans, so user lifecycle changes such as joiners and leavers will not flow automatically on Community. Document which accounts currently receive Project licenses through Microsoft 365 administration, and decide whether provisioning should be automated or handled manually during transition. Ask OpenProject to confirm current plan contents in writing.
Compliance readiness, not certification
Your auditors will ask how Project data is protected, who can access it, how it is backed up and how changes are logged. DeployOpen can plan, configure and document the OpenProject environment and collect the supporting evidence for those controls. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
Microsoft licensing against OpenProject editions
The first decision is which OpenProject edition you need, and the answer depends mostly on identity and portfolio requirements rather than on the core scheduling features. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. The Enterprise on-premises plans are priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros, each with a 25-user minimum, and Premium at 15.95 euros with a 100-user minimum. The Corporate tier is quoted on request for 250 or more users. Features such as single sign-on, LDAP group synchronization, custom branding and the Jira Migrator sit in the paid plans, so check the current feature matrix on the OpenProject pricing page before you assume Community covers your identity needs.
OpenProject is licensed under GPL-3.0. For internal use, this means your organization can install, run and modify the software on its own servers without paying a license fee for the code itself. The obligations apply when you distribute modified versions to others. Internal use does not trigger source disclosure, so the license is rarely the constraint for a regulated enterprise. What you do pay for is the subscription relationship with OpenProject GmbH for Enterprise features and support, plus your own operations staff. Ask legal to confirm how your use case, including any integrations or customizations you plan to distribute to subsidiaries or partners, maps to the GPL terms.
Microsoft licensing is a separate question, and this page does not quote Microsoft prices. Confirm with Microsoft or your reseller which Project and Project Server entitlements, Project desktop client rights, SharePoint and SQL Server licenses and any Subscription Edition terms apply to your users today, and whether any of them can be ended or reduced at renewal. Ask for the total recurring figure per user and per server, not only the headline subscription. Then compare that recurring total with the OpenProject Enterprise per-user price for the same headcount, using the Community edition as the baseline if identity and portfolio features are not required.
What each option costs to run
This table sets the cost components of Microsoft Project and Project Server against those of self-hosted OpenProject, marking each as one-time or recurring. Use it to see which lines your own quote and infrastructure will have to fill in, since most Microsoft figures depend on your agreement and farm design. The main takeaway is that OpenProject's Community edition removes per-user licensing but not the operations work.
| Cost component | Microsoft Project and Project Server | Self-hosted OpenProject |
|---|---|---|
| Licensing | Recurring Microsoft subscriptions per user or per plan, set by your Microsoft agreement. Confirm the current SKUs and terms with your Microsoft account team. | Community edition is free. Enterprise on-premises plans are recurring per named user per month, listed on the OpenProject pricing page, with a minimum user count per tier. |
| Server and farm infrastructure | Recurring. Project Server needs SharePoint and SQL Server farm components, sized to your Microsoft guidance and user base. | Recurring hosting. Sizing guide suggests 4 cores and 4 GB RAM up to 200 users, 8 cores and 8 GB for about 500, and 16 cores and 16 GB for about 1,500. |
| SharePoint and SQL Server licensing | Recurring if licensed separately or bundled into your agreement. Confirm which components your current licenses cover. | Not applicable. OpenProject runs on PostgreSQL 16 or later, which carries no license fee in the Community edition, plus the pg_trgm, btree_gist and unaccent extensions. |
| Administration effort | Recurring. Farm patching, SharePoint and SQL Server maintenance and Project Server configuration are typically handled by specialist staff. | Recurring. Docker or packaged installs, PostgreSQL upkeep and OpenProject upgrades. Effort rises with the number of hosts and custom integrations. |
| Backups and recovery | Recurring. Requires backup tooling and tested restores for both the farm databases and the content databases. | Recurring. Requires backups of the PostgreSQL database and attachment storage. Confirm the restore procedure in your own environment before go-live. |
| Migration | One-time. Export schedules, resources and timesheet data from Project Server, then validate results, since baselines and some settings may not carry over. | One-time. Excel-based import of work packages and resources, plus a review of what does not carry across. The Jira Migrator is not relevant here and is in beta for Jira only. |
| Support | Recurring through your Microsoft support plan or partner contract. Scope and response terms come from that agreement. | Community support is free. Enterprise plans include vendor support. Ask OpenProject what support tier each plan includes. DeployOpen support is quoted from written scope. |
What a move from Microsoft Project involves
The sequence turns scattered schedules, resource pools and reporting habits into a tested OpenProject setup that a project team can use in production. Each step closes with a check, so the move is confirmed before the old Project files or farm are retired.
Inventory schedules, portfolios and reporting dependencies
Project managers and the PMO list every project plan, portfolio view, shared resource pool and report that depends on Microsoft Project or Project Server. Include timesheet approvals, status reports and any finance exports that read Project Server data, because these often break silently. The step is done when each item is marked as migrate, rebuild, retire or keep in Microsoft, with an owner named for each decision.
Export plans from Project or Project Server
Plan owners export task lists from the Project desktop client or from Project Server into Excel, keeping task names, outline levels, start and finish dates, predecessors, durations and assigned resources. Keep the original .mpp files and a copy of the export in a read-only archive, since baselines and history may not transfer in full. The step is done when each exported workbook has been opened, row counts match the source plan, and the archive copy has been verified.
Map resources, custom fields and hierarchy
The implementation lead and the PMO build a mapping sheet that links Project resources to OpenProject users, groups and roles, and maps enterprise custom fields to OpenProject work package attributes. They also decide how summary tasks and phases map to parent work packages and how predecessor types are represented. The step is done when the mapping has been reviewed by one representative from each affected team and every field has either a target or a documented reason to drop it.
Pilot the import in a test instance
The DeployOpen team, or the client's platform engineers, install OpenProject in a test environment and run the Excel synchronization against one representative project with dependencies and several resources. They compare the result against the source plan, checking hierarchy, relations, dates and assignments, and log every mismatch. The step is done when the pilot project has been signed off by its project manager, and the list of known gaps has been agreed in writing.
Import and rebuild resources and custom fields
The team runs the import for the full set of in-scope projects in the production instance, then rebuilds the resource pools, roles, custom fields and portfolio groupings that the import does not carry. Portfolio and resource management views depend on the paid Enterprise features, so the team confirms that the chosen edition covers them before going live. The step is done when a reconciliation report shows that work package counts, owners and key dates match the mapping sheet for every project.
Decide what does not carry over
The PMO and project managers record each capability that will not transfer as expected, such as baselines, resource leveling results or other Project-specific calculations, and choose a replacement for each. Options include keeping the Microsoft plan as a frozen reference, capturing a baseline snapshot in a document, or accepting that historical variance data stays in the archive. The step is done when every gap has a named decision and the stakeholders who rely on those figures have acknowledged it.
Run parallel use before cutover
Project teams work in OpenProject while the Microsoft plans stay available as a reference, and the PMO compares status and timesheet data between the two for an agreed period. Any discrepancy is traced to its cause, whether mapping, user habit or a missing rule. The step is done when the PMO records that discrepancies are resolved or accepted, and the team lead has confirmed that the reporting outputs meet the agreed needs.
Cut over and retire the old environment
The organization sets a cutover date, freezes edits in Project and Project Server, runs a final incremental import, and points users, bookmarks and reporting consumers at OpenProject. The old farm or licenses are retired only after the archive has been tested for restore and the owner of the retained data has signed off. The step is done when the cutover checklist is complete, support ownership is assigned, and the Microsoft environment is marked read-only.
Questions buyers ask before switching from Microsoft Project
What does switching from Microsoft Project to OpenProject cost in effort, and who does the work?
The effort is mostly one-time: exporting schedules, rebuilding the work package hierarchy, recreating resources and custom fields, and validating the result, plus the platform build on your own servers. Your internal project controls staff and IT provide the knowledge of the existing plans, and whoever you engage, whether internal staff or an implementation partner, is paid for the hours in the agreed scope. Ask any quote to split the work into migration, platform setup, integration with your identity provider, testing, and training, and to state which items recur, such as hosting, support and upgrades. DeployOpen works from a written, fixed scope, so the quote follows from the plan size, the number of projects, and the integrations you need.
How long does a migration from Project Server to OpenProject take?
Duration depends on what you are moving, not on a fixed template. The main drivers are the number of active schedules, how deep their hierarchies and dependencies run, how many custom fields and resource calendars must be rebuilt, and how many people must sign off on the rebuilt plans. Organizations with a small portfolio and clean exports usually finish faster than those with years of archived baselines and cross-project links. No duration figure is supplied for this comparison, so ask the vendor or implementer for a timeline built from a sample of your own schedules before you commit to a date.
Can our own team migrate from Microsoft Project without outside help?
A small team with spare capacity and an administrator who can run a Linux server can often handle a pilot themselves, especially for a few active projects. The harder parts are the Excel-based rebuild of work package relations, the resource and permission model, single sign-on, and backup and upgrade routines that the platform will need after go-live. Before deciding, check whether your team has someone who can own the server, apply OpenProject upgrades, and test restores. If not, a fixed-scope engagement can cover those pieces while your staff keep control of the content.
Do baselines carry over from Project Server to OpenProject?
Baselines are one of the items to confirm carefully, because they do not move through the standard export and upload path described for this migration. Plan for baselines to be kept as archived exports or recorded values, not as live baseline objects that compare against current dates. Ask the implementer to show, on one of your schedules, exactly which fields and comparisons survive the move and which must be reproduced in a report or spreadsheet. Leveling results and certain scheduling calculations should be treated the same way and verified against your reference plan.
What do our IT and project staff need to provide during the switch?
Expect to supply a few clearly defined inputs:
How does OpenProject licensing change once we need SSO, LDAP sync or portfolio views?
The Community edition is free and covers work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Features such as single sign-on, LDAP group synchronization, SCIM provisioning, and portfolio and resource management sit in Enterprise plans. Enterprise on-premises pricing is per named user per month, with Basic at 5.95 euros and Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), and Corporate on request for 250 or more users. Compare these figures with your current Microsoft licensing by component, and confirm current prices on the OpenProject pricing page before budgeting.
Which parts of the Project desktop client work need a replacement?
The desktop client is used for detailed scheduling, so check which of its functions your planners rely on daily. OpenProject provides a browser-based Gantt view with dependencies and work package hierarchy, but it does not replicate every desktop-only scheduling option, so list the features your planners use and confirm each one with the vendor. Plan to test several real schedules, including critical path and resource-heavy plans, before retiring the desktop client for those projects.
Which official sources to check before deciding
Before you commit to OpenProject, confirm the edition, version and hosting requirements against the vendor's own pages, because those are the details most likely to change between your evaluation and your rollout. Start with the OpenProject pricing page to see which features sit in the free Community edition and which sit in the paid Enterprise on-premises plans, including single sign-on, LDAP group synchronization and the Jira Migrator. Then check the OpenProject system requirements for supported operating systems, the PostgreSQL version and extensions, and the sizing guidance for your user count. Use the OpenProject release notes to confirm the current release line and any changes that affect your plan, and the OpenProject GitHub repository to verify the GPL-3.0 license terms that apply to the code you deploy.
Check these pages directly on the day you request a quote, not only when you first read this comparison. Plans, per-user rates, minimum seat counts and feature placement are commercial terms that the vendor can revise, and Microsoft's licensing for Project Server or Project desktop access is governed by its own terms and your existing agreements. Ask your procurement and legal teams to record the URL, the date you checked and the version you tested against in the decision file. Ask the OpenProject sales team to confirm in writing which Enterprise features your chosen tier includes, and ask your platform team to validate the system requirements in a test environment before sizing production hardware. A written scope from DeployOpen can then reference those confirmed terms.
How DeployOpen helps evaluate, implement and migrate OpenProject
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted OpenProject inside your own cloud accounts, data centers or air-gapped networks. For Microsoft Project and Project Server replacements, we start with a written scope that separates what OpenProject covers from what stays with the Project desktop client or another system.
How we scope
- Inventory which Microsoft Project files, Project Server features and reports your teams actually depend on.
- Map each capability to OpenProject Community or Enterprise features and record the gaps in writing.
- Confirm licensing tiers, user counts and SSO or LDAP needs before any build work begins.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Size and deploy OpenProject on your infrastructure using the Docker-based or packaged install that fits your Linux estate.
- Configure PostgreSQL with the required extensions, along with SSO, LDAP group synchronization and custom fields.
- Rebuild work package hierarchies, relations, resources and custom fields from exported schedules, then test them with your planners.
- Run security testing and hardening checks on the deployment before users receive access.
How we hand over
- Document the architecture, configuration, backup routine, upgrade steps and access model for your operations team.
- Deliver a register of what did not carry over, such as baselines or leveling, with the workaround agreed for each item.
- Prepare control and evidence material for your compliance assessment, while independent auditors issue any formal report.
- Run knowledge transfer sessions so administrators can operate and patch the platform without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
- Track OpenProject release notes and plan upgrades on a schedule you approve.
- Keep backups, restore tests and monitoring under your control, reviewed in each support cycle.
- Confirm support boundaries, response expectations and escalation paths in the written agreement.
