Project Server 2019 end of support

Project Server 2019 end of support: what the decision has to settle

Project Server 2019 left extended support on July 14, 2026, so the decision is between staying on a supported Microsoft release, Project Server Subscription Edition, and moving schedules, resource plans and timesheets to self-hosted OpenProject on your own servers. Either way, the farm needs containment now, because schedules, resource data and timesheets are still in daily use on a platform that no longer receives security fixes. Start by restricting access to named groups, confirming the farm is not reachable from the internet, and reviewing which network paths the application and SQL Server tiers actually need. Take a full, tested backup of the content and configuration databases, and inventory every SharePoint and SQL Server dependency, including custom solutions, timer jobs and integrations with finance exports.

Replacement is shaped by OpenProject's technical requirements, so check them before comparing features. The 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. Docker is the recommended installation method, packaged installs support Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15, and the database must be PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Confirm that your operating system and database standards meet these requirements. Single sign-on and LDAP group synchronization are Enterprise features, so identity requirements also affect the licensing decision, as described on the OpenProject pricing page.

Several facts must come directly from Microsoft before you commit to either path. Ask for the current support dates for Project Server Subscription Edition, the licensing model for your named users, and whether your farm's SharePoint and SQL Server components are included or billed separately. Confirm whether any of your timesheet or status workflows depend on components that Microsoft will not support on your target version. Then set a decision date with the business owners of schedules and resource plans, and document which containment controls are in place until the move is complete. The outcome should be a written choice, a dated containment plan and a list of confirmed Microsoft terms, not a general intent to migrate later.

What an unsupported Project Server farm still has to meet

Project Server 2019 extended support ended on July 14, 2026, so the farm keeps running without vendor fixes while you decide. The cards below cover what must stay true until cutover, and each one names a check you can run this week.

Restrict who can reach the farm

An out-of-support farm is a fixed target, so the first control is network reach. Confirm that only the users, service accounts and monitoring hosts that need Project Web App can connect, and that administrative access to SharePoint Central Administration and the SQL Server instances comes from a managed jump host. Review the firewall or load balancer rules and the published hostnames against a current list of named users. Remove any external publishing that was added for convenience and was never reviewed.

Protect schedule and timesheet data

Project Server holds schedules, baselines, resource assignments and timesheet entries across the Project Server, SharePoint and SQL Server databases. Before any upgrade or cutover, take a full, restorable backup of every content and service database, and test a restore on separate hardware. Export project plans to a file format you can read without the farm, and record which projects carry baselines, since those values will not move cleanly to another tool.

Keep identity and access under control

Project Server users sign in through Active Directory, and any group-based access rules depend on that directory. OpenProject lists single sign-on and LDAP group synchronization as Enterprise features, so the target platform's identity cost must be quoted before you commit. Confirm which accounts are disabled when people leave, which service accounts hold farm rights, and whether any local accounts remain. Ask your vendor or integrator to price SSO and group sync as separate line items.

Track the patching gap

Without extended support, security fixes for the farm components no longer arrive from the vendor on the old schedule. Record the installed build of each server and SQL Server instance, list which fixes you have applied, and set a review cadence. Ask your Microsoft account team which updates remain available for the version you run and what the subscription path covers. Document any compensating controls, such as segmentation and tighter logging, that reduce the exposure in the meantime.

Document the decision for the board

Auditors and boards will ask why the farm kept running after support ended and what the plan is. Write a short decision record that states the options considered, the chosen path, the owner, the target date and the risk accepted in the interim. Attach the backup test results, the access review and the identity cost quote to it. This record shows that the timing was a deliberate choice rather than a missed deadline.

Assign owners for each control

Each control in this list needs a named person who runs the check and signs off on the result. Split responsibility between the platform team for infrastructure and backups, the directory team for identity, and the project management office for data validation and user communication. Schedule the checks as recurring tasks until cutover, and record each run in the same decision file so the evidence stays current.

What changes on each path, and what stays the same

Moving to Project Server Subscription Edition keeps most of what your teams already use. Planners keep the Project desktop client, the schedule files, the calendars and the resource pools they built, and your administrators keep working with the Microsoft stack they already run, including the SharePoint and SQL Server components and the Active Directory accounts behind them. The main change is the release model: Subscription Edition is still in support, so you move to a supported product with current security updates rather than running an unsupported farm. Confirm with your Microsoft account team which Subscription Edition build and licensing terms apply to your farm, and check whether your existing Project Web App customizations, custom fields and reporting connections work on that build before you commit to a date.

