How do I get a test instance for a Cloud hosted JIRA instance?

[Garrett Lang]

How do I get a test instance (where I can copy production data into test when needed, and migrate things from test to production as needed), when our JIRA instance is deployed as a hosted JIRA cloud solution?

Thanks for any help you can provide.

[Nic Brough -Adaptavist-]

Cloud does not provide any test systems.  You have to buy a second instance and use that.

[Garrett Lang]

So if I buy a 10 user cloud instance of JIRA I can make it a copy of my production instance and migrate pieces of functionality/objects from test to prod?

[Nic Brough -Adaptavist-]

Yes and no. Moving "pieces of functionality" is not as easy as it sounds, so you'll be replicating stuff manually.

[Ignacio Pulgar]

By becoming an Atlassian Expert your organization will have to perform some tasks of a so-called onboarding program. On of those tasks consists of building a local instance of JIRA (among other Atlassian products) for a fictitious enterprise called Teams In Space.

While that local deployment was designed for demo purposes, it seems to be useful for testing punctual things that you wouldn't like to perform on your Production environment right ahead.

[Chander Inguva]

You need to have a valid license if your process of migrating things is frequent. Buy a 10 tier license and set up a cloud instance.

Other way is to spin up a Server edition of JIRA and use XML backup/restore to migrate data to and fro.

[Yuki Reid]

Note, if you have more than 10 users in your "prod" cloud instance, then you need to edit the entities.xml file from your backup jira-export.zip file and inactivate most of your users.  If you do not inactivate, the restore to your test instance will fail.  

Here's an example of how to edit the entities.xml from Atlassian support:

<User id="10001" directoryId="1" userName="sysadmin" lowerUserName="sysadmin" active="1" createdDate="2017-07-28 20:03:18.206" updatedDate="2017-07-28 20:03:18.206" firstName="System" lowerFirstName="system" lastName="Administrator" lowerLastName="administrator" displayName="System Administrator" lowerDisplayName="system administrator" emailAddress="sysadmin@localhost.localdomain" lowerEmailAddress="sysadmin@localhost.localdomain" credential="{PKCS5S2}R+BJAdk3nuzFdPM7xgH9f6dp1SvPCTa57Z4LZvMj4kKcpcBvOBoBsW5rMs/xoydN"/>

Note the active parameter is set to 1, so this user is active. The user would be inactive if the value was set to 0.
One workaround you can apply, is to use a text editor and run a find and replace in the entities file to find this entry active="1" createdDate=" and replace by active="0" createdDate=" - That would set all users in the file as inactive, so you wouldn't find any problems related to license seats. Once the import is finished you'll be able to access the user management and reactivate the users you need, up to 10 on each application.

Once you are done with editing, just re-zip the files and try the import process again.