What a Jira to OpenProject migration involves
Treat this as a data and process migration. Copying files does not carry over what makes a Jira instance work: issues with their history and links, custom fields, versions, users and groups, and the statuses and workflows teams have built over years. Each of those needs a mapping decision before any data moves. Start by inventorying projects, custom fields, workflow schemes and permission schemes, then decide which ones keep their meaning in OpenProject and which must be rebuilt by hand.
The OpenProject Jira Migrator supports Jira Data Center 10.x and 11.x. It does not support Jira Cloud, so a Cloud instance needs a different plan before it can be assessed. The migrator is in beta, and OpenProject's documentation advises using it only in test setups. Confirm the current status with OpenProject when your project starts, including whether production use is recommended and which object types are supported at that point. Let that answer set the cutover plan.
Most migrations start from one of three triggers. The first is a decision about Jira Data Center's end of support, which should be checked against Atlassian's current published dates for your version before any plan is built. The second is a licensing change that alters the cost of keeping Jira running for every user. The third is a move to on-premises open-source tooling, where the organization wants project data inside infrastructure it operates.
Short answer: most teams run the discovery and rebuild work with a partner or a mixed team, and keep ownership of process decisions in-house. Discovery covers inventory, field and status mapping, and test data selection. The rebuild covers workflows, permissions and reports that the migrator does not carry across today. Internal owners should decide which statuses, fields and roles the organization keeps, because those choices shape how people work after cutover.
What the migration work includes
The work runs in six packages, from source assessment to handover. The beta Jira Migrator covers only part of the scope, so much of the effort goes into mapping and manual rebuilds.
Source inventory and assessment
Confirm the source is Jira Data Center 10.x or 11.x, since the Migrator does not read Jira Cloud. Inventory projects, issue volumes, attachments, custom fields, workflows, permission schemes, sprints and issue links, then mark each item as imported, manual or out of scope. Deliverable: a source inventory and gap assessment.
OpenProject target instance setup
Build the OpenProject instance that will receive the data, using your chosen installation method and PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Size it from your user count using the sizing guide, and set edition, identity and access controls before any import runs. Deliverable: an installation record covering versions, configuration and access.
Migrator configuration and test runs
Configure the beta Jira Migrator against a test instance only, since the documentation advises against production use. Run repeated imports of representative projects, log every error and rerun after each fix so results stay repeatable. Deliverable: a test run log that records each run, its errors and the fix applied.
Status, type and custom field mapping
Map every Jira status, issue type and custom field to its OpenProject equivalent, including fields that need a new type or a different format. Agree each decision with the product owners before the final load, because a merged status or field is harder to undo once data has moved. Deliverable: a mapping document signed off by the business owners.
Manual rebuild of workflows and permissions
The Migrator's current scope does not include workflows or permissions, so these are rebuilt by hand in OpenProject. Translate each Jira transition and permission scheme into roles, status transitions and project memberships, then test them with real user accounts from each group. Deliverable: a permission matrix and a workflow specification.
Validation, cutover and handover
Reconcile counts, sampled issues, attachments, users and groups between Jira and OpenProject before any cutover decision. Then run the agreed cutover window, freeze writes in Jira, and confirm the final load against the reconciliation results. Deliverables: a reconciliation report, a cutover checklist and an operations runbook with open gaps listed by owner.
What drives cost and duration
This table lists the factors that change migration effort and duration, why each one matters for a Jira Data Center move to OpenProject, and how to reduce it before test runs begin.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Projects and issues | Every project and issue must be extracted, mapped and checked, so volume lengthens test runs and reconciliation. | Archive closed or stale projects before export and migrate only the history your teams need. |
| Custom fields | Imported fields need matching types and options in OpenProject, and each one adds mapping and validation work. | Retire unused fields in Jira and merge near-duplicates before the first test migration. |
| Workflows and permissions | The migrator does not yet import workflows or permissions, so these rules are rebuilt by hand in OpenProject. | Document current workflow and permission schemes and agree which rules are still needed before the build. |
| Sprints and issue links | Sprint assignments and issue relations are listed as coming soon, so sprint history and links need a manual or scripted approach. | Agree with stakeholders which links and sprint history must survive, and confirm current status in the migrator documentation. |
| Attachments volume | Large attachment sets increase transfer time and storage needs, and the transfer behavior must be confirmed for your version. | Measure attachment size per project, archive old files and confirm how they transfer during a test run. |
| Users and groups | Users and groups are imported, but account cleanup, group membership and named user counts shape validation and licensing. | Remove inactive accounts and duplicate groups in Jira, and confirm the named user count before requesting a quote. |
| Jira instances and merges | Merging several Jira Data Center instances means reconciling project keys, user identities and field definitions across them. | Map keys, identities and fields early and limit the merge to one agreed target structure. |
| Apps and integrations | Apps and automations sit outside the listed import scope, so each one needs a replacement, a manual rebuild or a retirement decision. | Inventory every app and automation rule, then retire those with no active use before the test runs. |
| OpenProject environments | The migrator is in beta and documented for test setups, so each added environment repeats runs and checks. | Complete full test runs in a test environment, then repeat only the final run in staging before production. |
Migration phases and outputs
The sequence moves Jira Data Center data into OpenProject in controlled test runs, so cutover happens only after reconciliation and user acceptance have passed.
Inventory Jira Data Center data
Confirm the Jira Data Center version is 10.x or 11.x, then list projects, issue volumes, attachments, custom fields, workflows, sprints, permission schemes, users and groups. The output is an inventory document that states which objects the Jira Migrator imports today, which need manual rebuild and which are out of scope.
Install and size the target OpenProject
Choose the installation method, size the server and PostgreSQL for the confirmed user count, and enable the required PostgreSQL extensions. The output is a non-production OpenProject instance with documented versions, sizing and backup settings, reviewed against the system requirements before any data is loaded.
Run a first test migration
Run the beta Jira Migrator against a copy of Jira Data Center data in a non-production setup, because the documentation advises test use only. The output is a first import log and a list of errors, skipped objects and fields that did not map, which feeds the mapping review.
Review mapping and document gaps
Compare Jira statuses, types, custom fields, versions and users with their OpenProject equivalents, and record every gap. The output is a signed mapping sheet and a gap register that lists relations, sprint assignments, workflows and permissions to rebuild by hand.
Rebuild relations, sprints, workflows and permissions
Recreate issue relations, sprint assignments, workflows and permissions in OpenProject according to the gap register, since these are not covered by the current import. The output is a configuration record that maps each rebuilt item back to its Jira source.
Repeat test runs with reconciliation
Run the import again after each fix, then reconcile counts and sampled records against Jira for projects, issues, attachments, users and groups. The output is a reconciliation report that shows each run is consistent and that remaining differences are accepted or fixed.
Complete user acceptance testing
Have named project owners and team leads check their projects in OpenProject against agreed scenarios, such as backlog views, boards and permission checks. The output is a signed acceptance record listing any open defects and their agreed resolution before cutover.
Cut over with a rollback plan and hypercare
Freeze Jira writes, run the final migration, reconcile again, and switch users over under a written rollback plan that defines how to return to Jira. Hypercare then covers issue triage and fixes for an agreed period. The output is a cutover record and a closed hypercare report. Ask for the phase timeline in the written scope.
What stays in-house and what goes to a partner
This table shows who usually owns each part of a Jira to OpenProject migration and which skills each part needs, so you can decide where your own staff should sit and where a partner adds the most value.
| Work area | Usual owner | Skills needed |
|---|---|---|
| Process and business decisions | Client, decided by leadership and project owners | Business process knowledge, decision authority, prioritization of which Jira practices to keep |
| Jira data inventory | Shared between client Jira administrators and the partner | Jira Data Center administration, reporting on projects, custom fields, workflows and users in scope |
| Migrator configuration and test runs | Usually the partner, with client review of results | OpenProject administration, Jira Data Center 10.x or 11.x access, familiarity with the beta Jira Migrator |
| Manual rebuild of workflows and permissions | Partner, working with client product owners | OpenProject workflow and role configuration, Jira workflow knowledge, product owner sign-off |
| User and group mapping | Client identity team with the partner | Identity administration, directory group design, OpenProject user and group import review |
| Infrastructure and PostgreSQL setup | Client infrastructure team, with partner guidance | Linux operations, PostgreSQL operations with pg_trgm, btree_gist and unaccent extensions, backup and restore |
| Cutover communication and training | Client change management and team leads, with partner materials | Change management, internal communications, end-user training, cutover runbook writing |
| Ongoing administration | Client, optionally covered by a support retainer | OpenProject administration, release upgrades, Linux and PostgreSQL operations, user lifecycle management |
What usually goes wrong
Most Jira to OpenProject migrations stall on a small set of predictable gaps between what the beta migrator imports and what teams assume it imports. Each card names the risk and the check that prevents it.
Running the beta migrator on production data
The OpenProject Jira Migrator is in beta, and the migration documentation advises using it only in test setups. Treat the first runs as rehearsals against a copy of your Jira Data Center instance, never the live data. Before any production run, agree in writing who accepts the test results and what sign-off the production run requires.
Assuming relations and sprints transfer
The migration documentation lists issue relations and sprint assignments as coming soon, so they will not arrive in a current run. Teams that rely on dependency links or sprint history will find gaps after cutover. Build a reconciliation checklist that counts relations and sprint assignments in Jira and records how each will be preserved, such as exporting them to a reference sheet or re-linking by hand.
Assuming workflows and permissions transfer
Workflows and permissions are listed for later support, so the migrator does not rebuild them for you. Status transitions and project role access may look correct in test data but differ in production. Require a rebuilt-permissions sign-off from each project owner, comparing Jira roles and groups with the OpenProject roles you configure before users log in.
Attachment and user identity mismatches
Users, groups and attachments must map cleanly to OpenProject accounts, or work packages show the wrong owners and broken files. Matching usually fails on email addresses, duplicate accounts or deactivated users in Jira. Review the user mapping table and confirm how attachment storage and file size limits will handle historic files before the trial run is accepted.
Unmapped custom field types
Custom fields are imported, but field types that do not map to an OpenProject equivalent need a decision before the run. Unmapped fields can be dropped, converted to text or handled by rebuilding them as custom fields after import. List every custom field type in the Jira source, mark its mapping result in the test report, and agree a treatment for each one with the business owner.
Jira Cloud sources
The migrator imports from Jira Data Center 10.x and 11.x and does not support Jira Cloud. If your source is Jira Cloud, the migration path described here does not apply without a different approach. Confirm the exact Jira product and version in the source environment at scoping, because this decision determines the whole plan.
Cutover without a Jira edit freeze
If people keep editing Jira during the final import, changes made after the snapshot never reach OpenProject. Define a freeze window for Jira edits, take a frozen source snapshot, run the final import from that snapshot, then reconcile counts of projects, issues and users against the snapshot before reopening OpenProject to teams.
How the work differs by starting point
The OpenProject Jira Migrator reads from Jira Data Center 10.x. The main task is checking that the data you need falls within the objects the migrator imports today.
- Confirm the exact 10.x patch level against the current migrator documentation before extraction.
- Inventory projects, issues, versions, custom fields, users, groups, statuses and types that you plan to bring across.
- Plan manual rebuilds for sprint assignments and issue relations, which are listed as coming soon.
- Rebuild workflows and permissions in OpenProject, since the documentation places these in later releases.
- Run a test import into a non-production instance first, because the migrator is in beta.
The migrator documentation lists 11.x as a supported source alongside 10.x, so the importable object set is the same. What changes is the verification you complete before relying on the tool.
- Confirm the exact 11.x release is named in the current documentation, because support statements can change during the beta.
- Apply the same gap list as for 10.x, covering relations, sprints, workflows and permissions.
- Map custom fields from marketplace apps to OpenProject field types, since these often need a decision on retention.
- Ask OpenProject to confirm any 11.x-specific data limits in writing before the test plan is signed off.
- Record the source version in the migration plan so that test and production runs use the same source.
Many workflows and apps increase effort, because the migrator does not yet import workflows or permissions. The more configuration you have, the more of it you will rebuild by hand in OpenProject.
- Count workflows, screens, permission schemes and apps per project to size the manual rebuild.
- Map each custom field to an OpenProject field type and decide which fields to retire.
- Document app-driven behavior, such as automation rules, and confirm with OpenProject how it will be replaced.
- Plan permission design as a separate workstream, because permissions are listed for a later migrator release.
- Decide which history to keep and which inactive projects to archive rather than migrate.
The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x only, so a Jira Cloud source falls outside the tool's supported scope. Planning needs a different route, and you should confirm that route with OpenProject before scheduling any work.
- Confirm the migration route in writing with OpenProject, including whether any supported path exists for your Cloud site.
- Expect a different extraction method that will need its own test and validation cycle.
- Confirm which exports your Atlassian site administrators can produce and what each export contains.
- Repeat the scope inventory, because issue history and attachments may arrive through a different path.
- Do not assume Data Center findings carry over to a Cloud source without testing them.
When the migration runs inside an air-gapped or segregated network, every component must arrive through an approved transfer path. Plan the software, the migrator and the database requirements before the work starts.
- Confirm how packages or images enter the network, using your approved media or internal mirror process.
- Check PostgreSQL 16 or later and the pg_trgm, btree_gist and unaccent extensions can be installed without internet access.
- Confirm the migrator and its dependencies are available from your internal repository before the cutover window.
- Keep Jira export data inside the segregated zone, and agree how files are moved, encrypted and deleted.
- Test the offline path in a staging segment, since any undocumented network call would block the run.
What you need to provide
Before any migration work starts, you need to supply access, decisions and named people. The beta Jira Migrator reads from Jira Data Center 10.x or 11.x, so the first input is read access to that instance, or a database or export copy that the team can use for test runs. Confirm with your Jira administrator which copy is permitted and how it is refreshed. Jira Cloud is not a supported source for this tool, so check your deployment type early.
Decisions and owners. Name a business owner for each Jira project in scope. That person decides what moves, what is archived and what is dropped, and approves the mapping of statuses, types and custom fields. Because the migrator does not yet move issue relations, sprint assignments, workflows or permissions, these owners also need to agree how that information will be recreated or kept as reference in the archive.
Target environment. Provide the infrastructure for OpenProject, a PostgreSQL instance that meets the version and extension requirements, and the database access your team needs for reconciliation. Identify who provisions user accounts and groups, since users and groups are imported and must match your identity source. Also name the contact who approves the Jira change freeze window, the period in which no new issues or edits are made in the source during the final migration.
Finally, appoint one sign-off owner who accepts the reconciliation results and approves cutover. You keep the Jira licence and ownership of all Jira data throughout the project. DeployOpen works on copies and in your target environment, and nothing is deleted from Jira as part of this work unless you instruct it in writing.
Frequently asked questions
Can we migrate from Jira Cloud to OpenProject with the migrator?
No. The OpenProject Jira Migrator reads from Jira Data Center 10.x and 11.x only. If your source is Jira Cloud, confirm with OpenProject which migration route, if any, applies before you set a date. Ask DeployOpen to verify your Jira version and deployment type as the first scoping step, since this decides whether the migrator can be used at all.
Is the OpenProject Jira Migrator production ready?
No. The migrator is in beta, and the OpenProject documentation advises using it only in test setups. Confirm its current status with OpenProject before you plan a cutover, because beta behavior can change between releases. Run test imports on a copy of your Jira data, compare imported counts and field values with the source, and treat production import as a separate decision that depends on the vendor's status and your test results.
What does the Jira Migrator leave out today?
The migrator imports projects, issues, versions, custom fields, users, groups, statuses and types. Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are listed for a later release. Plan to rebuild workflows, permission settings and sprint planning by hand, and check the OpenProject documentation for the current list before you finalize scope.
What does a Jira to OpenProject migration cost?
Cost has five components: the OpenProject edition, the infrastructure you run it on, the migration work itself, the manual rebuild of workflows and permissions, and your staff time for testing and cutover. The Community edition has no license fee, while Enterprise on-premises is priced per named user per month on OpenProject's published pricing page. DeployOpen does not publish prices. A quote follows from written scope, so ask it to separate one-time work from recurring items such as support and upgrades, state its data volume assumptions, and list what your team must provide.
How long does a Jira to OpenProject migration take?
Duration depends on scope, not on a standard timeline. The main drivers are the number of projects and issues, how many custom fields and workflow states you have, how much manual rebuild is needed for workflows and permissions, how many test runs your change process requires, and how quickly your team reviews results. Ask for a schedule in the written scope with test cycles and the cutover window shown separately, and confirm how the plan handles changes to the migrator if its beta status shifts.
Can our own team migrate, and what must we provide?
Yes. An internal team with Jira administration skills, Linux administration skills for the OpenProject host, and time for the manual rebuild can run the migration. To work with DeployOpen instead, provide read access to the Jira Data Center instance, a test environment where OpenProject and the migrator can run, named owners for projects and approvals, a cutover window, and decisions on which legacy data to keep. Ask any partner to confirm these items in writing.
How DeployOpen runs this migration
DeployOpen scopes, builds and hands over the move from Jira Data Center to OpenProject inside your own infrastructure, with the beta Jira Migrator treated as a test-stage tool until its limits are confirmed for your data. Engagements run on a written, fixed scope, and ongoing support is available as a retainer.
How we scope
- Confirm your Jira Data Center version, which must be 10.x or 11.x, since the Jira Migrator does not import from Jira Cloud.
- Inventory projects, issues, versions, custom fields, users, groups, statuses and types, and list which items need manual rebuilding.
- Record in the written scope which items are out of reach today, such as issue relations, sprint assignments, workflows and permissions.
How we build
- Stand up the target OpenProject instance and PostgreSQL database in your environment, with the required extensions in place.
- Run repeated test migrations against copies of your data, comparing counts and field mappings after each run.
- Rebuild workflows, permissions and sprint or relation data manually where the migrator does not yet cover them.
How we hand over
- Document the mapping decisions, test results, known gaps and the manual steps your team must repeat at cutover.
- Plan the cutover sequence with a freeze window, final data load, validation checklist and a rollback path.
- Deliver a written handover covering admin tasks, user onboarding and the open items you own after go-live.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after cutover, scoped separately from the migration.
- Plan OpenProject upgrades within its release cycle, confirming each target version against the release notes before applying it.
- Review the migration record with your team once users have worked in the new system for an agreed period.
