Why teams move Jira and Confluence in one project
Moving Jira and Confluence together is possible, but it needs a deliberate sequence, because issues and pages reference each other and a break in either system breaks the links between them. Internal platform teams usually run this work, often with an implementation partner for the parts they have not done before, such as SSO wiring, data mapping and cutover. The urgency comes from Atlassian's own timeline: Data Center subscriptions stop for new customers on March 30, 2026, expansions and new licenses for existing customers stop after March 30, 2028, and Data Center licenses become read-only on March 28, 2029. Teams on Jira Cloud face a different driver, usually pricing or data residency, but the same question applies: both products must land on infrastructure the organization controls.
Effort and risk depend less on the number of users than on how tightly the two products are used together. Confirm with your Atlassian admins how many Jira projects link to Confluence pages, which Confluence spaces hold the runbooks and requirements that issues cite, and which automation rules, apps and Assets data exist, since the Jira Cloud backup does not cover automation rules, third-party apps or Assets. Ask any vendor or partner to size the work from that inventory rather than from a headcount estimate. Identity is the other dependency: plan one identity provider that both the project tracker and the wiki trust, so users do not hold separate accounts during the transition.
The decision that shapes everything else is the order. Most teams move the wiki and the tracker in an agreed sequence, then rebuild cross-links by mapping page identifiers and issue keys before anyone relies on them, and they run both systems in parallel for a defined period. Treat each importer's documented limits as a planning input, not a footnote. Once the sequence, identity design and link inventory are agreed in writing, the remaining questions become concrete and can be quoted.
Which Jira and Confluence capabilities map cleanly to OpenProject, Plane and XWiki
This table maps the main Jira and Confluence capabilities to OpenProject, Plane, and XWiki or Docmost. Read clean as a direct equivalent, needs rework as possible with configuration or a different workflow, and gap as something to plan around or replace. Automation rules and Assets are the items most likely to need confirmation and manual rebuilding.
| Capability | OpenProject | Plane and XWiki or Docmost |
|---|---|---|
| Issue tracking and work items | Clean: work packages with types, statuses, comments and attachments, and the Jira Migrator for Data Center 10.x and 11.x (beta). | Clean: Plane work items with states, priorities and comments. Jira importer covers Cloud and Data Center on Plane Cloud or Commercial Edition. |
| Boards and sprints or cycles | Clean: agile boards are in Community. Sprints map to sprint-style boards, so confirm how your sprint history translates. | Needs rework: Jira sprints map to Plane cycles. Confirm how open sprints and carried-over issues are handled after import. |
| Roadmaps and Gantt planning | Needs rework: Gantt charts are in Community. Cross-project portfolio views sit in paid Enterprise plans, so confirm the tier you need. | Needs rework: Plane modules and cycles cover grouping and timelines, but expect a different planning model than Jira advanced roadmaps. |
| Permissions and workflows | Needs rework: roles and project permissions must be rebuilt. Workflows and transitions are not carried over by the beta migrator, so plan a manual rebuild. | Needs rework: project roles and state flows must be recreated. Confirm role mapping against your Jira permission schemes before cutover. |
| Page content and page history | Gap for wiki pages in OpenProject, which is a work package and project tool. Use XWiki or Docmost for documentation. | Clean: XWiki pages hold rich content and version history. Confirm how Confluence macros and page trees convert with the XWiki migration service. |
| Attachments | Clean on work packages, with attachments imported by the beta migrator. Confirm size limits in your environment. | Needs rework: Confluence Migrator Pro keeps page history but not attachment history, so decide whether attachment history must be preserved. |
| Links between issues and pages | Needs rework: link work packages to wiki pages by URL, and confirm how links survive the move from Confluence. | Needs rework: links from Jira issues to Confluence pages must be rewritten after both migrations. Plan a link map before cutover. |
| Single sign-on across both | Needs rework: SAML and OIDC are Enterprise features, and LDAP group synchronization is also Enterprise. Confirm the tier before you design identity. | Needs rework: Plane SAML and OIDC start at the Pro plan. XWiki SSO apps come with XWiki Pro, so confirm the OIDC route with your identity team. |
| Jira Cloud automation rules | Gap: automation rules are not in the migrator scope. Inventory every rule and rebuild it by hand or in a workflow tool. | Gap: automation rules are not migrated. Export and document each rule, then rebuild it in your target platform. |
| Assets (Jira Cloud) | Gap: Assets object data is not covered by backup for cloud. Confirm export options with Atlassian and plan a custom data model. | Gap: Assets schemas and objects need a separate export and a target database or wiki structure. Confirm before scoping. |
How issue-to-page links survive the move
Links between Jira issues and Confluence pages will break unless someone rewrites them after both systems are loaded. Jira work items are referenced by key, such as a project prefix and number, and Confluence pages are referenced by space key and page title or by a numeric page ID in the URL. Neither platform's import will guarantee that these references resolve to the new issue and page addresses in OpenProject or Plane and in XWiki or Docmost. Plan a mapping table before the first test load: one row per source key or URL, the destination identifier, and a status column for each rewrite pass.
The mapping table is built from the source exports. Record every Jira issue key, every Confluence page ID and title, and the new identifiers assigned by each target. Then run the rewrite in a fixed order: issues first, pages second, and a final pass over both to catch cross-references in macros, embedded issue lists and attachment links. Confirm with each vendor how their importer handles original keys, whether it keeps source IDs in a field you can query, and whether it preserves Confluence page IDs or assigns new ones. OpenProject's Jira Migrator documentation and Plane's importer documentation describe what they import, but they do not settle how cross-references are carried across, so test this against your own sample data.
The risk is most visible in runbooks, incident procedures and specifications, where a broken link can send an operator to the wrong record during an outage. Treat those documents as a priority list: check them first, sign off their links with the document owner, and keep a redirect or a dated note with the old key where the new target differs. Plan for the rewrite to need manual review, and agree in your statement of work who checks links, who signs off, and what happens to links that cannot be resolved automatically.
What data can leave Jira and Confluence through documented paths
Each route moves a different slice of Jira and Confluence, and none of them moves everything. The cards below set out what each documented path carries, what it leaves behind and what your team must rebuild or verify before the old instance goes read-only.
Jira Cloud backup contents
Jira Cloud's backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. It does not cover automation rules, third-party apps or Assets, so those need to be exported or rebuilt separately. Check the backup against a sample project before you rely on it as the source for a move, and confirm which of your projects use apps or Assets.
Automation rules stay behind
Automation rules are not part of the Jira Cloud backup, so every trigger, condition and scheduled action has to be listed from the Jira instance and rebuilt in the target tool. Teams often find these rules only after cutover, when a status change no longer sends a notification or a ticket no longer moves on its own. Inventory the rules by project before the first migration run.
OpenProject Jira Migrator limits
OpenProject's Jira Migrator imports projects, versions, issues with history, comments, attachments, basic custom fields, users, statuses and types. It is in beta, supports only Jira Data Center 10.x and 11.x and does not support Jira Cloud. The documentation advises using it only in test setups, so confirm your Jira version first and plan a production move on a different route.
Plane's Jira and Confluence importers
Plane provides importers for Jira and Confluence, available on Plane Cloud and on the self-hosted Commercial Edition. The Jira importer supports Jira Cloud as well as Jira Server and Data Center, which makes it the broader route for Jira Cloud teams. Ask the vendor which Jira objects each importer maps, since sprints, custom fields and link types may map differently than in Jira.
XWiki Confluence Migrator Pro scope
Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata. It keeps page history but not attachment history, so teams that need an audit trail of document versions should export those records separately. The trial is limited to 30 pages per migration, so test a representative space before you buy a full run.
Permissions and links to rebuild
Migrators carry users, groups and permissions in part, but project roles, space restrictions and cross-links between issues and pages depend on the target mapping. Confirm that issue keys and page URLs resolve in the new system, and rebuild single sign-on and group sync in the target before users log in. Record every link type you depend on so you can test each one after the move.
Single sign-on across OpenProject or Plane and XWiki
OpenProject lists single sign-on as an Enterprise feature. The supported protocols named on its pricing page are SAML, OIDC, CAS, Kerberos and Okta, and LDAP group synchronization is also listed under Enterprise. The Community edition is free, but it does not include these options, so a shared login depends on buying an Enterprise on-premises plan. Plan the identity path with that cost in mind.
- Edition check: Confirm with OpenProject which Enterprise plan includes the SSO protocol your identity provider uses before you size the user count.
- Protocol choice: Compare SAML, OIDC and Kerberos against what your identity provider already exposes to other applications.
- Group sync: LDAP group synchronization is a separate Enterprise feature, so confirm whether group membership drives project roles in your design.
- Administration: Keep the OpenProject administrator account as a documented local fallback, and confirm how it works when the identity provider is unavailable.
- Configuration owner: Assign one person to maintain the SSO settings, redirect URLs and certificates through upgrades.
Before cutover, confirm the exact SSO protocol and plan with OpenProject in writing and test one login from start to finish.
On self-hosted Plane, SAML and OIDC are available from the Pro plan upward, while LDAP support and API-enabled audit logs are listed as Enterprise features. Plane's Community Edition is AGPL-3.0 and matches the Free tier feature set. Moving to a paid plan requires switching from Community to the Commercial Edition with a license key, so the identity decision and the edition decision are the same decision.
- Pro tier identity: SAML and OIDC are the protocols to plan around for most identity providers on Pro and above.
- LDAP path: If your directory is LDAP only, confirm that the Enterprise tier covers your setup before choosing Plane for both tools.
- Edition switch: Plan the move from Community to Commercial as a step with its own change record, since it changes the install and the license key.
- Seat counting: Paid seats count users with paid roles, so align SSO group assignments with the roles you intend to pay for.
- Audit logs: If you need API-enabled audit logs for compliance evidence, treat them as an Enterprise requirement.
Confirm the exact SSO and LDAP entitlements for the plan you select with Plane, and test a login on the edition you will run in production.
XWiki Standard is free and open source under LGPL 2.1. Its standard authentication options can be extended with the community xwiki-contrib/oidc extension, which is the route to OIDC for a free install. XWiki Pro adds Active Directory and Azure Active Directory SSO applications on top of XWiki with SAS support. Which path fits depends on whether you need vendor support and on the directory you already run.
- OIDC extension: The xwiki-contrib/oidc extension is community maintained, so review its release state and test it on the XWiki version you deploy.
- Pro applications: XWiki Pro lists Active Directory and Azure Active Directory SSO applications, which fit Microsoft directory environments.
- Support scope: Ask XWiki SAS whether SSO configuration falls under the support plan you buy, since Standard users rely on community resources for the extension.
- Version pinning: Match the extension version to the XWiki line you run, whether stable or LTS, and retest after each upgrade.
- Group mapping: Decide how directory groups map to XWiki groups and rights so Confluence permissions carry over cleanly.
Confirm with XWiki SAS which SSO path its support covers, and test the OIDC extension or Pro connector on the exact XWiki version you plan to deploy.
A single login across OpenProject or Plane and XWiki works only when both products trust the same identity provider through protocols they each support on your chosen edition. The most common gap is a directory that only speaks LDAP, which is an Enterprise path in Plane and an Enterprise path in OpenProject, while XWiki's free route runs through OIDC. Map each product to its identity path before you pick the identity provider.
- Shared provider: Choose one identity provider that offers SAML or OIDC, since that is the common denominator across the three products.
- Gap list: Record which product needs a paid edition or a community extension to reach that provider.
- Session behavior: Test how session timeouts and logouts behave across both tools, because each one manages its own session.
- Identity fallback: Keep a documented local administrator path for each product in case the provider fails.
- Single test flow: Run one scripted login with a test user across both tools before cutover, and record the result.
Before cutover, confirm each product's identity path on its chosen edition in writing, then run and record one shared login flow.
Single sign-on is usually the last setting to finish in a Jira and Confluence move, and it is also the setting auditors ask about first. Treat identity configuration as part of the migration plan, with its own test cases, owners and evidence. The goal is to show that access follows the identity provider and that offboarding removes access in both tools.
- Test cases: Cover first login, group-based role assignment, a denied user, and removal of a leaver in both OpenProject or Plane and XWiki.
- Change records: Keep the configuration, certificate and redirect URL changes in your change management system.
- Access review: Export the user and group state from each product for your periodic access review.
- Upgrade regression: Repeat the login test after each platform upgrade, because SSO settings can change with versions.
- Pilot group: Start with a small group of users before moving the full company, and keep the fallback path ready during the pilot.
Before go-live, confirm the evidence format your auditors expect and make sure each login test is repeatable and recorded.
Migration order for Jira and Confluence in parallel
This sequence moves Jira projects and Confluence spaces in controlled waves, so each team keeps working in a system it trusts while the links, identities and history are checked before the old tools are closed.
Inventory issues, pages and their links
Your Atlassian administrators and project leads list every Jira project, workflow, custom field, automation rule and app in use, and every Confluence space with its page count, attachments, permissions and macros that reference Jira issues. Atlassian's cloud backup excludes automation rules, third-party apps and Assets, so record those separately before any export. The output is an issue and page inventory with an owner and a target tool for each item. It is done when every project and space has a named owner and a decision on whether it moves, archives or retires.
Build the link map between issues and pages
Before importing anything, list the places where Confluence pages point to Jira issue keys and where issues point to wiki pages, including Jira macros, smart links and URLs in descriptions. Decide how each link will resolve after cutover, either by rewriting it to the new tool or by keeping a redirect or archive reference. The output is a link map in a spreadsheet, reviewed by one person from the wiki side and one from the project side. It is done when every high-traffic link has a planned target and the exceptions are written down.
Stand up test instances and set identity
Your platform team installs OpenProject or Plane and XWiki or Docmost in a test environment inside your own infrastructure, following the vendor's system requirements and supported database versions. Connect both to one identity provider over SAML or OIDC, and confirm which SSO and directory features your chosen editions include. The output is a working test stack with test users who sign in once, and a note of any edition gate that blocks SSO or group sync. It is done when a test user can reach both tools through the same login and group membership maps correctly.
Run a pilot import and sign off the result
Import one representative Jira project and a small Confluence space into the test instances, using the vendor importer and checking its version support against your Jira deployment. Compare counts of issues, comments, attachments, users, statuses and page history with the source, then walk the pilot with its owners to check permissions and links. Note what did not move, such as Jira-only fields or attachment history, and decide how to handle each gap. The output is a signed-off pilot set and a list of manual rebuild tasks. It is done when the pilot owners accept the result in writing.
Run both systems in parallel
Keep the Atlassian and replacement systems live for a defined set of teams, with new work entered in the target tool for pilot teams while the rest stay in Jira and Confluence. Use the link map to check cross-references on each sync, and log every discrepancy in a single defect list with an owner. Your identity team confirms that accounts, groups and permissions stay aligned across both sides. The output is a parallel-run log and a defect list with resolution status. It is done when the defect list has no open items that block the next wave.
Cut over projects and spaces in waves
Move projects and spaces in groups, starting with low-risk content and finishing with the most linked projects, using the same import and link steps proven in the pilot. For each wave, freeze edits in the source for the affected items, run a final import, verify counts and links, and then switch the team's bookmarks and integrations. The output is a cutover checklist per wave, signed by the project owner and the platform lead. It is done when each wave passes its checklist and the source is set to read-only for migrated items.
Decommission with read-only archives
Once all waves pass, export a final archive from Jira and Confluence, including the items that cloud backup excludes, and store it in an access-controlled location that your retention policy covers. Remove integrations, revoke service accounts and set the Atlassian sites to read-only where your contract and retention rules allow. Confirm the archive can be opened and searched by a named reviewer before any site is closed. The output is a retained archive with an index and a decommission record. It is done when your compliance owner accepts the archive and the record in writing.
What drives the cost and duration of a combined move
This table lists the factors that change the effort and recurring spend of moving Jira and Confluence together, with how to keep each one down. Read it before asking for a quote, since the same scope can cost very different amounts depending on source version, data volume and identity design.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Source product and version | Jira Server or Data Center 10.x and 11.x can use OpenProject's beta Jira Migrator, while Jira Cloud needs another route, and Confluence Server and Cloud export differently. | Confirm the exact version and deployment type first, then choose the migration path before scoping work. |
| Number of projects and spaces | Each project needs its own mapping of workflows, permissions and page trees, so counts multiply review and testing time. | Archive inactive projects and spaces, and migrate only what current teams still use. |
| Attachment volume | Large attachment sets slow transfers, increase storage on both new platforms and lengthen validation. Confluence Migrator Pro keeps page history but not attachment history. | Measure attachment size per project, and decide with owners which historical files stay in the archive. |
| Custom fields and issue types | OpenProject's migrator covers only basic custom fields, so complex fields must be rebuilt by hand in Plane or OpenProject. | Inventory fields in use, remove unused ones and map the rest to a short list before migration. |
| Automation rules and apps | Jira Cloud backup excludes automation rules and third-party apps, so each rule must be rebuilt or replaced. | List rules and apps with their owners, then retire the ones no longer needed. |
| Links between issues and pages | Keeping references from Jira issues to Confluence pages means mapping identifiers across two systems and testing every link. | Agree on one link pattern and test a sample of cross-product references early. |
| Single sign-on design | SSO across OpenProject, Plane and XWiki may need Enterprise tiers or the xwiki-contrib OIDC extension, and each identity provider integration adds setup and testing. | Pick one identity provider, confirm which features each edition supports, and test sign-in for each product. |
| Hosting and operations | Self-hosted services, databases, object storage and backups recur every month and need staff time for patching and upgrades. | Size hosting from the vendor sizing guides, and reuse shared database and backup tooling where possible. |
| Support and XWiki Pro tiers | Paid support, Enterprise plans and XWiki Pro tiers (Starter, Basic, Business, Enterprise) recur per user or per plan, while XWiki's Confluence Migrator Pro is priced from 2000 EUR according to XWiki Store. | Compare community and paid support, and match the XWiki tier to real user counts rather than headcount. |
Comparing the combined cost with Atlassian Cloud
Build the comparison on a per-user, per-year basis for the same headcount, because the self-hosted side has no single price. Start with your current Jira and Confluence costs from your own Atlassian contract, including Cloud subscriptions, any add-ons and the tiers that apply to your user count. Atlassian's figures are not in this page's source set, so take them from your order form or renewal quote rather than from a list price. Then add the self-hosted side as separate lines: the work management tool, the wiki, hosting, staff time and support.
On the work management side, the supplied prices are OpenProject Enterprise on-premises at 5.95 euros (Basic), 10.95 euros (Professional) and 15.95 euros (Premium) per named user per month, with Professional requiring a 25-user minimum and Premium a 100-user minimum, according to the OpenProject pricing page. Plane's Pro plan is listed at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month on the Plane pricing page. Note that the Community editions of both products have no license fee, and that SSO, LDAP and SCIM sit in paid tiers, so price the tier that gives you the sign-on model you need, not the cheapest line.
For the wiki, XWiki Standard is free and open source, while XWiki Pro and support subscriptions are priced by user band, with cloud and on-premises pricing stated as the same. Ask XWiki SAS for a written quote and confirm whether consulting, migration and training are one-time or recurring. Migration of Confluence spaces with Confluence Migrator Pro is priced from 2000 EUR according to the XWiki Store listing. Add hosting for the database, object storage and application servers, plus the staff time to upgrade and back up both platforms, which recurs for the life of the system.
What usually goes wrong when both products move at once
Moving Jira and Confluence in the same program multiplies the places where data, identity and history can break. The cards below cover the failures that recur most often when issues, pages, users and permissions cross from Atlassian into OpenProject or Plane and XWiki or Docmost, with a prevention step for each.
Broken issue-to-page links
Jira issues point to Confluence pages through smart links and macros, and those references do not survive a move unless the target pages are migrated first and their new URLs are mapped. Build a table of old and new addresses for every space and project before the import runs. After the cutover, sample a set of linked issues and confirm each link resolves to the migrated page rather than an empty or wrong target.
Automation rules and Assets lost
Jira Cloud backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes, but it does not include automation rules, third-party apps or Assets. Anything that ran automatically in Jira will silently stop after the move. Inventory every rule, app and Assets object type, then decide which ones to rebuild in the target tool, retire, or replace with a workflow automation service you run yourself.
Importer version limits
The OpenProject Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, not Jira Cloud. Plane's Jira importer supports Jira Cloud as well as Server and Data Center, but the two importers cover different objects and have different gaps. Confirm the exact source version and deployment type before choosing a route, and plan a test migration on a copy of the data, since the OpenProject documentation advises beta use only in test setups.
SSO gaps between platforms
Single sign-on often works for the first product and fails for the second. On OpenProject, SSO (SAML, OIDC, CAS, Kerberos and Okta) sits in Enterprise plans, while on self-hosted Plane, SAML and OIDC start at the Pro plan. The wiki side needs its own configuration, for example the xwiki-contrib OIDC extension for XWiki. Map the identity provider, group claims and session lifetimes for each application before cutover, and test a user who holds roles in both products.
Attachment history missing
Confluence Migrator Pro keeps page history but not attachment history, so earlier versions of uploaded files do not come across. Jira attachments imported into OpenProject arrive with their issues, but version lineage of documents referenced from both systems can still be lost. Decide which attachment versions matter for audit or contract purposes, export them separately to archive storage you control, and record where each current file now lives.
Users and permissions mismatched
Users, groups and permission schemes do not map one to one. A Confluence space permission and a Jira project role can grant different rights to the same person, and OpenProject and Plane organize roles differently again. Export the user directory and group memberships first, reconcile inactive accounts and duplicate identities, and compare effective access per project and space after import rather than trusting the migrated role names.
Parallel editing splits the record
If teams keep working in Jira and Confluence during the move, edits made after the export start will not appear in the new system, and two versions of the same plan will drift apart. Set a freeze window for each space and project, announce it, and set the old instances to read-only once the final export is taken. Keep the source instance available for reference until the reconciliation sign-off is complete.
How the move differs by starting point
This is the only starting point where OpenProject's Jira Migrator applies, and the migrator is still in beta. Its documentation advises use only in test setups, so treat the first import as a rehearsal. Confluence Data Center has no matching OpenProject path in the supplied facts, so the wiki needs its own route.
- Jira import scope: The migrator brings projects, versions, issues with history, comments, attachments, basic custom fields, users, statuses and types. Workflows, permissions and advanced fields need to be rebuilt by hand.
- Enterprise license: The migrator sits under OpenProject Enterprise plans from Basic upward, so test and production imports both need a paid plan.
- Plane as the other route: Plane's Jira importer supports Data Center, and Plane's importers also cover Confluence, so one vendor could handle both products.
- Confluence path: Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions and attachments. It keeps page history but not attachment history, and it is priced from 2000 EUR.
Check which Data Center minor version you run, because the migrator accepts only 10.x and 11.x.
Cloud starting points cannot use OpenProject's Jira Migrator, which does not support Jira Cloud. Plane's importer supports Jira Cloud, as described in the Plane Jira importer documentation. Atlassian's cloud backup also defines what leaves the tenant, so the gap list comes first.
- Backup gaps: Jira Cloud backup covers work items, boards, sprints, comments, users, workflows and schemes. It excludes automation rules, third-party apps and Assets.
- Rebuild inventory: Automation rules, app data and Assets must be documented and rebuilt, because the supplied importer facts do not show them moving.
- OpenProject route: Since the Jira Migrator does not read Cloud, confirm with OpenProject which export route it supports for Jira Cloud before you commit to a timeline.
- Confluence Cloud: Confirm in writing whether Confluence Migrator Pro and Plane's Confluence importer accept your Cloud site and version.
- Overlap period: Keep the Atlassian subscription active until the cutover is verified, so the old data stays available for comparison.
Before you cancel anything, list every app and automation your team relies on and check each one against the backup exclusions.
Atlassian ended support for all server products, including Jira Server, on February 15, 2024. An instance still running Server or Confluence Server no longer receives vendor security fixes, so the move out carries a security urgency that the Data Center and Cloud tabs do not share. The importer options also differ from the other starting points.
- Support status: Treat a current Server instance as unpatched while you plan, and restrict its network exposure until cutover.
- Plane importer: Plane's Jira importer names Jira Server directly among its supported sources, which makes it the clearest documented route for Server data.
- OpenProject migrator: Its documented scope is Data Center 10.x and 11.x, so a Server source needs a different route. Confirm the options with OpenProject in writing.
- Confluence Server: Verify the source-version scope of the Confluence tooling before you buy, since version limits decide whether the wiki moves in the same wave.
- Cutover order: Stand up the target platform and identity first, move the most exposed instance first, and freeze writes on the old system during the final sync.
Ask each importer vendor whether it accepts your exact Server version and patch level.
Air-gapped and EU residency requirements shape the deployment before any import begins. Self-hosting keeps data inside your environment, but each platform packages its software and dependencies differently, and that affects how updates and importers reach a restricted network.
- Packaging: OpenProject publishes packages and Docker images, Plane offers a proprietary Airgapped edition, and Redmine is GPL v2 software on Ruby on Rails. Confirm how security updates reach a disconnected network for each product.
- Importers offline: Plane's importer is available on the self-hosted Commercial Edition, so an enclosed network should run it there rather than through Plane Cloud. Confirm that the Airgapped build includes the importer.
- Dependencies: Plane needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage. OpenProject requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Each dependency must be mirrored into the enclave.
- EU residency: A cloud-hosted importer may process data outside your control, so ask each vendor where processing happens and which external calls the product makes at install and at runtime.
- Identity: SSO on OpenProject is an Enterprise feature, and Plane's SAML and OIDC require the Pro plan or above.
Request a written list of external network calls from each vendor before you approve the design.
Questions buyers ask before moving Jira and Confluence
What drives the cost of moving Jira and Confluence to self-hosted open source?
The cost is driven by four components: the software licence, the infrastructure, the migration work and the people who run the platform afterward. OpenProject's Community edition is free, but its SSO, LDAP group synchronization and Jira Migrator sit in paid Enterprise plans, which OpenProject prices per named user per month. Plane's self-hosted Community edition is AGPL-3.0, while paid self-hosted features require the Commercial Edition with a license key. XWiki Standard is free, while XWiki Pro and support are priced by user tier. Ask each vendor for a quote based on your user count, and ask what is one-time and what recurs each year.
How long does it take to move Jira and Confluence together?
The duration depends on the number of projects, the volume of attachments and history, the complexity of workflows and permissions, how many Confluence spaces and pages exist, and how many integrations must be rebuilt. No single duration applies to every estate. Ask your implementation partner for a timeline in a written scope, and ask the tool vendors which migration paths apply to your Jira deployment type, since importer support varies by version and by Cloud or Data Center.
What does the client's team need to provide during the migration?
Expect the client to supply named business owners who can confirm which projects, spaces and users must move, plus administrators who can export data and approve permission mappings. You will also need infrastructure owners for hosting, database and object storage, and a security contact for SSO and access reviews. Confirm these roles with your partner before work starts, because decisions on workflows, custom fields and permissions take time from people outside IT.
Can our internal staff run OpenProject, Plane and XWiki themselves?
Yes, many teams run these platforms internally, but it requires people who can operate PostgreSQL, container or Kubernetes platforms, backups, upgrades and identity integration. OpenProject supports Docker installation and Helm charts for scaling, and Plane documents Docker Compose and Kubernetes with Helm. XWiki publishes official Docker images for MySQL, PostgreSQL and MariaDB. Assess whether your team has these skills and capacity, and if not, consider a fixed-scope implementation with ongoing support retainers.
Which importers work for Jira Cloud and which work for Data Center?
OpenProject's Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x. It does not support Jira Cloud, and its documentation advises use only in test setups. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center, but it is available on Plane Cloud and on the self-hosted Commercial Edition. For Confluence, XWiki SAS offers Confluence Migrator Pro, which keeps page history but not attachment history. Confirm current version support with each vendor before you choose a route.
How are links between Jira issues and Confluence pages handled after migration?
Links are not preserved automatically by every importer, so plan for them explicitly. Map each Jira issue key and Confluence page URL to its new location, then rewrite references in issue descriptions and wiki pages. Plane's importers and XWiki's migration tooling each cover different objects, so test a sample of cross-links in a staging environment. Ask your partner to document which link types survive, which need manual repair and who signs off on the results.
Can single sign-on cover both OpenProject or Plane and XWiki?
Both can be configured for single sign-on, but the features depend on edition. OpenProject lists SAML, OIDC, CAS, Kerberos and Okta under its Enterprise features. On self-hosted Plane, SAML and OIDC are available on Pro and above, and LDAP support is an Enterprise feature. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, and the community xwiki-contrib OIDC extension exists on GitHub. Confirm that your identity provider works with each product and edition before you commit to a design.
When should we start the migration given the Data Center dates?
Atlassian ends new Data Center subscriptions for new customers on March 30, 2026, stops licences and expansions for existing customers after March 30, 2028, and makes Data Center licences expire and become read-only on March 28, 2029. Bitbucket and Bamboo Data Center are the exceptions. Start with an inventory of Jira and Confluence spaces, integrations and compliance evidence, then run a pilot with one project and one space. Confirm the dates and any changes directly with Atlassian, since its timeline is the authoritative source.
How DeployOpen scopes and runs the combined migration
DeployOpen plans, implements, integrates, hardens, backs up and documents the target stack inside your own infrastructure, and the scope is fixed in writing before any work begins. For a combined Jira and Confluence move, that means one written statement covering the chosen project tool (OpenProject or Plane), the wiki (XWiki or Docmost), the hosting target in your cloud account, data center or air-gapped network, the identity integration, the migration waves and the handover documents. Most engagements are fixed-scope, so the deliverables and timelines are agreed with you on paper. Ongoing support, upgrades and continuous testing are available as retainers once the cutover is complete, which matters because both platforms ship new releases on their own cycles and both need patching after go-live.
The scoping conversation should settle the decisions that drive most of the work. Confirm which Jira deployment you run, because the OpenProject Jira Migrator covers only Jira Data Center 10.x and 11.x and is in beta, while Plane's importer also covers Jira Cloud. Confirm which Confluence content must survive, and whether links from issues to pages need to resolve after the move. Decide where single sign-on terminates and which users need access to each system. Confirm which features need paid editions, such as SSO, LDAP synchronization and SCIM provisioning on OpenProject Enterprise, or SAML, OIDC and LDAP on self-hosted Plane. Each of these choices changes the migration plan and the license line in your quote.
DeployOpen does not issue audit reports, attestations or certifications. Our work prepares systems, access controls, backup evidence and documentation so that your compliance team and an independent auditor or certification body can assess them. Ask any provider, including us, to show which controls are configured and which evidence is produced, and ask your auditor which of those they will accept.
