Move a whole Jira and Confluence site to orboto

Added in v0.231.0 Admin -> Import -> Move a whole Jira and Confluence site moves the projects of a Jira Cloud site into orboto in one run. Unlike the single-project Jira import, it maps every person once for the whole site and keeps the links between projects: an epic in one project with stories in another, a bug in one project that blocks work in the next.

Added in v0.232.0 The same run also moves the Confluence Cloud spaces of the site into docs spaces, with links between tickets and pages in both directions: see Move Confluence into orboto docs.

You need the admin:import permission, the site URL (https://<your-site>.atlassian.net), the email of an Atlassian account and an API token of that account. The account sees what the run can import: give it Browse projects on every project you want to move, Browse users and groups for the people list, and View voters and watchers for watchers. A permission the account lacks does not stop the run: Jira answers 403, orboto leaves that data out and lists it as a warning (identity for people, groups and watchers, other for the rest). Only a token Jira refuses, or a 403 on the account check when you connect, stops the run.

How a run goes

The same run is reachable without the browser:

orboto import jira-site start --url https://acme.atlassian.net --email me@example.com --token-stdin --wait < token.txt
orboto import jira-site plan <run> --out plan.json      # edit it, then:
orboto import jira-site plan <run> --file plan.json
orboto import jira-site apply <run> --wait
orboto import jira-site report <run> --markdown --out report.md

The REST routes are under /admin/import/jira-site/runs. An OAuth connection (for example an MCP client signed in through the browser) cannot start a run, send credentials, save a plan, apply or resume: those send a stored secret to a site you name or decide which accounts are created. Use the CLI or an API key.

Merging into an existing orboto project

By default every Jira project becomes a new, empty orboto project. When an orboto project with the same key already holds tickets that did not come from this site, the run would merge into it, and a merge is never silent:

• Projects shows the merge with every collision: the Jira key, the orboto ticket that already holds that number, and the number the issue gets instead.
• Start the import stays disabled until you tick Merge this Jira project into KEY and type the project key, for each merging project.
• The API answers 409 (errors.admin_import.jira_site_merge_not_confirmed) with the same list until the project in the plan carries "confirmMerge": true and "confirmProjectKey": "KEY"; the CLI prints the list on plan and on a refused apply.

The existing tickets stay as they are. An issue whose number is free keeps it; one whose number is taken gets the next number after the highest Jira number of the project, and the run lists it as a ticket_number warning. A project with the same key but no tickets, or one an earlier run of this site created, is no merge. Every imported ticket keeps its Jira key and issue id as its source reference (see Source keys on imported tickets).

Old keys of a renamed project

When an orboto project was renamed away from a key, its old ticket keys keep opening its tickets. A Jira project with that key would take them over, whether the run creates the project or an orboto project (even an empty one) holds the key now: each imported ticket that gets one of those keys replaces the old key, and old links to it then open the imported ticket. Projects lists such a project with the number of old keys, how many this run replaces, up to 20 of them and the renamed project. Start the import stays disabled until you tick Let the new project KEY take over these old keys and type the key; the API answers 409 (errors.admin_import.jira_site_alias_takeover_not_confirmed) until the plan project carries "confirmAliasTakeover": true and "confirmProjectKey": "KEY". After a takeover, new tickets of the project are numbered above every old key, so the old keys the run did not replace keep opening the renamed project's tickets. The migration report lists how many old keys each project took over and how many are left.

People

Each Atlassian account becomes one orboto user for every project of the site:

• Matched by email - Jira shows the account's email and an orboto user has it. Mapped by default.
• Matched by display name - Jira hides the email (the person's profile visibility is private), but exactly one orboto user has the same name. You must confirm the match before the run starts.
• No match - a placeholder keeps the attribution: a user without a sign-in whose name is the Jira display name. You can also create a user (with the email Jira shows, or one you enter for a hidden email), map the account to any user by hand, or skip it.

Accounts that appear only in issues (people who left, apps) get the choice you set for "Accounts found only in issues": a placeholder or skip. A later run of the same site starts from the mapping you made, so nobody is mapped twice.

What becomes what

Added in v0.232.0 Descriptions, comments, worklog notes and rich-text custom fields convert with their links, tables, headings, code, panels, mentions, emoji, status lozenges and dates, and a link to another issue of the site opens the imported ticket, also when it got another key. What orboto has no equivalent for keeps its text and shows as a content warning per issue. The full list is in What converts from Jira; to repair a site import made before 0.232.0, delete the imported project and import it again.

Every ticket ends with a Jira fields section that lists the custom field values, resolution, environment, further versions and sprints, the Jira key and every Jira link, so nothing is lost even where orboto has no field for it. The Sprint field always becomes the milestone; an Epic Link field becomes the parent.

Runs, limits and rate limits

• Resumable. The run works in short steps and remembers where it stopped, per project. A crash or a deploy continues by itself; a run that failed continues with Resume the run. Nothing is imported twice: every Jira issue is written together with the record of its source id.
• A second run of the same site imports only issues that are new since the first run, and resolves links the first run left open because their target was not imported yet. Changes made in Jira to issues that are already in orboto do not transfer.
• One run per site. While a run of a site discovers, imports or waits for Jira, a second start or apply for that site answers 409 (errors.admin_import.jira_site_run_active); cancel the running one or let it end. Cancelling stops the run after the issue it is writing.
• Rate limits. orboto sends at most jira_site_requests_per_second requests per second and follows Jira's Retry-After. A short wait happens in place; when Jira's hourly quota is used up, the run shows Waiting for Jira and continues at the time Jira named.
• Limits (Admin -> Backup -> Import and sync limits):

One attachment is at most 50 MiB, like an upload. Every answer of Jira is read with a size cap.

• Credentials. The token is sealed with the instance key, kept for at most 24 hours, never written into a background job, a backup or the report, and deleted when the run ends. If it expired before the run finished, the run asks for it again and continues where it stopped.

The migration report

Download the migration report (or orboto import jira-site report <run> --markdown) gives a Markdown file with the counts per project, the people mapping, every custom field with where it went and how many issues had a value, the warnings by kind, the links that stayed unresolved and the list below. The warnings themselves are listed on the result page and through /admin/import/jira-site/runs/<run>/warnings.

What does not transfer

• Jira Service Management portals, queues, SLAs and request types
• Wiki pages of Atlassian products other than Confluence; Confluence spaces move with the run, see Move Confluence into orboto docs
• Workflow transitions, conditions, validators and post functions (statuses and their categories transfer)
• Permission schemes, issue security schemes and project roles
• Groups and group membership (listed in the discovery; people become project members)
• Board columns, swimlanes, quick filters and saved filters
• Dashboards, gadgets and reports
• Automation rules
• Issue history (changelog), votes and remote links
• Changes in Jira to issues that a run already imported
• Custom fields as fields of their own: their values are kept as described above
• Jira Data Center specifics beyond what the Jira Cloud REST API v3 returns