Skip to main content
search icon

Restoring data to another Jira instance: In-depth overview

Rewind
Updated

This article explains Rewind’s Restore to another instance functionality, which allows you to take backup data from one Jira instance and restore or copy it into another Jira instance.

Covered in this article:

Overview


Restore to another instance allows you to take backup data from one Jira instance and restore or copy it into another Jira instance. This can be useful for disaster recovery, setting up test environments, or promoting configuration changes between environments.

Rewind offers two ways to restore Jira data to another instance. Each has different purposes and ideal use cases:

Full Restore (Everything)

  • Disaster recovery to a new, empty instance
  • Seeding a sandbox with a full copy of production
  • Point-in-time audit snapshots

Configuration-Only Restore

  • Promote sandbox configuration changes to production
  • Apply tested workflows, fields, and screens to a live instance
  • Use a sandbox as a configuration “blueprint” for new environments

Restore options you’ll see in Rewind

The options you see when restoring to another instance depend on the Service Type you selected when you installed the Rewind app into the environment that will be receiving the data:

  • Destination instance (clean, empty): You can choose Everything (full restore) or Configuration only.
  • Backup instance (already actively backed up with Rewind): Configuration-only restores are the only option supported when restoring from a different Jira instance into an existing backup instance.

What we mean by service type

When you first install Rewind to a Jira environment, you choose whether the connection should be treated as a backup instance or a destination instance:

  • A destination instance can only be used to restore data into — it does not include backup functionality.
  • A backup instance is a Jira instance where Rewind is already performing daily backups.

Full restore vs. configuration-only restore


Feature comparison

The table below compares Full Restore and Configuration-Only Restore, showing the types of data each can restore and which destination instances they support.

Feature / Scenario Full Restore (Everything) Configuration-Only Restore
Restores Jira content (projects, issues, attachments) Yes No
Restores Jira configuration settings Yes Yes
Destination can be an existing instance with data No Yes
Destination can be a new, empty instance Yes Yes
Deletes data in destination No No


What each restore type includes

Below is a breakdown of the Jira items supported by each restore type. Some items, like issues and attachments, are only available with Full Restore, while both include core configuration elements such as workflows, screens, and project roles.

Full Restore (Everything)

  • Project
  • Project Components
  • Project Roles
  • Boards
  • Issues
  • Issue Attachments
  • Issue Comments
  • Issue Fields
  • Issue Links
  • Issue Link Types
  • Issue Priorities
  • Issue Properties
  • Issue Types
  • Issue Type Schemes
  • Issue Type Screen Schemes
  • Epics
  • Filters
  • Screens
  • Screen Tabs
  • Screen Tab Fields
  • Screen Schemes
  • Status
  • Workflows
  • Workflow Transition Rules
  • Workflow Schemes
  • Workflow Scheme Project Associations
  • Workflow Transition Properties

Configuration-Only Restore

  • Project
  • Project Components
  • Project Roles
  • —
  • —
  • —
  • —
  • Issue Fields
  • —
  • Issue Link Types
  • Issue Priorities
  • Issue Properties
  • Issue Types
  • Issue Type Schemes
  • Issue Type Screen Schemes
  • —
  • Filters
  • Screens
  • Screen Tabs
  • Screen Tab Fields
  • Screen Schemes
  • Status
  • Workflows
  • Workflow Transition Rules
  • Workflow Schemes
  • Workflow Scheme Project Associations
  • Workflow Transition Properties

Limitations


Some Jira data types and features are not supported when restoring to another instance. The list below shows components that are currently excluded from both full restores and configuration-only restores, unless otherwise noted:

  • Jira Work Management resources
  • Jira Service Management resources
  • Jira Product Discovery resources
  • Project avatars, categories, properties, property keys
  • Project features
  • Project versions (fixVersions)
  • Dashboards
  • Sprints
  • Actions, advanced roadmaps, automations/rules, conditions
  • Issue resolutions
  • Issue security schemes
  • Issue property keys
  • Issue field configurations & schemes
  • Custom field options
  • Workflow scheme drafts
  • Permission schemes, notification schemes
  • Users and groups*
  • Filters with user/group permissions*
  • Forms, portal, portal groups, triggers

