Which open-source option replaces Project Web App timesheets
If your teams enter timesheets and status updates in Project Web App and finance pulls its numbers from Project Server, the replacement question is narrower than a full project tool decision. OpenProject's Community edition includes time tracking against work packages, along with dashboards, so individuals can log hours against the tasks they are assigned and managers can see progress without a paid plan. Cost and budget reporting, approval routing for submitted hours, single sign-on and LDAP group synchronization are the parts to check against your current process. Per the vendor's pricing page, SSO, LDAP group synchronization and the Jira Migrator sit in paid Enterprise plans, so approval and identity requirements may be the deciding factor in edition choice.
Confirm three gaps early, before any build work. First, there is no direct import from Project Server or Project Web App timesheet data in the supplied documentation, so historical hours will likely need to be exported and mapped by your own team or partner. Second, confirm in a trial instance how OpenProject's time entry, cost and budget views match the period, rate and approval structure your finance team uses today. Third, confirm whether the timesheet approval steps you rely on are available in your chosen edition, and whether they cover your current delegation rules. Document each answer in writing, because these three points determine how much of the Project Web App workflow you can reproduce and what your finance exports need to read instead.
How Project Web App timesheet features map to OpenProject
This table maps each Project Web App timesheet feature to its nearest OpenProject option, the edition that includes it and the points to confirm in your own environment. Read the edition column first, because directory sync and SSO sit in paid Enterprise plans while time tracking is included in Community. Where the supplied material gives no evidence of parity, such as approval routing and finance exports, treat the row as an open question to test in a proof of concept.
| Project Web App feature | OpenProject option | Edition | Coverage and what to confirm |
|---|---|---|---|
| Timesheet entry | Time entries logged against work packages in the time tracking module | Community | Confirm the weekly entry view and whether users can enter time by day against the same work packages. |
| Task-level time logging | Time booked to individual work packages, including child items in a hierarchy | Community | Confirm how parent totals roll up before finance relies on them, and test with a sample plan. |
| Status updates | Work package status, progress fields and project dashboards | Community | Confirm the statuses match your reporting cadence and any status rules you use in Project Server today. |
| Cost and budget reporting | Cost and budget fields on work packages, reported through dashboards or exports | Confirm for your plan | Confirm which cost and budget fields your edition exposes and compare results against a known project budget. |
| Approval routing | No timesheet approval workflow is confirmed in the supplied material | Confirm | Ask OpenProject whether your target version offers approval steps. If not, plan a manual sign-off or an external workflow. |
| User and group sync | Single sign-on (SAML, OIDC) and LDAP group synchronization | Enterprise | SCIM provisioning is also Enterprise. Confirm your directory requirements before choosing a plan. |
| Export to finance | Work package and time entry exports, plus API access for scheduled extracts | Confirm for your plan | Confirm the column set and format with finance, and check that existing Project Server reads map to the exported fields. |
Which self-hosted tools fit timesheet-led teams
Timesheet-led teams usually need hours logged against tasks, a way to see cost against budget, and a clear approval step. The four options below differ mainly in how much project structure, reporting and access control they bring, and in what each one costs to run. Check each card against your approval chain and finance exports before you choose.
OpenProject Community
The free edition includes work packages, time tracking and dashboards, so hours can be logged directly against the tasks a project manager already maintains. It fits small or mid-sized teams that can accept community support and handle their own upgrades. The trade-off is that single sign-on, LDAP group synchronization and SCIM provisioning sit in paid Enterprise plans, so account management stays manual. Confirm whether the cost and budget reports you need are available in the Community edition before you rely on them.
OpenProject Enterprise on-premises
Enterprise on-premises adds single sign-on through SAML, OIDC, CAS, Kerberos or Okta, LDAP group synchronization and custom branding, which matter when timesheet access must follow your directory. It is priced per named user per month, with a minimum of 25 users on Professional and 100 on Premium. Ask the vendor how approvals and cost reporting are configured in each tier, and whether the Jira Migrator, listed from Basic upward, is needed for your move.
Redmine with built-in time tracking
Redmine is a GPL v2 application on Ruby on Rails that includes time tracking against issues, Gantt charts and LDAP authentication, with no per-user license fee. It suits teams that record hours against issues and need Git or Subversion links. Its interface looks dated compared with current tools, and budget reporting usually depends on plugins or custom reports. Plan for a Ruby on Rails administrator and a review of the plugins you need, since their upkeep is a recurring effort.
Plane as a lighter option
Plane is a lighter issue and project tracker licensed AGPL-3.0, with a Community Edition you run yourself. It works well for teams whose timesheets are a side task and whose main need is clear work item tracking. Its reporting on budgets and cost is narrower than OpenProject's, so finance may need exports into a spreadsheet or BI tool. Confirm time logging, approval steps and cost fields in the current release before you commit, because the feature set changes between versions.
What changes for finance exports that read Project Server data
Finance jobs that read Project Server or Project Web App reporting tables will need to be rewritten against OpenProject's data model, its API or its exports. Nothing in OpenProject reads those SQL views or OData feeds, so a nightly job that pulls hours, costs or project status into a general ledger or a cost allocation tool will stop returning data at cutover. Before scoping, inventory every consumer of the timesheet data, including reports that finance builds by hand from exports, and record which fields each one uses. Confirm with OpenProject which export formats, API endpoints and fields are available in your edition and version, because the exact shape of what you can extract is the first thing the rewrite depends on.
The mapping work centers on four things. Time entries become time entries linked to work packages, so each finance line needs a stable work package ID to join on. Project codes from Project Server have to be carried into a custom field or a project identifier that finance recognizes, and that mapping should be written down and tested with a sample month. Rate fields, such as cost rates per user or role, must be rebuilt from the source system because they do not carry over as-is, and you should agree with finance which rate applies to each period. Finally, check how rounding, currency and time zone are stored so totals reconcile with the last Project Web App period.
Historical timesheet data usually stays in an archive rather than being loaded into OpenProject in full. Keep a read-only export of the Project Server reporting data with its schema documented, and define who can query it, how long it is retained and how finance reaches it for prior-year audit requests. Ask your OpenProject partner or OpenProject directly whether historical time entries can be imported and at what level of detail, and plan the archive read path before the old environment is switched off.
Running OpenProject beside the rest of the Microsoft estate
Timesheets rarely move alone. Project desktop schedules, Microsoft 365 sign-in and the finance tools that read Project Server data all keep running while OpenProject takes over time entry. The cards below cover the integration points that decide whether the transition is smooth for approvers and finance staff.
Identity federation through SSO
Staff who already sign in with Microsoft 365 should not manage a second password for timesheets. SSO for OpenProject is listed among the Enterprise features (SAML and OIDC are both named), so the Community edition will not federate with your directory. Confirm which identity provider you will federate, whether group claims can map to OpenProject roles, and how deprovisioning a leaver is handled, since SCIM provisioning also sits in paid Enterprise plans.
LDAP group synchronization for approvers
Timesheet approval depends on who belongs to which project group. OpenProject lists LDAP group synchronization as an Enterprise feature, so group membership can follow the directory instead of being maintained by hand. Confirm that your directory groups match the project and approver structure you want to keep, and decide who owns those groups after Project Web App is decommissioned.
Project desktop schedules stay in place
Project desktop schedules will not move into OpenProject on their own. Teams that keep building plans in the Project desktop client need a clear rule for which system holds the planned work packages and which holds actual hours. Decide whether schedule updates are pushed by hand, exported on a fixed cadence, or retired, and confirm that the work package IDs used for time entry match the schedule your finance team expects.
Optional Nextcloud file linking
Status packs, change requests and signed approvals often live in SharePoint or OneDrive. OpenProject provides a Nextcloud integration, so work packages can link to files held on a self-hosted Nextcloud instead. This is optional. Confirm whether your Microsoft 365 document links will remain valid, whether Nextcloud is needed at all, and who will maintain file permissions across the two systems.
Read-only Project Server access during transition
Finance and reporting jobs often read historical actuals from Project Server. Keeping the farm readable for a defined period lets those extracts run while OpenProject time data accumulates. Confirm which views, tables or reports your jobs query, who holds the credentials, and when the farm is switched to read-only. Ask Microsoft or your Project Server administrator how the read-only period is configured on your version.
Finance export format changes
Finance tools that read Project Server data expect fields such as actual work, cost and resource identifiers in a specific shape. OpenProject exports will differ in column names, time units and how project and work package hierarchies are flattened. Before cutover, map each consumed field to its OpenProject equivalent, run both feeds in parallel for at least one reporting cycle, and reconcile totals with the finance owner.
How to move timesheet data and users to OpenProject
This sequence moves timesheet logging, users and approval routines from Project Web App into a self-hosted OpenProject instance, with each step closing on a check you can verify. It also makes clear which records must be exported and archived because they will not transfer directly.
Inventory timesheet fields and approval paths
Project managers, finance and the Project Server administrator list every timesheet field in use, including task-level and project-level entry, custom enterprise fields, reporting periods, and who approves which timesheets and through which steps. Record which fields feed finance exports and which approvals are formal sign-offs. The output is a signed-off inventory that names each field and each approver. You know it is done when every field in the list has an owner and a documented destination, or a decision to drop it.
Define work packages that replace tasks
Map the Project Server task hierarchy to an OpenProject work package structure, deciding which tasks become work packages, which become parent packages, and which codes or enterprise fields become custom fields or project attributes. Time is booked against work packages, so the team decides the granularity at which people will log hours. The output is a mapping sheet reviewed by one project manager and one finance lead. You know it is done when each timesheet line in the inventory maps to exactly one work package or a defined overhead bucket.
Install and configure OpenProject
The platform team installs OpenProject inside your own infrastructure, using the supported installation path for your environment, and checks it against the system requirements for PostgreSQL and the sizing guide for your user count. They enable time tracking, configure cost types and rates where finance needs them, and set up the authentication method chosen for the pilot. The output is a staging instance with backups configured. You know it is done when a test user can log time against a test work package and the database backup restores into a separate environment.
Import users and groups
The identity administrator recreates users and groups from the Project Server directory, using the directory the organization already controls, and confirms which people need time logging, approval or report access. Single sign-on, LDAP group synchronization and SCIM provisioning are Enterprise features, so confirm the required plan before designing the group model. The output is a list of accounts, groups and roles checked against the approver inventory. You know it is done when every active approver and timesheet submitter signs in to staging and sees only the projects they should.
Pilot time logging on one project
Choose one active project with a clear approval path and have its team log time in OpenProject for a full reporting period, in parallel with Project Web App where possible. Compare the hours each person booked in both systems and collect feedback on the work package granularity. The pilot tests the approval flow your organization actually uses, so record any approval step that OpenProject does not reproduce exactly. You know it is done when hours match between systems for the pilot project and the team agrees on the work package rules.
Rebuild cost and budget reports
Finance rebuilds the cost and budget views it relies on, using OpenProject's time tracking, cost types and reporting, and checks each rebuilt report against the same figures from Project Web App for the pilot project. Where a report needed a Project Server feature OpenProject does not provide, record the gap and the workaround. The output is a reconciliation sheet listing each report, its source, and any differences explained. You know it is done when finance signs off that the pilot totals reconcile to the Project Server figures.
Cut over finance exports
Finance and the integration owner replace each export that read Project Server data with an equivalent read from OpenProject, or with a scheduled export from OpenProject, and run both in parallel for one closing cycle. Any export that depended on OData or database views must be reviewed with the vendor documentation for your OpenProject version before cutover. The output is a cutover record for each export with its owner. You know it is done when the parallel run produces matching totals and the old export is switched off in a dated change record.
Export and archive Project Server data
Before decommissioning, export actuals history, approval records, submitted timesheets and audit trails from Project Web App and store them in a documented archive that your records policy covers. Actuals history and approval records may not transfer directly into OpenProject, so treat the archive as the system of record for past periods. Confirm retention periods with your legal and compliance owners rather than assuming them. You know it is done when the archive is restored and read by a second person, and the owner signs the retention record.
Questions buyers ask before replacing Project Web App timesheets
What drives the cost of replacing Project Web App timesheets with OpenProject?
The main drivers are the edition you choose, the number of named users who log time, the servers you run OpenProject on, and the effort to configure time tracking, cost reports and approvals. The Community edition has no license fee, but it does not include SSO, LDAP group synchronization or the other Enterprise features, so organizations that need them will pay per named user. Ongoing costs include server operations, backups, upgrades and support. Ask for a written quote that separates one-time setup from recurring licensing and hosting.
Can our internal team replace Project Web App timesheets without an outside partner?
Often yes, if you have staff who can run a Linux server, a PostgreSQL database and a Docker-based deployment, and who can define time tracking, approval and reporting rules in OpenProject. The harder parts are usually not the software install but agreeing on approval routes, mapping cost fields to finance categories and rebuilding finance exports. Consider how much of this your team has done before, who will own upgrades, and whether anyone can cover the platform when a release changes behavior. A fixed-scope implementation is one option if these skills are thin.
How long does a pilot of OpenProject for timesheets usually take?
A pilot length depends on the number of projects, the approval chains you need to model and how many finance reports must match your current outputs. Nothing in the supplied research gives a fixed duration, so treat any number you hear as an estimate to verify. A useful pilot covers one or two real project portfolios, a small group of named users, the approval flow and one finance export, then checks the totals against Project Web App for the same period. Ask the implementer to put the pilot scope, exit criteria and timeline in writing before work starts.
What must our team provide before an OpenProject timesheet implementation starts?
Work with three inputs ready: a current user directory, the finance field definitions and the approval rules. The directory determines who gets an account and whether LDAP group synchronization is needed, which is an Enterprise feature. Finance field definitions cover cost centers, rates, currencies and budget categories, so reports reconcile with ledger data. Approval rules should state who approves timesheets for each project, how delegation works and when locked periods apply. Missing any of these usually extends the setup phase more than the software itself.
Which OpenProject plan do we need for named-user licensing of timesheet users?
Enterprise on-premises plans are priced per named user per month, and the supplied pricing lists Basic at 5.95 euros and Professional at 10.95 euros per user per month, with Professional requiring a 25-user minimum. Premium is 15.95 euros per user per month with a 100-user minimum, and Corporate is quoted on request for 250 or more users. Check whether every person who logs time needs a named seat, and whether viewers or approvers are counted differently under the terms you receive. Confirm the current pricing page before budgeting, because prices can change.
How many servers and what hardware do we need for OpenProject?
The supplied sizing guidance 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. Actual load depends on how many people log time at the same moment, how many attachments you store and how heavily you run reports. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and PostgreSQL 16 or later is required. Use the system requirements page to confirm your target environment, and test under realistic peak load.
What does a DeployOpen engagement cover for a timesheet replacement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this topic, that can include deploying OpenProject, configuring time tracking, cost and approval settings, and preparing the finance export handover. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a quote based on your written scope.
Where OpenProject does not match Project Web App
The first gap is that OpenProject has no direct import path from Project Server or Project Online that carries timesheet history across. Time entries, approval records and resource assignments held in Project Web App will need to be exported and rebuilt as work package time entries, users and rates. The Jira Migrator documented by OpenProject is built for Jira Data Center 10.x and 11.x and is in beta, so it has no role in this migration and should be removed from the plan. Ask OpenProject which export formats its current release accepts for time data, and confirm that your historical periods can be loaded with their original dates and users before you commit to a cutover.
The second gap is approval and portfolio depth. Single sign-on, LDAP group synchronization, SCIM provisioning and portfolio and resource management are listed among the paid Enterprise features on the OpenProject pricing page, so the Community edition will not cover those needs. Map each approval step your organization uses today, such as manager submission, multi-level sign-off and period locking, to the exact configuration your chosen plan provides. Do not assume that a multi-step chain in Project Web App has a one-to-one equivalent. Confirm this with OpenProject against a written list of your approval rules, and budget for the Enterprise tier only once that list is confirmed.
The third gap is reporting. Finance teams that build workbooks from Project Web App data will find that field names, time granularity and cost calculations differ, so every report needs a new column mapping and a check of how rates are applied. Illustrative example: if a monthly cost roll-up by department depends on a Project Web App field that has no matching OpenProject field, the report will break at the first run. Before committing, build a pilot instance, load a representative set of users and projects, and run your most complex timesheet report, including its approvals and period totals. Compare the results line by line with the Project Web App figures for the same period, and only proceed when the differences are explained and accepted by finance.
How DeployOpen scopes and delivers timesheet replacement
DeployOpen plans, implements, integrates, documents and supports self-hosted OpenProject inside your own infrastructure, so time entries, budgets and approval records stay on your servers. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Project Web App timesheet periods, time entry types and status reports the business actually uses
- Map each finance export that reads Project Server data to the OpenProject report, API call or replacement feed
- Agree the edition needed for SSO, LDAP group synchronization and the Jira Migrator, if those are in use
- Record the written scope, deliverables and timeline before any build work begins
How we build
- Deploy OpenProject with Docker or packaged installs in the cloud accounts or data centers you choose
- Configure projects, work packages, time tracking activities, cost types and budgets to mirror your timesheet structure
- Set up approval steps and status update conventions, then test them with real project managers in a staging instance
- Run security testing and check PostgreSQL 16 or later with the required extensions before go-live
How we hand over
- Provide configuration documentation covering projects, roles, cost reports, export jobs and approval workflows
- Train project managers, finance reviewers and administrators on the timesheet and reporting procedures
- Deliver backup and restore runbooks, and confirm which exports and retained records need independent sign-off
- Prepare control evidence for your compliance assessors, while independent auditors and certification bodies issue any opinions
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan OpenProject version upgrades against the release notes and test them before production rollout
- Review sizing as user counts grow, using OpenProject's sizing guide as a starting point
- Ask for a written quote based on your scope, user count, edition and support level
