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:
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.