The first part is - server/datacenter is the same thing in terms of migrations, so the documentation for "server" is what you're after.
That said, this is no easy task. Out of box, without any 3rd party apps, your Jira versions must be identical. If they are not, then normally you would clone the source instance (or migrate to existing) to an "intermediate" instance. Then, you can upgrade this intermediate instance to the target version, and then you can make a compatible backup. Best yet is to have both on the same version to avoid this hocus pocus with upgrades, but that's one way to do it without affecting the source.
Unofficially, this version requirement is more often than not unnecessary. The actual data being used by the importer hasn't changed in a while, and the version check really just checks the version in the backup file. So, one could just edit the version in the backup to trick Jira into trusting it.
That said, this I don't recommend unless you are very, very sure that there is no major difference between the Jira versions (which there might be). If you'd thus force Jira into trusting incompatible data, it could of course backfire. So don't do that with production.
The same logic applies to 3rd party apps / plugins, when it comes to customfield value data. The out of box backup doesn't import any plugin data all by itself (no boards, no roadmaps, no anything), it only includes custom fields as far as plugins go, so that's the same bucket - either the same plugin version matches, or it can be edited, but you must be sure the custom field data format has not changed between the different versions. There is no guarantee the values can be imported either (a specific plugin could not support project restoration).
Unless you see a valid use case to purchase any 3rd party apps off the marketplace (such as Project Configurator, Project Configuration Manager), you would need to recreate the projects on the target instance - same schemes, workflows, screens, etc. All of that would need to be done manually. The backup strictly only imports: issue data, role members (I think?), components, versions. So you do need to manually create a configured, empty project, to import the data into.
Once you have an empty project ready, you then would go ahead and import the data from the backup, provided that all of the version differences are sorted.
If you have old instances, there will most probably be some errors and bugs, so the import is very unlikely to work the first time. There may be a need to fix some formatting, maybe there are duplicate users, maybe there is some invalid value. So if you get a partial import and it errors out somewhere, you need to delete the stuff it imported (issues, versions, components) to get an empty project again, fix the problem, import again.
Then there is the question whether the usernames are corresponding to the target Jira instance (e.g. difference in local accounts vs ldap), which may require remapping if the same usernames wouldn't be valid. System timezones also need to be the same on both environments, otherwise this would cause a time offset during the import.
This is overall not an easy process if it's your first migration. It tends to be marketed as "so easy much wow" but it really is not. If the target instance is production - which I assume - I must strongly suggest to test the migration with a non-prod instance first (a clone of your prod so you know it is configured the same way).
The relevant KBA for this is here:
# https://confluence.atlassian.com/adminjiraserver/restoring-a-project-from-backup-938847691.html
My recommendation would be to work with non-production instances to get the hang of it and to understand what you need to do in order to make this work. Doing so straight away probably won't work, you will need to do either an intermediate upgrade, or risk editing the versions in the backup. You might need to prepare some bug fixes. So for all intents and purposes, import only to non-production until you are sure the process works. Failed imports can be troublesome and leave (well, seldom, but can) corrupted data behind.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.