The plugin allows you to migrate a whole server, with several options: one or more projects, basic data such as types of issues, custom fields, issue / s range, with or without links, comments, attachments, worklogs ... incrementally, about a project exists or not, you can modify existing records or not ... with respect to users, you can migrate them (with their respective attributes such as email, etc.) or assume a default user (as indicated by the options ). It can work from one JIRA to another JIRA (the origin must always be server, the destination can be Server or Cloud):

Features

Export metadata as project definition, issue types, users (or use a default user)
Create custom fields
Export project component and versions
Export issues for all projects, for a selected project, for an issue or a range of issues, with or without comments and worklogs
Upload issues attachments
Link issues
Update existing information if selected
The migration process runs in a separate thread that can be canceled and restarted to complete the process incrementally if necessary. You can see the progress in a console in detail (verbose option) or summarized.
The errors that could occur are shown in the error console (red) directly visible to quickly solve the issue and resume the process.
As much as when launching the process as at the end it shows information about the selected options and the time consumed in the process

Suggested migration steps

Previous to run the migration, you should do the following in your JIRA 2 (destination):

Create manually metadata that can not be created with the JIRA REST API. With metadata I mean data other than issues, which are referenced by issues. Not all of this data can be created through web services. When creating an issue, it is necessary to some extent that there are workflow data, screens, fields, custom field configuration, and permissions for it to be successful. This data is maintained in JIRA with the option to manage the project.
Priorities
Resolutions
Configure Custom fields (see also custom fields options). CUSTOM FIELDS MUST HAVE AN UNIQUE NAME
Screen must be include the following fields: components, environment, versions, duedate, reporter, fixVersions, assignee, timetracking, labels, and needed custom fields. From version 1.1.0 is autoconfigured by the plugin
Issue type schemes used by the projects must include issue types referenced by imported issues. From version 1.1.0 is autoconfigured by the plugin (only server targets)
Permission schemes (grants for create/update/transition/worklog/comment)
Workflows with a Done terminal status for resolved issues
Configure users (inactive users will be migrated as admin, see also default user option

After migration, as final step, you should complete each project issue's schemes as needed

Issuetypes are not case sensitive
Migrated issues can have different issue key in destination depending on the order of creation and the initial numvalue of each project key
Only custom fields of built-in types are migrated
All resolved issues are closed using a given transition (Done) from the initial status that sets the Resolution. After migration you can discard this transition
Only issue field's not hidden in project field configuration are migrated
Migration JIRA user need to be administrator with Browse grant in all source projects, and with Create/Edit issues, Modify Reporter, etc. permissions on destination migrated projects
Option export issues always inserts and/or updates (does not omit records)
File attachments are located in your Jira Home, folder /import/attachments. You can copy the attachments in a folder for each issue manually or with the update existing information option make the plugin download them for you

Installation

Download Ballon for Jira from Atlassian Marketplace

Configuration files

If for some reason you need the origin and destination servers to be different (or adjust other connection options), you can use two configuration files (jira1.yml and jira2.yml respectively) that should be in the JIRA HOME folder of the server where this plugin was installed. Using these files is optional

Example jira2.yml

:username: user_email
:password: atlassian_token
:site: other_destination_host
:context_path: '/jira'
:auth_type: :basic
:use_ssl: true

Important

You should create Atlassian API token and configure yml file/s with user and passwords

Examples

Configuration

Within the jira add-on option, you will see two options in the IMPROVEKIT section: Configure Balloon and Launch Balloon, to configure and execute the plugin process respectively.

The configuration consists in completing the following screen (click to enlarge) with data of the connection to the destination server (see configuration files above if you want to overwrite this information)

Launching process

From the option Launch Balloon you can launch a complete migration process or a step of it as planned (normally it is first to migrate metadata, configure the fields and then proceed to migrate issues and their options).

In order to launch or cancel the process, the administrator password must be enter

Process control

The thrown process can be canceled at any time. Then you can resume the migration: if you were migrating metadata, select the update existing information option so that it does not duplicate the information.
If you were migrating issues, idem, but you can also return to a particular issue, or range of issues (enter the last migrated, or the next if you know the issue key and proceed from there with the rest of the issues).

Log and error console

The migration process displays information in the standard output/error (with more or less information according to the verbose option). To view them, press the refresh button

When the process finishes, press the Done button to release the resources

Privacy Policy

Data security and privacy policy

End User License Agreement

EULA

Support

If you need support on the plugin, please send an email to improvekit@gmail.com and your order will receive a response and solution. Improvekit is formed by specialists in systems with more than 20 years of experience in software engineering and in Jira's employment every day and develops its applications following a mature methodology to provide its clients with the highest quality and services.

Good flights

Browser not supported