Moving to OpenProject changes the work surface and the data model. Planners and team members work in a browser, using work packages as the central object, with Gantt charts, agile boards, time tracking and dashboards in one place. Work packages, relations, versions and custom fields are modeled differently from Project tasks, resource assignments and Project Web App entities, so a one-to-one mapping is not a safe assumption. Baselines, resource leveling and the Project Web App specifics such as timesheet approval flows and custom reports need to be checked line by line against the migration guide for Microsoft Project (the OpenProject Jira migration page is the only supplied source, so confirm the Microsoft Project path directly with OpenProject before planning) and tested on a copy of real schedules before anyone relies on them.

Which replacement options fit a supported, self-hosted estate

This table compares five paths for a supported, self-hosted estate: staying on Project Server Subscription Edition, or moving to OpenProject Community, OpenProject Enterprise on-premises, Redmine or Plane. Read each row for where data stays, how licensing works, support status and the gaps to test. The main takeaway is that portfolio and resource management sits in paid OpenProject Enterprise plans, so confirm those needs before choosing a free option.

Option	Data location and licensing	Support status	Gaps to confirm
Project Server Subscription Edition	Runs on your own servers in a SharePoint and SQL Server farm, licensed by Microsoft	Still in support; confirm the current end date in Microsoft's lifecycle pages	Keeps Project Server skills, farm maintenance and Microsoft licensing costs in place
OpenProject Community	Self-hosted on your servers; free under GPL-3.0	Community support only	No portfolio or resource management and no SSO, LDAP sync or SCIM provisioning
OpenProject Enterprise on-premises	Self-hosted on your servers; priced per named user per month with minimums	Support terms depend on the plan; confirm response commitments in writing	Portfolio and resource management, SSO and LDAP sync are paid features; check which tier includes each
Redmine	Self-hosted on your servers; GPL v2 licensed; version 7.0.2 released September 30, 2026	Open-source community support; commercial support via third parties	Needs a separate fit check for schedule dependencies and resource planning
Plane Community	Self-hosted on your servers; AGPL-3.0 licensed; version 1.4.2 released August 23, 2026	Community support; confirm the support options for your deployment	Needs a separate fit check for scheduling and resource needs; confirm which importers the Community Edition includes

Choosing a path by situation

Some organizations must stay on Microsoft because a contract, an approved toolchain or a workforce that depends on the Project desktop client makes migration impractical. In that case the work is to move the farm from 2019 to a release that is still supported, and to confirm which Microsoft product that is before any installation starts.

Confirm Microsoft support terms: Check the lifecycle entry for Project Server Subscription Edition and the agreement that covers your farm, including whether your licensing includes the upgrade path.
Confirm your identity provider: Record which directory and sign-in method the farm uses today so users keep their access and permissions after the upgrade.
Confirm your database platform: Check the SQL Server version and confirm that the target release supports it before you build a test environment.
Inventory custom code and add-ins: List solutions, workflows and integrations that must be retested on the target release.
Work in a copy first: Build a test farm from a recent backup, run the upgrade there, and keep the production farm frozen until the test results are signed off.

Confirm that the target release is still in support on the date you plan to finish the move.

How to keep the 2019 farm safe during the move

This sequence keeps an unsupported Project Server 2019 farm contained and recoverable while the migration to Subscription Edition or OpenProject proceeds, so that every later change has a tested rollback and a documented end point.

