Migrate a small 10 user local server instance to Atlassian Cloud host.

Question

Current setup:

We run a VM with Ubuntu16 running Postgres9.6 as the database server.

And another VM Ubuntu16 running: Jira 8.6.1

Jira has 65 Projects: 32 active, 33 are archived.

And another VM running Ubuntu16 for Confluence 6.15.2

We are running Atlassian Jira/Conf on a 10 user $10 PA licence.

Our plan is to migrate to test an Atlassian cloud instance/setup.

I have a few question about this.

I have signed up for an Atlassian.com account (for a basic 10 user plan (2Gb data), hopefully it’s all we need for testing) and setup our name in there and have logged in to: admin.atlassian.com

No users apart from the creator, have been made.

We have installed the cloud migration tools into our local Jira & Confluence instances and worked through (not all the way) so as to familiarise myself with the layout and working of the migration tools. Some things are not clear.

We use tempo budget (cost-tracker is a cloud sort of equivalent) will the data be excluded automatically or do we have to do something in the migration tool?

Plan A is to migrate data from Jira and Confluence into this pre-prod setup using the migration tools provided by Atlassian.

Question: Can test migration be done individually? or should it be both?

If both, which one first? Confluence or Jira? or does it matter?

Question: Can we access concurrently the pre-prod setup without impacting our existing local server setup? I’m thing the answer is yes but please respond…

In this scenario I envisage users (from the test migration) being able to access data in the cloud just like our local instance, and keeping in mind all the time that this is a test. We want to check out any operating differences between a local server instance and a cloud-based instance.

Then, if/when successful, and we decide to move ahead to a production Atlassian hosted Jira/Confluence setup, do we 1/ remove that test migrated data (then, how?) or 2/ re-migrate over the top of it?

Earl McCutcheon · Answer

Hi @Joe F ,

For Jira, there is not an explicit "read-only" mode, but you can do it manually.

You can create a permission scheme that only allows "browse project" Project-level permission and then apply it to all projects.

Also, we have the following feature requests for both cloud and server respectively to track interest in adding this in as a feature make sure to add your vote:

* https://jira.atlassian.com/browse/JRACLOUD-1924
* https://jira.atlassian.com/browse/JRASERVER-1924

Regards,
Earl

Joe F · Answer

HI Earl, I have followed instructions and been in touch with Atlassian and tempo support. We have test migrated both Jira & Confluence to the cloud instance now and both appear good.

Tempo data is difficult to migrate requiring REST API knowledge etc etc which is not in my skill set.

There appears to be very limited support from tempo to assist in any way other than pointing to documentation which assumes a level of knowledge that is higher than mine anyway, or to a support partner to do the work for one.

So, to cover this, we want to keep our old local instances running and in read only mode (except for 1-2 admins) and have migrated just the bare Jira and Confluence installs, jira will have tempo cost-tracker, timesheet and planner added in our cloud instance and we'll start with some kind of total to date, and if needed can get back to our prev instances for historical reasons.

I have found some instructions to put Confluence (our release is: 6.15.2) into this read only state: https://confluence.atlassian.com/confkb/how-to-make-confluence-read-only-311920317.html

But have no luck finding a fairly simple way to to the same for our local Jira (8.6.1) instance. Can you offer any guidance/links/help for this? The permissions scheme looks complicated but I guess if I really had to, I could.

Earl McCutcheon · Answer

Hello @Joe F ,

For starters as a referance point I'm just adding in the links to the documentation for the general recommendations and a comparison to the the Migration assistant tool vs the XML import:

* Migrate from server to cloud
* Use Jira Site Import to migrate from server to cloud
* Use the Jira Cloud Migration Assistant to migrate from server to cloud

The main takeaway applies to your first question about add-ons, as the Migration assistant will move only the project data, users, and groups from Cloud to Server, but will not do anything with add-on data or customizations from those add-ons (i.e. workflow customizations like a post function, or Dashboards that you have set up with custom gadgets)  where the Site Import option will do a full site migrations (projects, users, groups, app data, etc...), basically a copy of the source to the destination that overwrites the destination, and can copy over any add-on specific tasks as long as the add-on has a cloud compatible version of the add-on.

Also the Site import is going to be a bit more complex as it will require more troubleshooting around any customizations that my be in place on the server install for incompatibilities that need to be adjusted before migrating, such as the noted "tempo budget" app you have on server would need a uninstall before migrating as there is not a cloud version available at this time for that app, and none of the data other than custom field data would transfer over (custom field data will stay on the issue for historical referance to values entered but the fields will not be connected to an apps function that used those fields previously)  However if there is a cloud compatible version of an app, you install the app cloud side and everything should link up in the migration, but it is  always recommended to reach out to the app vendor to double check if there are any additional required steps as each third party app could have a special requirement for a migration.

Overall though I highly recomend contacting our Migration Support team, and they can take a look at your individual set up and give you specific recommendations for your setup to get you all sorted out, check out this article for the contact info:

* How to contact migration support

And from your description it sounds like you should mark Planning for the "Where are you in your Migration?" section as you are partially testing but still researching the optimization points.  Also make sure to mention this thread in the contact form as well to for a referance point to the questions you have already asked.

next looking a the rest of your questions:

Question: Can test migration be done individually? or should it be both?

If both, which one first? Confluence or Jira? or does it matter?

I would recomend doing the test the same way you plan on doing the final migration to work out any kinks, and test with a Jira + Confluence migration,  But i also recomend staging it out, i.e. do the finalized Jira portion of the migration, verify it looks good then move on to the confluence stage, then do the UAT once everything is running fully configured.

Question: Can we access concurrently the pre-prod setup without impacting our existing local server setup? I’m thing the answer is yes but please respond…

In this scenario I envisage users (from the test migration) being able to access data in the cloud just like our local instance, and keeping in mind all the time that this is a test. We want to check out any operating differences between a local server instance and a cloud-based instance.

The sites will be separated from each other and users will be able to access both, but one thing to watch out for is email configurations, the new site will send notifications out to any of the users that you have set up with site access and they will be able to interact with the site, so make sure to send out the proper notifications to impacted users about the possibility of accessing the test site, as well as removing product access to any user that is not needed for the UAT portion to avoide confusion

Then, if/when successful, and we decide to move ahead to a production Atlassian hosted Jira/Confluence setup, do we 1/ remove that test migrated data (then, how?) or 2/ re-migrate over the top of it?

This is covered in the Article "Test your server to cloud migration" at point 7, but Yes I would recomend reseting the site, the article notes this as an optional step, with caveats such as using the production site as the test import site (the most common scenario for a reset prior to the prod final import):

(Optional) Step 7: Reset your test site

In some cases, you may need to delete the data from your cloud site and start again – for example, if you used your production instance to test, or need to re-run your tests.

To delete all of the data from your cloud site and reset it to the default settings, you can follow the instructions here.

Let me know if there are any more questions you have, but again I highly recomend contacting our migration support team so they can evaluate your individual setup and needs and make some better recommendations as well as assist in the migration as needed.

Regards,
Earl