Migrate from Jira to OpenProject: what the move involves
OpenProject can take Jira project data, but its Jira Migrator is in beta and only reads Jira Data Center 10.x and 11.x. Jira Cloud is not a source for that tool, so a Cloud customer needs a different extraction route before any OpenProject import can start. Start by confirming your exact Jira product and version, because a renewal deadline or a residency requirement may push the decision faster than the migration itself can run.
In most organizations the work is shared. The internal platform or IT team owns the target environment, the identity integration, backups and the decision about which Jira projects move at all. An implementation partner, if used, typically handles the migration runs, the mapping of Jira statuses and issue types to OpenProject types and statuses, and the documentation of what was rebuilt by hand. Agree in writing which party is responsible for test imports, cutover validation and the final reconciliation of issue counts, comments and attachments. Ask any partner to state those responsibilities in the fixed scope before work begins.
Effort and risk depend less on the tool than on the state of the Jira instance. Projects with clean statuses, few custom fields and limited app dependencies move with fewer surprises. Workflows, permissions, schemes and automation rules do not carry over automatically and must be rebuilt in OpenProject, so plan a review of each one with the teams who use them. The migrator documentation advises using it only in test setups while it is beta, so run at least one full trial import into a non-production instance and check results against the source before you schedule a production cutover. Ask OpenProject and your partner to confirm the current migrator behavior against your Data Center version.
Which Jira capabilities map cleanly to OpenProject
This table compares Jira capabilities with their closest OpenProject equivalents and marks each as clean, needs rework or gap. Read it as a checklist: the rows marked clean can usually move with the importer, while rework and gap rows need a manual rebuild or a different tool. Verify each row against your own Jira configuration before you commit to a plan.
| Jira capability | OpenProject equivalent | Status and notes |
|---|---|---|
| Issues, history, comments and attachments | Work packages with history, comments and attachments | Clean: the Jira Migrator documentation lists issues with history, comments and attachments as imported; test with a sample project first |
| Basic custom fields | Work package custom fields | Clean for basic types; needs rework for complex field types, calculated fields or field-level rules, which the importer does not list |
| Users, statuses and issue types | Users, statuses and types | Clean: listed as imported; confirm that status names and type names map to the ones your teams use |
| Projects and versions | Projects and versions | Clean: listed as imported; check how nested or archived projects are represented after the move |
| Boards and sprints | Agile boards and sprint-style planning in work packages | Needs rework: boards are rebuilt in OpenProject, and sprint history is not a documented import item |
| Workflows and permission schemes | Statuses, transitions and project roles | Gap for direct import: rebuild transitions and role permissions by hand and review them with each team lead |
| Automation rules and Jira apps | Built-in notifications and separate integrations | Gap: automation rules and third-party apps are not part of the importer and must be redesigned or replaced |
| Dashboards and filters | Work package views, queries and dashboards | Needs rework: saved filters and dashboards are recreated, not imported |
| Advanced Roadmaps | Gantt charts and portfolio management in paid Enterprise plans | Gap in Community: portfolio planning sits in paid Enterprise plans, so confirm the required plan with OpenProject before scoping |
| Single sign-on, LDAP sync and access control | SSO and LDAP group sync in paid Enterprise plans | Needs a paid plan: Community covers core features, while SSO and LDAP synchronization are Enterprise features |
What data moves, from which export path, and what to rebuild
The Jira Migrator covers a defined set of Data Center objects, and it does not reach Jira Cloud at all. Each card below marks one thing that moves, one thing that does not, or one thing you rebuild by hand, so you can plan the source path before you plan the target.
Core objects the Jira Migrator imports
The beta migrator brings over projects, versions, issues with their history, comments, attachments, basic custom fields, users, statuses and work item types. Check each custom field type against your instance, because only basic custom fields are documented as supported. Anything more complex, such as cascading or calculated fields, should be treated as a manual rebuild and tested in a non-production run.
Data Center version requirement
The migrator reads from Jira Data Center 10.x and 11.x only. Confirm your exact build before you commit to a route, because a Server or older Data Center instance falls outside the documented scope. Record the version in your migration plan so the decision is traceable later.
Jira Cloud backups exclude key data
Jira Cloud backup covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. It does not include automation rules, third-party apps or Assets. If you run Cloud, plan a CSV or API extraction for the missing parts and treat automation and app logic as a rebuild item from the start.
Workflows, schemes and permissions
Statuses and types import, but workflow transitions, permission schemes and notification rules must be mapped to OpenProject roles, statuses and types by hand. Document each Jira role and who holds it, then confirm project-level access in a test instance. Expect this to be one of the larger manual efforts in the project.
Single sign-on and directory sync
SSO through SAML, OIDC, CAS, Kerberos or Okta, plus LDAP group synchronization, sits in OpenProject Enterprise plans. Plan the identity setup before cutover so users can sign in on day one. Confirm which plan tier your chosen features need, since the migrator itself is listed from Basic upward.
Nextcloud file links and CI or source links
Attachments move with issues, but links that point to Nextcloud files, Git commits, pull requests or pipelines do not repair themselves. OpenProject has a documented Nextcloud integration, so review it if your file store is Nextcloud. Re-point source and CI links, and test whether each one still resolves after cutover.
Why Jira Cloud users need a different route than the Migrator
The OpenProject Jira Migrator does not support Jira Cloud. It imports from Jira Data Center 10.x and 11.x only, and the migration documentation describes it as beta and suitable for test setups. If your projects live in Jira Cloud, the Migrator is not a route to production, so you need a separate extraction plan before you commit to OpenProject. Confirm the current Cloud export options with Atlassian and check the OpenProject Jira migration documentation for any change in supported sources before you set a date. Jira Cloud's backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. That is a useful base for a move, because it preserves the issue record and the configuration that defines how work flows. It does not cover automation rules, third-party apps or Assets. Each of those must be inventoried by hand from the Jira admin screens, documented, and rebuilt in OpenProject or retired. Ask your Jira administrator for a list of installed apps and active automation rules, and record which projects depend on them before any data leaves Atlassian.
How the migration sequence runs from inventory to decommission
The sequence moves Jira Data Center projects into OpenProject in controlled stages, so each stage produces evidence that the next one can rely on. Each step ends with a written output that the project owner signs off before work continues.
Inventory projects, workflows, permissions and integrations
Start by listing every Jira Data Center project with its issue counts, attachment volume, active versions, custom fields, issue types and statuses. Record the workflows and permission schemes that govern each project, along with every app, automation rule and integration that reads or writes issues. Assign the work to the Jira administrator and a named project owner for each project. The output is a signed inventory that marks each element as migrate, rebuild or retire, so nothing is lost by accident.
Run a test-only pilot on Data Center data
Run the OpenProject Jira Migrator against a copy of representative Jira Data Center 10.x or 11.x data in a test environment, not against production. The documentation advises use of the beta migrator only in test setups. Compare the imported projects, versions, issues, history, comments, attachments, users, statuses and types with the source, and log every field that did not arrive. The output is a pilot report listing what transferred cleanly, what needs manual handling and what must be rebuilt.
Rebuild workflows, roles and integrations in OpenProject
Using the pilot report, configure OpenProject types, statuses, custom fields, roles and project permissions to match the business rules you intended to keep, and rebuild the integrations that are still needed through OpenProject's APIs or the tools that replace them. Because the migrator does not carry over every Jira construct, treat this as design work that a reviewer signs off, not a copy operation. The output is a configuration baseline that the business owners have reviewed against the inventory.
Reconcile counts and attachments in a parallel run
Keep Jira available for reference while teams work in OpenProject on a trial set of projects. Load the production-scope data into OpenProject, then compare issue counts, comment counts, attachment counts and file checksums per project against the Jira export. Record every mismatch and its cause before accepting the result. The output is a reconciliation sheet per project showing zero unexplained differences, or a documented exception approved by the project owner.
Cut over with a final delta load and freeze window
Announce a freeze window in which no new work is created in Jira for the migrated projects. Export the changes made since the last load, apply them to OpenProject, and repeat the reconciliation for the delta. Switch user access to OpenProject, update links and notification routes, and confirm that single sign-on and group synchronization work for the migrated users. The output is a cutover record listing the time of freeze, the final counts and the users who confirmed access.
Decommission Jira with archived exports
After the agreed stabilization period, set the migrated Jira projects to read-only and retain a full archive. Store the export, the reconciliation sheets and the inventory in a location your records policy covers, and confirm with your legal and compliance owners how long they must be kept. Ask Atlassian to confirm which data your Data Center license or support terms require you to keep and how it can be exported before removal. The output is an archive index and a signed decommission record that closes the project.
What drives migration cost and duration
This table lists the factors that most change the cost and effort of moving from Jira to OpenProject, with how to reduce each one and what to request in a written quote. Read it before scoping, since several drivers depend on your Jira origin and on the Enterprise plan you select.
| Driver | Why it changes cost or effort | How to keep it down | Ask for in the quote |
|---|---|---|---|
| Jira origin and version | The Jira Migrator supports only Data Center 10.x and 11.x. Jira Cloud and other versions need a different route, which adds analysis and tooling work. | Confirm your exact version and deployment type early. Consider a Cloud export path only if you accept its scope limits. | Written confirmation of the supported source version and the approach for any unsupported source. |
| Number of projects and work items | Each project adds mapping, validation and test cycles. Issue history and comments increase the volume imported and checked. | Archive or close stale projects before migration. Migrate in waves, starting with a pilot project. | Assumed project count, issue count and history depth, with the number of test loads included. |
| Custom fields, workflows and permission schemes | The migrator imports only basic custom fields. Complex workflows and permission schemes are rebuilt by hand in OpenProject, which is usually the largest effort item. | Audit fields, statuses and schemes, then remove unused ones. Map each workflow to OpenProject statuses and types before building. | Itemized list of fields, workflows and permission rules to rebuild, and whether rebuilding is in scope. |
| Attachment volume | Attachments are imported with issues, so total storage and transfer time grow with file volume. Large files extend test runs. | Measure attachment size per project. Decide which old attachments stay in an archive instead of moving. | Total attachment size and the transfer method, plus storage sizing for the target server. |
| Integrations and apps | Jira apps, automation rules and external links are not imported by the migrator, so each one needs a replacement or a manual step. | List every integration and mark which ones must keep working. Retire low-value automations. | Inventory of integrations, the replacement for each, and whether integration work is priced separately. |
| Users, groups and identity | User and group mapping affects assignment accuracy. Enterprise single sign-on and LDAP group synchronization need paid plans and configuration. | Clean up inactive accounts before import. Confirm which identity source is authoritative. | Named user count, the Enterprise plan tier, and the identity integration included in scope. |
| Enterprise plan choice | Enterprise on-premises pricing is per named user per month. Basic is 5.95 euros, Professional 10.95 euros with a 25-user minimum, and Premium 15.95 euros with a 100-user minimum (OpenProject pricing page). | Compare named user counts against tier minimums. Confirm which features you need, since SSO, LDAP sync and branding sit in paid tiers. | Tier, billed user count and whether the Jira Migrator is included in the chosen Enterprise plan. |
| Hosting size | 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 (OpenProject system requirements). Larger teams need more infrastructure and operations time. | Size to your actual concurrent users. Use Docker for a simpler install, and confirm PostgreSQL 16 or later with its required extensions. | Server specification, database setup, backup design and who operates the environment after go-live. |
| Parallel-run length | Running Jira and OpenProject side by side keeps two systems to maintain and synchronize users and data. A longer overlap adds licensing and staff time on both sides. | Set a fixed cutover date and freeze Jira writes for the final load. Keep the parallel period as short as your testing allows. | Duration of the parallel run, who maintains each system during it, and the final cutover steps. |
What usually goes wrong and how to prevent it
Most failed Jira-to-OpenProject moves trace back to a few predictable gaps: a beta importer used too early, rebuilt rules that drift from the originals, and people working in two systems at once. Each card below names one risk and the check that prevents it.
Running the beta importer in production
The Jira Migrator is in beta, and the documentation advises using it only in test setups. Treat the first run as a rehearsal against a copy of your Jira Data Center instance, not as the cutover. Record every error, decide which gaps are acceptable, and confirm with OpenProject which beta limits still apply to your release before scheduling a production import.
Assuming workflows and permissions carry over
Statuses and types are imported, but workflow transitions, permission schemes and role logic must be rebuilt by hand in OpenProject. Write down each Jira workflow and who can transition or edit issues in each project, then map those rules to OpenProject roles and statuses. Have a project owner sign off on the mapping before users get access.
Losing attachments and issue history
The migrator is documented to bring over issue history, comments and attachments, but you should verify this on a sample project rather than assume it. Pick issues with long histories and large attachments, compare counts and file contents against Jira, and check that timestamps and authors look right. Missing files are easiest to catch before the source instance is shut down.
Mismatched user identities
Imported users must match real OpenProject accounts, or assignees, watchers and comments end up attributed to the wrong people or to no one. Compare Jira usernames and email addresses with your directory before the run, and decide how inactive or shared accounts are handled. If you rely on LDAP group synchronization or SSO, confirm those are licensed on your Enterprise plan.
Missing PostgreSQL extensions and versions
OpenProject supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. A database built without them, or on an older major version, fails at install or upgrade time. Verify the server version and extensions in the target environment with a test install before the migration window opens, and keep the database version in your change record.
Two systems during the parallel run
Teams that keep working in Jira while testing OpenProject create split records, duplicate issues and conflicting status updates. Set a freeze date for Jira edits, announce a single source of truth in writing, and set a short window in which only the migration team edits both systems. Agree who resolves conflicts and how remaining Jira items are closed or linked.
How the migration differs by starting point and organization size
If your Jira Data Center instance runs version 10.x or 11.x and is stable, you are in the group OpenProject's Jira Migrator is designed for. The migrator is in beta, and its documentation advises using it only in test setups, so treat the first run as a rehearsal on a copy of production data rather than a cutover.
- Scope of the import: Projects, versions, issues with history, comments, attachments, basic custom fields, users, statuses and issue types move across. Anything outside that list needs a separate plan.
- Test instance first: Stand up a non-production OpenProject and run the migrator against a recent Data Center export so you can measure mismatches before anyone works in the target.
- Custom fields and workflows: Only basic custom fields come across, so map complex field types, workflow transitions and permission schemes by hand.
- Enterprise features: LDAP group synchronization and single sign-on sit in paid Enterprise plans, so confirm your edition before you plan authentication.
- Sizing: Use the sizing guide tier that matches your user count, then add headroom for the test run.
Before committing, confirm with OpenProject that the migrator version you plan to use supports your exact Data Center release.
If your Jira Data Center runs a version older than 10.x, the OpenProject Jira Migrator does not support it. The practical route is to upgrade Jira Data Center to a supported version in a controlled environment first, verify the upgrade, and then run the migration from the upgraded copy. This is additional work that belongs in your plan, not a formality.
- Upgrade path: Confirm with Atlassian which upgrade steps apply to your instance, and test them on a clone before touching production.
- Plugins and apps: Older Data Center installs often depend on third-party apps that may not survive an upgrade. Inventory them early, because the migrator does not carry apps across.
- Data cleanup: Old instances usually carry stale projects, orphaned users and unused fields. Archive or remove them before export so the target is not built on legacy clutter.
- Timing: Atlassian has set dates for Data Center subscriptions and licenses, which you can review in its Ascend announcement. Factor those dates into your schedule.
- Fallback: Keep the original instance available until the upgraded copy has been verified.
Ask your Atlassian administrator or partner to confirm the exact upgrade sequence for your version, because the steps depend on your installation.
If your team uses Jira Cloud, the OpenProject Jira Migrator does not apply. It supports only Jira Data Center 10.x and 11.x, so you need a different extraction route. Start by understanding what Atlassian's own export covers, because it is not a complete copy of a Cloud project.
- Cloud backup scope: Atlassian's backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. It excludes automation rules, third-party apps and Assets.
- CSV and API routes: Plan a CSV or API-based extraction with a custom transformation step into OpenProject's import formats. Test it with a small project before scaling up.
- Rebuild list: Automation rules, app data and Assets must be recreated or replaced in OpenProject by hand.
- Attachments and history: Confirm how your chosen route handles attachments and issue history, since these are the items teams most often expect to carry over.
- Alternative target: If your priority is a Cloud-to-self-hosted move with an importer that works with Cloud, compare the route described on the Plane migration page.
Ask your implementation partner to document in writing which Cloud objects the chosen extraction route will carry and which will be rebuilt.
For a small group, the main differences are a lighter server, a simpler permission model and a faster rehearsal. OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, so a single modest server can run a small team. Whether you pay for an Enterprise plan depends on whether you need single sign-on or directory synchronization, not on size alone.
- Server sizing: The sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, which fits a single node for many small deployments.
- Community edition: The free Community edition covers work packages, Gantt charts, agile boards, time tracking and dashboards, so confirm whether you need anything from the Enterprise list.
- Enterprise decision: Pricing starts with the Basic tier per named user per month, with a minimum that applies to larger tiers, so a small team may not reach a paid tier at all.
- Migration effort: Smaller data sets make the test run quick, so you can repeat it several times before cutover.
- Operations: A single person may run the instance, so document backups and upgrades early.
Check the current OpenProject pricing page for the minimum user counts before you choose a tier.
For large user counts, the differences shift to infrastructure, identity and change management. The sizing guide suggests 8 cores and 8 GB RAM for about 500 users, and 16 cores and 16 GB RAM for about 1,500 users. Above that range, OpenProject's Corporate plan is priced on request, so the quote becomes a scoping conversation.
- Sizing tiers: Plan roughly 8 cores and 8 GB RAM for about 500 users, and 16 cores and 16 GB RAM for about 1,500 users, then validate under load.
- Scaling: Docker is the recommended installation, and Kubernetes with Helm charts supports horizontal scaling if you need it.
- Identity: Single sign-on and LDAP group synchronization are Enterprise features, so align them with your directory team early.
- Batch migration: Split large Jira estates into waves by project or business unit, rather than moving everything at once.
- Change management: Train project managers on the rebuilt workflows and permissions before each wave goes live.
Ask OpenProject for a written quote on the Corporate tier, and confirm the sizing with the vendor for your expected concurrency.
Questions buyers ask before moving Jira to OpenProject
What does it cost to move from Jira to OpenProject?
The software cost depends on the edition you choose, and the migration cost depends on your data and your team. OpenProject Community is free under GPL-3.0 and includes work packages, Gantt charts, agile boards and time tracking. Enterprise on-premises is priced per named user per month, with Basic at 5.95 euros and Professional at 10.95 euros, both 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. Migration effort is a one-time cost, and it rises with the number of projects, custom fields, workflows, permissions and attachments that must be rebuilt. Ask for a written scope that separates the migration work from the ongoing hosting and operations work.
How long does a Jira to OpenProject migration take?
No researched figure for migration duration is available, so confirm timing against your own scope. The main drivers are the number of projects, the volume of issue history and attachments, how many workflows and permission schemes you need to rebuild, and whether the Migrator is used in a test environment first. Because the Jira Migrator is in beta and the documentation advises using it only in test setups, plan a trial import, review the results and then repeat the process for production. Ask OpenProject and your implementation partner for a timeline that lists each phase as a separate deliverable.
Does the OpenProject Jira Migrator work with Jira Cloud?
No. The OpenProject Jira Migrator supports only Jira Data Center 10.x and 11.x and does not support Jira Cloud. If your Jira instance runs in Atlassian's cloud, you need a different route, such as exporting your data and loading it into OpenProject with a separate process. Atlassian's cloud backup covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes, but it does not cover automation rules, third-party apps or Assets. Confirm the export scope with Atlassian and the import approach with OpenProject before you commit to a plan.
Which OpenProject Enterprise plan includes the Jira Migrator and SSO?
OpenProject lists the Jira Migrator under its Enterprise plans from Basic upward, so Basic, Professional, Premium and Corporate include it. Single sign-on through SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization and custom branding, is also listed among Enterprise features. SCIM provisioning is in the paid Enterprise plans as well. Because plan contents can change, confirm the exact feature list for each tier on the OpenProject pricing page and in writing with OpenProject before you buy, especially if SSO is a condition of your identity policy.
What does my team need to provide for the migration?
Your team needs to supply access and decisions that only your organization can make. Expect to name a product owner who signs off on which projects, statuses, issue types and custom fields move, a Jira administrator who can export data and explain the existing configuration, and an infrastructure contact who provisions the servers, database and network access. Your security team should review user mapping, single sign-on settings and who can see migrated attachments. Budget time for these people, because the Migrator's supported scope means decisions about what to leave behind must be made before the import runs.
Can our own team migrate from Jira to OpenProject without a partner?
Yes, a capable internal team can run a self-hosted OpenProject installation and a test migration, provided it has Linux, PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and someone who understands both Jira and OpenProject data models. The documentation advises using the Migrator in test setups only while it is in beta, so the team must validate results carefully. A partner such as DeployOpen can plan, implement, customize, integrate, harden, back up, upgrade and document the deployment in your own infrastructure under a fixed-scope agreement. Compare the internal effort with a written scope before deciding.
What must be rebuilt by hand after the Jira import?
The Migrator covers projects, versions, issues with history, comments and attachments, basic custom fields, users, statuses and types, so other configuration needs manual work. Plan to rebuild:
- Workflows and transition rules that go beyond basic statuses
- Permission schemes and role assignments, reviewed against your access policy
- Automation rules, third-party app integrations and Assets-style data, which Jira's cloud backup also excludes
- Advanced custom fields and dashboards that the Migrator does not list
Confirm the exact mapping for each item with OpenProject before the production import.
What ongoing costs come after the migration to OpenProject?
After go-live, you pay for the servers or cloud capacity that run OpenProject, backups, monitoring, patching and upgrades, and any Enterprise subscription for the users who need paid features. 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, so hardware grows with user count. Releases such as 17.9.2, published on October 15, 2026, mean you should budget regular upgrade windows. Ask any partner for a retainer scope that covers upgrades, backup testing and support, and compare it with the internal staff time you would otherwise need.
When to start the migration before Data Center end of life
Start the planning now, because the Migrator's version limits can force a Jira upgrade before any data moves. Atlassian ends new Data Center subscriptions for new customers on March 30, 2026, stops licenses and expansions for existing customers after March 30, 2028, and on March 28, 2029 Data Center licenses expire and become read-only. Those dates set the outer limit, but the practical deadline is set by the OpenProject Jira Migrator, which supports only Jira Data Center 10.x and 11.x and is still in beta. If your instance runs an older Data Center line, you may need an upgrade to a supported version before you can run a test import, and that upgrade has its own change window and testing effort.
Confirm every date directly with Atlassian and in your own contract, because your renewal and audit calendar decides when you actually have to act. Ask your account team which dates apply to your license tier, whether a renewal or expansion after March 30, 2028 is possible, and what happens to read-only instances in your region. Then map your own calendar: the next renewal, the next internal or external license audit, budget approval cycles, and any freeze periods for regulated changes. Work backward from the earliest of those dates to find when a test migration, a parallel run and a cutover window must happen. Also check the Migrator's beta status against your risk appetite, since the documentation advises using it only in test setups.
How DeployOpen scopes, runs and supports the Jira to OpenProject migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that applies to an OpenProject deployment that receives Jira data. Engagements are fixed-scope, so the scope, deliverables and timelines for the migration are agreed in writing before any work starts.
How we scope
- Confirm the Jira source is Data Center 10.x or 11.x, since the beta migrator does not read Jira Cloud.
- Inventory projects, workflows, permission schemes, custom fields, automation rules and installed apps that the written scope must cover.
- List which Enterprise plan features the target needs, such as SSO, LDAP group synchronization or SCIM provisioning, and price them from the written scope.
How we build
- Deploy OpenProject with Docker or packages on a supported Linux distribution and PostgreSQL 16 or later in your environment.
- Run the beta Jira Migrator against a test instance first, then reconcile project counts, issue history, attachments and users.
- Rebuild workflows, statuses, types, roles and permissions in OpenProject, then test them with representative users before cutover.
How we hand over
- Document the target architecture, migration runbook, mapping decisions and the list of items rebuilt by hand.
- Deliver a written record of what migrated, what was skipped and what needs manual follow-up, with agreed acceptance checks.
- Walk administrators through backups, upgrades and user administration so your team can operate the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Plan OpenProject upgrades on your own schedule, starting from the release notes and a staging copy of your data.
- Confirm with your internal owners which post-migration support level fits your team before the written scope is signed.