Inventory the farm and its components
Record every server in the farm, including the web front ends, application servers, SharePoint content and service databases, and the SQL Server instances that hold Project Server data. Note versions, patch levels, service applications, custom solutions, integrations with Excel, Power BI or finance systems, and scheduled jobs. The owner of the farm, usually the SharePoint or Project administrator working with the database team, signs off the inventory. It is done when every component has an owner and a documented dependency list that the migration team can check against.
Restrict network access to named users
Limit access to the farm to named user groups, named administrators and the specific service paths the migration needs, using firewall rules, network segments and reverse proxy allow lists. Remove any public exposure of the farm and close management ports to all but the administrator jump hosts. Your security team tests the rules from outside and inside the network and keeps the results. It is done when the test log shows that unlisted sources cannot reach the farm and that every listed path is documented.
Review and remove unnecessary accounts
Review the farm administrators, the SharePoint and Project service accounts, the SQL Server logins and the service identities used by scheduled jobs and integrations. Remove accounts for leavers and unused integrations, reduce privileges to what each service needs, and move service identities to managed or rotated credentials where the platform allows it. Record each change with the approver's name. It is done when an access review lists every remaining account with its owner and purpose, and no shared administrator password remains in use.
Take verified backups before any change
Take full backups of the SQL Server databases and the SharePoint content and configuration, and keep the farm backup set that your administrators use for recovery. Restore the backups to a separate test environment and confirm that the Project Server data, the Project Web App sites and the reporting data open correctly. Store copies away from the farm so that a fault in the farm does not remove them. It is done when a restore test has passed and the backup location, retention and restore steps are written down.
Freeze new configuration
Agree a change freeze for the farm that covers configuration, custom solutions, service applications, patching and new projects that depend on farm-specific settings. Only emergency security fixes go through an approved change record, and each one is tested against the restore environment first. Publish the freeze to project managers and finance users so that new work is planned for the target platform. It is done when the change freeze is communicated, the exception process is written, and the change log shows no unapproved changes since the freeze date.
Set a retirement date with export checkpoints
Set a retirement date for the farm in the written migration plan, then define checkpoints before it. Each checkpoint names what is exported, such as project schedules, resource data, timesheet history and reports, the format used, the reconciliation check against the source and the owner who signs it off. Keep read-only access to the farm until the last checkpoint has been reconciled. Your fixed-scope engagement records these steps, owners and checkpoints in writing before work starts. It is done when the signed plan shows a retirement date, each checkpoint has a reconciled export, and the decommissioning steps are approved.

Evidence to keep for the decision and the cutover

Each card below is a record that should exist before the farm is switched off or migrated. Together they show who decided, what was moved, how it can be restored and when the old system was retired. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.

Written decision record and owner

Keep a dated decision record that names one accountable owner and states whether the team chose Project Server Subscription Edition or OpenProject. Record the options weighed, the business owners who approved the choice and the conditions that would trigger a change of course. Because Project Server 2019 is past its extended support end date, the record should also state the interim risk accepted while the farm stays in service.

Inventory and access review

List every Project Server and SharePoint component, the SQL Server instances behind it, the projects, resource pools, custom fields and integrations that depend on them, and every account with administrative or write access. Confirm which users still sign in and which service accounts feed reports or finance exports. Stale accounts and undocumented integrations are the most common surprises during a cutover.

Backup and restore test results

A backup is only evidence once a restore has been performed. Record the date of the most recent full backup of the content and configuration databases, the restore target used, the time taken and the checks run afterward, such as project counts and sample schedules compared with the source. Store results beside the decision record so the team can show the farm can be rebuilt if the upgrade fails.

Data export checkpoints

Define checkpoints where project data is exported and compared with the source, including task hierarchy, dependencies, dates, assignees and custom fields. Note what does not carry over, such as baselines and leveling results, and record how each gap is handled. For OpenProject, the import route depends on the source format, so confirm the migration path with the vendor before the first export.

Sizing check against user count

Compare the named user count and the expected concurrent use with OpenProject's sizing guidance, which lists 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. Record the supported operating system, the PostgreSQL version (16 or later) and the required extensions. Keep the results with the test environment so capacity assumptions are traceable.

Sign-off for retirement

Retirement of the old farm should require a signed record from the business owner, the system owner and the security team. The record should confirm that data has been migrated and verified, that backups are retained for the agreed period, that access has been removed and that integrations have been switched off. Auditors and certification bodies can then test the record against your own control framework.

How much does moving off Project Server 2019 cost, and what drives it?

What does Project Server Subscription Edition cost compared with OpenProject?

Subscription Edition pricing depends on your Microsoft agreement, user counts and the server and database costs you already carry, so take the figures from Microsoft's current licensing documentation and your reseller quote rather than from this page. OpenProject Community is free and self-supported. Its Enterprise on-premises plans are priced per named user per month: Basic at 5.95 euros, Professional at 10.95 euros with a 25-user minimum, and Premium at 15.95 euros with a 100-user minimum. Corporate is quoted on request for 250 or more users. SSO and LDAP group synchronization sit in the paid tiers, so check them against your identity requirements. Compare the total by component: licenses, servers, migration, and support for each option. Current OpenProject prices are listed on the OpenProject pricing page.

How long does a migration off Project Server 2019 take?

No duration is fixed for this kind of move, and any timeline you are given should be tied to a written scope. The main drivers are the number of projects and schedules, how many tasks, dependencies, custom fields and resource calendars each one carries, how many reports and integrations depend on the farm, and how quickly your team can review and sign off the results. Ask the consultant or your team to break the timeline into inventory, data preparation, a test import, validation, cutover and post-go-live fixes. A pilot with a handful of representative projects usually shows the effort per project more reliably than an estimate made from a project count alone.