*Users and groups — must already exist in the destination; they are not copied during restore.
*Filters with user/group permissions — these permission types are removed. The filter remains, but permissions revert to a supported type (such as project-level or private).

Before you get started


To help your restore go smoothly, here are a few important things to know before you begin:

  • Destination should be mostly empty: We recommend starting with no existing projects. If a project with the same name or key already exists, it will be skipped — no changes will be made to fix conflicts.
  • Existing items won’t be overwritten: If the destination already has Workflow statuses, Issue link types, Issue types, Project Roles, or Workflows with the same names as in your backup, these items will be skipped. No existing data will be deleted or updated during restore.
  • Whole restore only: Restoring to another instance always copies everything supported for the restore type you choose (either all supported data for a full restore, or all supported configuration items for a configuration-only restore). It isn’t possible to restore only selected items.
  • User accounts must exist first: Any referenced users (e.g., issue assignees, reporters, component leads) must already be in the destination instance. If they don’t exist, those fields will be left blank in restored items.
     

Item-specific behavior to be aware of

Issue fields
  • If the same issue field already exists in the destination instance, it will be duplicated.
  • When creating a new Jira instance for a restore, Jira automatically adds a default project and some default custom fields. These default fields will also be restored, which may result in duplicates.
  • We cannot copy issue types with options like multi-select lists due to Jira API limitations.
Issues
  • “Team” and “fixVersions” (project versions) cannot be set during a restore.
  • If an issue has a reporter or assignee that does not exist in the destination instance, it will still be restored, but the user reference will be removed.
  • Issues in team-managed projects that use only custom issue types may fail to restore, as Jira’s API does not allow us to programmatically create these types in team-managed projects.
  • Only one transition per issue is supported during restore (e.g., we can move an issue from “To Do” to “Done,” but not through multiple statuses).
Issue types
  • Only hierarchy levels 0 and -1 can be created.
  • If the “Epic” type has been deleted or a custom hierarchy is in place, it cannot be recreated during restore.
  • Custom avatars for issue types are not restored; default Jira avatars will be applied instead.
  • If the Sub-Task issue type is disabled, it cannot be re-enabled or recreated via the API.
Projects
  • Project names and keys must be unique. If either already exists in the destination, the project will be skipped, and no issues will be restored to it.
  • Certain project types (e.g., Jira Product Discovery, some team-managed projects, Jira Service Management) aren’t supported.
Filters
  • Filters that use user/group permissions may not be restored. If restored, those permissions will be removed.
Screens
  • If a restored screen does not use the “General” tab, the layout may appear different in the destination instance because Jira automatically creates this tab by default.
Workflows
  • Workflows with screens that have required fields might encounter issues during transitions, especially if the field complexity is high. If you run into issues with this, please contact our support team at help@rewind.com.

How to restore to another instance


When you’re ready to start your restore, use the links below to follow step-by-step instructions for your chosen method — whether you’re performing a Full Restore or a Configuration-Only Restore.

How to perform a full restore →

How to perform a configuration-only restore →

FAQ

Can I restore to an existing instance?

Yes, for configuration-only restores. Full restores require a new, empty destination.

Can I back up a destination instance?

Not automatically. If you want to start backups on a destination instance after restoring data to it, please contact us. We can help convert the destination into a backup instance.

Will I be billed for destination instances?

No, destination instances used for restores are not billed as additional backups.

What happens after I start a restore?

Configuration-only: Updates changed items, creates missing ones — no delet.
Full restore: Creates all supported items in a new, empty destination instance.
You’ll receive an email summary with successful, skipped, and failed items.

 

Need help?

If you have questions or need assistance, reach out to help@rewind.com or submit a request. We’re here to help!

Related articles

Need to talk to us?

Submit a request for our Customer Support or Sales team below and we'll get back to you as soon as possible!

Submit a request Contact sales