After Project Online: self-hosted alternatives for schedules that must stay on your own servers
If schedules, resource data and exports must stay inside your own infrastructure, the realistic choices are Project Server Subscription Edition or self-hosted OpenProject, and exports from Project Online are the bridge to either. Project Online retired on September 30, 2026, so the first task is to find out what is still accessible in your tenant and what has already been removed. Before you consider the Microsoft option, confirm with Microsoft where Project Server Subscription Edition is hosted, which data it processes, and what the contractual terms say about data handling. If your residency rules require that the farm, its SQL databases and its backups sit in a location you control, confirm that the edition you would buy can be deployed that way, and who in your organization would operate it.
OpenProject is the self-hosted route. Its code is licensed under GPL-3.0, its Community edition is free, and it can run in your cloud account, a data center or an air-gapped network. Docker is the recommended installation method, and the platform officially supports PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. The gap to plan for is identity: SSO, LDAP group synchronization and SCIM provisioning sit in paid Enterprise plans, so if your access model depends on them, the Enterprise on-premises tier becomes part of the cost. Check the current tiers on the OpenProject pricing page and ask for a quote that names the user count and identity integrations you need.
Whichever platform you choose, treat exports as a controlled migration step, not a backup of record. Inventory every project that must survive, then export schedules, task hierarchy, dates, dependencies, assignments and custom fields from Project Online or your desktop files into Excel or CSV while the source is still reachable. Record who approved each export and where the files are stored, since they will hold the same sensitive resource and cost data. Then load one representative project into a test instance and compare it field by field against the source. Expect that baselines, leveling results and some formulas will not carry over, and decide in advance whether those values need to be kept as static reference data.
What keeping project data on your own servers requires after Project Online
Moving schedules, resource plans and timesheets onto your own servers shifts hosting, administration, access control, upgrades and recovery from Microsoft to your team or partner. Each card below names one of those responsibilities and what it means for project data after Project Online.
Where the data is hosted
With self-hosted OpenProject, work packages, Gantt dependencies, time entries and attachments sit in your own data center or cloud account, on a PostgreSQL database you operate. Confirm which region and network zone that database and its file storage occupy, and whether backups are copied off-site. Ask who holds database credentials and whether any vendor can see production data during support.
Who administers the platform
Under Project Online, Microsoft ran the service and your team configured it. Self-hosting makes your team responsible for the host operating system, containers, database patching and capacity planning. Decide whether internal platform engineers, a managed service or an implementation partner owns each task, and write that split into the support agreement before cutover so timesheet approvals do not stall during an incident.
How users authenticate
Project Online users signed in through your Microsoft Entra ID tenant. On self-hosted OpenProject, single sign-on (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are listed under Enterprise plans, so confirm the edition before design. Map Project Server security groups to OpenProject groups and roles, and test that a leaver loses access to schedules and timesheets on the same day their directory account is disabled.
How upgrades are applied
OpenProject publishes regular releases, including 17.9.2 on October 15, 2026, and both the Community and Enterprise editions follow that release cycle. Your team must schedule each upgrade, test it against a copy of production data, and apply database migrations. Agree a maintenance window with finance and project controllers, since a failed upgrade during a reporting period can block timesheet submission.
How backups and exports are kept
Project Online offered no database-level backup that you controlled, so self-hosting adds a duty to back up the OpenProject database and attachment storage together, and to test restores. Keep periodic exports of schedules and timesheet data in a format your finance team can open, because exports preserve values and structure but not every configuration. Document the recovery point and recovery time your business needs before go-live.
What the platform will not carry over
Baselines, resource leveling results, and some Project Server reporting views do not move automatically, so plan them as known gaps. Before retiring the old tenant, export schedules, resource assignments and timesheet history to files and list which views finance and portfolio reports depend on. Confirm with OpenProject which of these you must rebuild, and record a sign-off from each report owner.
Which option meets the constraint, and at what trade-off
This table compares four routes for keeping project data under your control after Project Online: staying on Project Server Subscription Edition, self-hosting OpenProject Community or Enterprise, and using the lighter Redmine. Read each row against your hosting, identity and reporting requirements, and treat the confirmation column as your checklist before any commitment.
| Option | How it meets the hosting and data constraint | What to confirm with the vendor or in your environment | Main trade-off |
|---|---|---|---|
| Project Server Subscription Edition | Stays within the Microsoft product line, so existing Project Server skills, the Project desktop client and SharePoint-based reporting can carry over | Hosting model and data location options, supported farm topology, and current subscription pricing with Microsoft and your licensing partner | Keeps the Microsoft platform and its licensing dependency, with cost components that you must price by component |
| OpenProject Community | Free, GPL-3.0 licensed, and installed on your own servers using Docker, packages or Kubernetes, so project data stays in your infrastructure | Your internal support model, since Community comes with community support only, plus backup, patching and sizing for your user count | No vendor support contract, and features such as SSO, LDAP synchronization and SCIM sit outside Community |
| OpenProject Enterprise on-premises | GPL-3.0 product run on your own servers, with paid support and Enterprise features such as SSO and LDAP group synchronization | Per named user per month pricing, 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, as listed on the OpenProject pricing page | Recurring per-user cost that grows with headcount, and the Jira Migrator is only listed from Basic upward |
| Redmine | GPL v2 web application that you host yourself, with issue tracking, Gantt charts, wikis, time tracking and LDAP authentication. Version 7.0.2 was released on September 30, 2026 | Whether its Gantt, resource and portfolio depth covers your schedules, and which plugins your reporting depends on | Lighter for issue-centred work, so it may need less Gantt and resource depth than a formal project schedule requires |
How to deploy and operate OpenProject under the constraint
This sequence takes an organization from a hosting decision to a tested, upgradable OpenProject instance that runs inside its own infrastructure. Each step closes with a check the team can verify before moving on.
Confirm hosting target and operating system
Decide whether OpenProject runs in your data center, a private cloud account or an air-gapped network, then choose the operating system. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and Docker-based installation is the recommended route. Your infrastructure team confirms which of these images, mirrors and patch sources they can use. The step is done when the target platform and install method are written into the scope document.
Size servers against expected user count
Use OpenProject's sizing guide as the starting point: 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. Sizing should also reflect concurrency, attachment volume and whether you plan horizontal scaling with Kubernetes and Helm charts. The output is a host specification signed off by the infrastructure owner, with headroom for growth agreed in advance.
Prepare PostgreSQL with required extensions
OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm whether your database team will host a dedicated instance, a managed service in your account or a shared cluster, since this affects backup and patching responsibility. Verify the extensions are installed and the database role has the privileges the installer needs. The check is a successful connection test from the application host with all three extensions listed.
Connect identity through the chosen edition
Community edition has no SSO, LDAP synchronization or SCIM provisioning, so decide early whether those are needed. Enterprise plans cover SAML, OIDC, CAS, Kerberos and Okta single sign-on, LDAP group synchronization and custom branding. Your identity team must confirm the identity source, group mapping and who owns deprovisioning. The step is complete when a test user signs in through the agreed path and a removed account loses access.
Run a pilot project with real governance
Load one active project with its work packages, Gantt dependencies, versions and time tracking, then have a small group of project managers use it for a defined period. Record what breaks in roles, custom fields, notifications and reporting. Use the pilot to confirm which Project Online data you will rebuild by hand and which you will import. The output is a findings list with owners and a decision on whether the configuration is ready for wider rollout.
Set up backups and test restores
Define backup scope for the application files, attachments and the PostgreSQL database, and schedule them to run in your own backup platform. Retention periods must come from your legal, compliance and records teams, not from the installer defaults. A backup is not proven until you restore it to a separate host and open a project, attachment and user record. The check is a documented restore run with the time taken and the data verified against the source.
Plan upgrades and document operations
OpenProject publishes frequent releases, so set a patch and minor upgrade routine, test each upgrade in a staging copy and keep a rollback plan that includes the database. Document the runbook covering install, configuration keys, certificate renewal, monitoring and on-call escalation. DeployOpen can plan, implement, harden, back up, upgrade and document these steps under a written, fixed scope, and can offer ongoing support as a retainer. Your own team must still confirm network rules, identity sources and retention needs before go-live.
What can still be recovered from exports, by source
Project desktop files (.mpp) and data pulled from Project Server hold the most structure, but what survives depends on how each file was saved and which fields were populated. Task names and the outline hierarchy usually come through most reliably, because OpenProject organizes work as parent and child work packages. Dates and predecessor links are the next fields to check, and each one should be verified after import.
- Usually carries over: task names, outline levels, start and finish dates and progress values that are populated in the source.
- Often carries over: predecessor relationships and assignees, once resource names match users already created in OpenProject.
- Custom values: text, number and list fields carry over only when they are present in the export and the matching field exists in OpenProject first.
- Does not carry over: baselines, leveling results, resource calendars and cost rate tables, which must be rebuilt or kept as archived attachments.
Open a copy of each file in the desktop client, compare task counts, dates and dependencies against the import, and confirm the result before you delete anything from the source.
Reports and grids exported to Excel or CSV are the most portable form because they carry plain values that any tool can read. The export is only as complete as the view it was run from, so columns that were hidden or left off the report will not appear in the file. Formulas, pivot tables, charts and dashboards stay with the source and do not move as working objects.
- Usually carries over: the values in the columns you selected, such as names, dates, owners, status and any custom columns included in the view.
- Hierarchy is weaker: indentation may be lost unless the export includes an outline level or ID column, so parent links need a manual check after import.
- Formulas as values: calculated columns come across only as their current results, which preserves history but cannot recalculate in OpenProject.
- Does not carry over: report layouts, filters, charts, baselines and any field that was not part of the report.
Before you start, list the columns each report contains, add every field you need to one test report, and compare that export against a sample project to confirm nothing essential is missing.
Teams that also used Asana, monday.com, Smartsheet or similar tools often hold part of their plan there. Each tool offers a different export route: some produce flat files, some produce full backups, and some require API access and a developer to script the extraction. The fields that survive depend on that route, and most exports omit automations and dashboards.
- Asana: project CSV exports include task ID, dates, name, assignee, due date, tags, notes and parent task, which map well to work packages. A full organization export is limited to service accounts on an Enterprise+ plan, so confirm your plan level first.
- monday.com: the GraphQL platform API can read boards, items, column values, users and workspaces, so extraction usually needs a script built by someone who knows the API.
- Smartsheet: backups are a zip of Excel files that include comments and attachments but exclude reports, dashboards, formulas, workflows, cross-sheet references and formatting.
- Cross-tool links: references between items in different tools do not survive, so rebuild them as relations in OpenProject after import.
For each tool, confirm your plan level and export permissions, then run a test export of one project and check its contents against the live source.
Evidence auditors and internal reviewers ask for after a self-hosted move
A self-hosted move shifts security and operational responsibility from the vendor to your team, so reviewers will ask you to show how the system is built, who can reach it and how it is kept alive. The cards below describe the records that answer those questions. DeployOpen can prepare these artifacts for an assessment, but independent auditors and certification bodies issue any report or certification.
Architecture record of hosting
This is a current diagram and written description showing where OpenProject runs, which hosts or containers serve the application, where PostgreSQL lives, how traffic reaches it and which network zones it crosses. Reviewers use it to confirm that project data for Microsoft Project or Project Server replacements stays inside your accounts or data centers. Check that the record names the PostgreSQL version and extensions in use, because OpenProject requires PostgreSQL 16 or later along with pg_trgm, btree_gist and unaccent. Update the record whenever the topology changes.
Access control records from SSO and LDAP
Keep exports of identity provider configuration, LDAP group mappings and the role assignments that OpenProject uses for projects and work packages. Reviewers want evidence that each person who can open a schedule or change a baseline was approved by a named owner and removed when they left. Single sign-on and LDAP group synchronization sit in paid Enterprise plans, so confirm which edition your records describe. Ask for a sample of joiner, mover and leaver tickets tied to group changes.
Backup and restore test results
A backup that has never been restored is not evidence of recoverability. Keep dated records of restore tests into a separate environment, covering the PostgreSQL database and the attachment storage, along with the time each step took and the data checks performed afterward. Include the OpenProject version running at the time of the test. Your team, not the vendor, owns this control, so the record should name who ran the test and who reviewed the results.
Upgrade and patch record
Maintain a log of every OpenProject upgrade, comparing the installed version against the release notes and recording the date of the change, the approver and the rollback plan. OpenProject publishes frequent releases, including 17.7.0, 17.8.0, 17.9.0 and 17.9.2, so reviewers will ask how you decide which releases to apply and how quickly. Record exceptions where a version was left in place and the reason. Confirm the cadence you commit to with your own change board and with DeployOpen's retainer scope if you use one.
Export and migration log
Build a log that records each source export, its date and scope, the import method used and the counts of projects, work packages, users and attachments that arrived. Equally important, list what did not carry over, such as baselines, leveling results, reports and custom formulas. An auditor can then compare the source and target and see that known gaps were accepted by a named owner. For Jira-sourced data, the OpenProject Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, so record that limitation if it applies to you.
What drives the cost of each option, and what to ask for in a quote
The cost of each option splits by who is paid for what. With Project Server Subscription Edition, the recurring lines are Microsoft licensing and the SharePoint and SQL Server farm it depends on, so confirm with Microsoft or your reseller which licenses, client access rights and server components apply to your user base before you compare totals. OpenProject Community carries no license fee, so its recurring costs are servers, the operating system, the PostgreSQL database, staff time for upgrades and whatever support you buy or staff in-house. OpenProject Enterprise on-premises is billed 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, according to the OpenProject pricing page. Installation, migration, hardening and first configuration are one-time work. Licenses, hosting, upgrades and support recur every year.
Four drivers move the totals most. User count sets the Enterprise tier and, on Community, the hardware: OpenProject's sizing guide suggests 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. SSO and LDAP needs usually push you onto Enterprise, because OpenProject lists SSO and LDAP group synchronization among its Enterprise features, so an identity requirement can change the license line more than headcount does. Data volume and the number of projects to move drive migration effort, since every project needs field mapping, rebuilt resources and reconciliation of dates and owners. Also check the PostgreSQL 16 or later requirement and its extensions, because a database on an older version adds work before go-live. Count active projects and named users separately, since the two figures often differ.
A written quote should name the scope: which Project Online or Project Server environments and projects are included, which are excluded, and whether baselines and resource history are expected to carry over. Ask for concrete deliverables such as installed and hardened instances, a migration run with a reconciliation report, test results, runbooks and documentation. Specify the edition and the number of named users per tier, and state whether SSO or LDAP is in scope. Require a timeline with milestones tied to acceptance, and separate one-time fees from recurring support or retainer fees. Confirm the OpenProject license terms directly with the vendor. DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask that the quote follow that document.
Questions buyers ask before moving off Project Online
Is Project Online still available after its retirement?
No, Project Online retired in September 2026, so plan on normal use of the service being unavailable. The practical question is what data you can still reach and for how long. Confirm the exact service end date, any read-only or data retrieval window, and how long exported files remain accessible with Microsoft through your tenant's admin message center and your licensing contact. Your contract or renewal paperwork may set different dates than the general retirement, so check those first. The remaining Microsoft path is Project Server Subscription Edition, which requires its own licensing and an on-premises farm. The alternative is a move to a platform such as self-hosted OpenProject, which the migration steps in this guide assume.
How much does a self-hosted OpenProject cost to run, and what is free?
The Community edition is free to download and run. It includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support only. Recurring costs come from three places. Enterprise on-premises subscriptions are priced per named user per month: Basic at 5.95 euros, 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. Servers and storage scale with user count and attachment volume. Staff or partner time covers upgrades, backups and monitoring. Migration and setup are one-time costs. Ask any partner for a quote built from a written scope, and confirm current prices and tax treatment on the OpenProject pricing page.
How long does a migration take and what does it need from our team?
The facts available to this guide do not give a migration duration, so the answer depends on the number of projects, schedules, custom fields and the amount of history you must keep. Your team needs a business owner to decide which projects, baselines and reports must move, a data owner to clean up resource names and status values, an administrator to host the system, and reviewers to check migrated plans against the source files. Start with a test instance so that reviewers can compare results before any cutover. Ask any implementation partner to state the timeline in the written scope, and confirm with OpenProject which migration paths apply to your source before you commit to a plan.
Can our own staff run OpenProject without outside help?
Often yes, if your team already operates Linux servers, containers and PostgreSQL. OpenProject recommends Docker-based installation, offers packages for 64-bit Linux, and supports Kubernetes with Helm charts for horizontal scaling. Day-to-day work includes applying upgrades, backing up the database and file storage, patching the operating system, monitoring, and restoring from backup. Community support is community-based, so your staff carries the operational load unless you buy Enterprise support or a retainer. Test a restore before you rely on the setup. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted OpenProject inside your own infrastructure, and ongoing support is available as a retainer. Check your team's skills against the written scope.
Which Enterprise features do we need for SSO and LDAP?
Single sign-on and LDAP group synchronization sit in Enterprise plans, not the Community edition. OpenProject lists single sign-on through SAML, OIDC, CAS, Kerberos and Okta, plus LDAP group synchronization and custom branding among its Enterprise features. SCIM provisioning is also listed in paid Enterprise plans. Start by mapping your need. If you only need users to sign in through an identity provider, the protocols your provider supports determine the required feature set. If you need group membership to update automatically, LDAP group synchronization and SCIM matter more. The pricing page does not settle which tier includes each feature in every case, so confirm the mapping with OpenProject before you choose a plan, including whether plain LDAP sign-in is covered by the same tier.
What server size does OpenProject need for our number of users?
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. Treat these as vendor starting points, not guarantees. Actual load depends on how many work packages are active, attachment volume, integrations and whether background workers share the host with the application. Storage for attachments and backups is a separate line that grows with uploads and retention. Use the sizing figures as the baseline for a proof of concept, then measure during testing. Ask any partner to state server assumptions in the quote so you can compare like with like. The system requirements page lists the current figures.
Which database and operating system must we prepare before installing?
OpenProject officially supports PostgreSQL 16 or later, since version 16.0.0, and requires the pg_trgm, btree_gist and unaccent extensions. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x, and SUSE Linux Enterprise Server 15. Docker-based installation is the recommended route. Check these items before choosing hardware, because an unsupported database version or a missing extension can block setup. Confirm that your managed PostgreSQL service allows the three extensions and that your security baseline approves them. Also check the requirements for the exact release you plan to deploy, since the current line includes 17.9.2, published October 15, 2026, and requirements can change between releases.
Can we export our Project Online data, and what will not carry over?
Export paths exist, but the exact tools and the fields each one carries depend on your tenant and Microsoft's current export support, so confirm them with Microsoft before you plan. In general, expect schedules, tasks, durations, dependencies and resource assignments to need checking after import. Treat baselines, custom formulas, views, reports and workflow rules as items to verify or rebuild by hand. Save a full copy of each project to storage your organization controls, keep the source metadata, and record which owner signed off on each migrated plan. Ask any migration partner to list in writing which fields they will carry over, which they will rebuild and which they will drop, before work starts.
How DeployOpen deploys OpenProject under a hosting and data constraint
DeployOpen plans, implements, hardens, backs up and documents self-hosted OpenProject inside your own cloud accounts, data centers or air-gapped networks. For Project Online exits, we start from the hosting and data constraints that drove the decision, then build only what the written scope requires.
How we scope
- We confirm which Project Online data must move, such as schedules, resources and custom fields, and which will be rebuilt by hand.
- We agree on the hosting target, operating system and database in writing before any installation work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows from that scope.
How we build
- We install OpenProject in your environment using Docker or a supported Linux package, then configure PostgreSQL and required extensions.
- We set up single sign-on, LDAP group synchronization and custom branding where your chosen edition and identity provider allow them.
- We test imported schedules, relations, user access and time entries against the exported source before any cutover date is set.
How we hand over
- We document the deployed architecture, configuration, sizing decisions, backup procedures and the list of data that did not carry over.
- We provide runbooks for administrators covering user provisioning, project templates, upgrades and restore testing.
- We prepare control and evidence material for your compliance assessment, while independent auditors remain responsible for any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover is complete.
- We plan OpenProject release upgrades against your change calendar and test them in a staging copy first.
- Ask any provider, including us, to confirm in writing which OpenProject edition, hosting model and support responsibilities are included.