What does our team need to provide for the migration?

The migration needs decisions and access from your side as much as technical work. Expect to provide:

An inventory of active projects, owners and the schedules that must move
Decisions on which baselines, history and resource assignments are kept as reference rather than rebuilt
A list of custom fields, reports, dashboards and integrations with SharePoint, finance or other systems
Access to the farm, exports and test environments, with a named person for each business area
Sign-off authority for test imports and the cutover date

The more of this you define before work starts, the fewer change requests you will pay for later.

Can our internal team migrate Project Server data without outside help?

Yes, if your team has the skills and the time, but plan for the work as a project of its own. OpenProject is GPL-3.0 and the Community edition is free, so licensing is not the barrier. The effort lies in building and hardening the server, running PostgreSQL 16 or later with the required extensions, sizing the hosts, and moving content by export and Excel upload. Confirm with OpenProject which steps need an Enterprise plan. Your team also has to rebuild resources, custom fields and hierarchies by hand and verify the results against the source files. Many organizations keep an internal owner and bring in a partner for specific parts, such as hardening, backups or validation.

What happens if the Project Server 2019 farm stays online after July 14, 2026?

Extended support for Project Server 2019 ended on July 14, 2026, so the farm no longer receives the standard security updates it relied on. It can keep running, but each new vulnerability in the operating system, SQL Server, SharePoint or the application itself stays open unless you apply a compensating control. Reduce exposure while you plan: restrict network access to named users, limit administrative paths, keep verified backups of the content and databases, and record the risk and the approved end date in your risk register. Confirm the lifecycle dates and any available options directly with Microsoft's product lifecycle documentation. If your organization is subject to a compliance assessment, ask your assessor how an unsupported system will be treated.

Can OpenProject import Project Server data directly?

No. No migrator for Project Server is supplied with OpenProject, so the practical route is the Excel route: export your schedules to Excel and upload work packages with their hierarchy and relations through OpenProject's Excel synchronization. The Jira Migrator is a different tool. It is in beta, supports only Jira Data Center 10.x and 11.x, and does not support Jira Cloud, so it does not apply to Project Server. Expect baselines, leveling results and some resource and custom field data to need manual rebuilding. Ask any partner to test the Excel route on a sample project before committing to a full scope.

What should a written quote from an implementation partner include?

A usable quote states scope, deliverables, assumptions and exclusions in writing before work starts. Ask for:

The number of projects, tasks, users and custom fields included, and what is out of scope
Hosting design, including the sizing basis and the environments (test and production)
Responsibilities split between your team and the partner
Data validation steps, acceptance criteria and the change control process
Backup, upgrade and support terms, and whether ongoing support is a separate retainer
How baselines, resource leveling and reports will be handled

At DeployOpen, most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen contains and replaces a legacy Project Server farm

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so an unsupported Project Server 2019 farm can be contained while you choose between upgrading and replacing it. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the Project Server 2019 farm, SharePoint and SQL Server dependencies, custom fields, and the users and reports that depend on them
Document which schedules, baselines, timesheets and portfolio views must carry over, and which can be retired
Agree in writing whether the work covers upgrade to Project Server Subscription Edition, replacement with OpenProject, or both
Confirm the target environment, hosting location and data residency requirements before any build work starts

How we build

Stand up OpenProject in your own cloud account, data center or air-gapped network using Docker or packaged installs
Confirm the PostgreSQL 16 or later setup with the required extensions and size the servers to your user count
Configure single sign-on, LDAP group synchronization and custom fields against your identity provider, using the Enterprise features your plan includes
Run security testing of the new platform and the migration path before any production data moves

How we hand over

Provide written documentation of the architecture, configuration, data mapping and the migration decisions made
Record which Project Server data was exported, what was rebuilt manually, and what did not carry over
Prepare compliance readiness evidence and controls for your assessors, without issuing audit reports or certifications
Train administrators and project owners on the new platform and on the access controls applied

How we support

Keep the legacy farm isolated and restricted to read-only access while the migration is in progress, with the changes agreed in scope
Offer ongoing support, upgrades and continuous testing as a retainer after handover
Plan OpenProject upgrades against the release notes and test each upgrade in a staging copy first
Maintain backups of the OpenProject database and attachments, with restore tests documented for your team

Project Server 2019 end of support: upgrade or replace