Importing from Jira

Moving a Jira Server, Data Center or Cloud site into Alba Ticket without losing anything.

Alba Ticket imports a complete Jira backup: projects, users, groups, roles, workflows, custom fields, tickets with their comments, attachments, links, history and work logs, boards and sprints, and Jira Service Desk data. Nothing is dropped: every imported record keeps its source id and the full original payload, and anything Alba cannot represent directly is stored as-is and reported for review. Work logs become time entries on their tickets (see Time), each with its history; where Tempo Timesheets was installed, its work attributes and accounts are kept with each entry's original record, a Tempo billable figure marks the entry billable, and the analysis says how many work logs carry Tempo data.

What you need

  • A Jira backup (System, Backup manager). It contains entities.xml and, on Jira Software and Service Desk, activeobjects.xml.
  • For a Jira Server or Data Center, a ZIP of the attachments directory from the Jira home (data/attachments), if you want the files themselves. A Cloud backup made with attachments carries them inside the ZIP instead.

Both are uploaded from Administration, Jira import, straight from your browser to the workspace's storage, so nothing has to be placed on the server; an upload waits there for a day and is then removed. The backup is analysed as soon as it is uploaded, and the import is started from it.

Jira Cloud

A Jira Cloud backup (Settings, System, Backup manager, with attachments included if you want them) is the same file, and the import recognises it by itself: the analysis report says which kind of backup it read, and the import source is recorded as Jira Cloud.

What Cloud does differently:

  • People are named by Atlassian account id, and an email address is only in the backup when the person's profile shows it. Every reference (reporter, assignee, comment author, history) resolves through the account id, so nothing is misattributed. A person who already has an account here is matched by email; anyone else gets a username made from their email address or their display name, and can be activated the same way as any imported user.
  • Every parent is a parent. Cloud records epic links, sub-tasks and the parent of any issue type the same way, and the import sets the parent accordingly.
  • Cloud's own fields (story point estimate, the Plans parent and start and end dates, teams, first response date) are typed like their Server equivalents. Anything else that Cloud adds is stored as JSON and reported, like any unknown field.
  • Attachments inside the backup are unpacked when the attachments stage runs, in the temporary directory the import works in on the server and removed afterwards. That directory can be large; a backup that includes attachments needs room for them twice while the import runs.

Step 1: analyse

Under Administration, Jira import, start an analysis of the backup. It reads the whole export and writes nothing. The report shows what is inside: projects with issue counts, issue types, statuses, users, custom fields and how each maps to Alba, workflows with any rules Alba cannot evaluate, boards, sprints and Service Desk data. Use it to decide whether to proceed and what to review afterwards.

Step 2: dry run

Start an import with dry run ticked. The whole import runs inside a transaction that is rolled back at the end, so you see the counts and every review item without changing anything.

Step 3: import

Run the import for real. It works in stages, in order: vocabularies, users, roles, workflows, projects, custom fields, tickets, attachments, boards, service desk, verification. Each stage records what it created, matched, left unchanged or skipped. The import is checkpointed and idempotent: if it stops, run it again and it continues where it left off; running it again later changes nothing.

Choose whether imported users are activated. Activated users can log in straight away (through single sign-on or a login link) and history stays attributed to them. Users you leave inactive keep their history too and can be activated later.

Verification

The last stage compares counts in the export with what was imported and reports differences. Review items list everything that needs a decision: fields stored as JSON, workflow rules Alba cannot run, attachments whose file was missing, and so on.

After the import

  • Projects keep their keys and ticket numbers, so HELP-42 is still HELP-42, and new tickets continue the numbering.
  • Ticket bodies keep their Jira wiki markup and are converted to Markdown only when someone edits them.
  • Boards, columns and sprints work as they did. Ranks are preserved.
  • Helpdesk projects keep request types, queues, organisations, customers, internal notes, SLA state, approvals and satisfaction ratings.
  • Field definitions that Alba unpacked into data of its own are archived so their JSON copies remain but are not shown twice.