Double entries in configuration sections after migrating Jira Server to Jira Cloud

[Dmitri]

Hello,

we've completed the migration from our Jira server instance (version 8.0.3) to Jira Cloud (Free plan) by using the Jira Cloud Migration Assistant, which worked much better than the Jira Cloud Site Import we used in the first attempt. The sire was completely reset after the first attempt, so that the current migration was a fresh one.

We've imported users and groups first, checked if that worked, the imported the projects.

The first attempt to import the projects failed, because a notification scheme was causing trouble. we deleted it and tried again, this time everything worked fine.

Some fine tuning was required afterwards, but in general it doesn't look that bad.
Some things are incorrect or not optimal, at least, but this seems not to affect the functionality, from what I see after a rough test.

Nevertheless I would like to know, if that's the normal situation after the migration or if something went wrong.

Many sections are double now:
"Default Issue Type Scheme" and "Default Issue Type Scheme (migrated)"
Issue types (exist only once, translations were missing) are assigned to both of them. My projects are assigned to the second one. The first has no projects assigned and is set to "global, for all not configured projects.

Workflows is another part:
"classic default workflow" exists twice:
- once in english and inactive (seems to be the one shipped with Jira Cloud by default)
- once in german and active (seems to be the migrated one)

The diagrams for both of them look differently.

About the same applies to
- Workflow Schemes
- Default Screen
- Default Screen Schemes
- Default Issue Type Screen Schemes
- Default Field Configuration
- Default Permission Schemes
- ...
-> all available twice, one of the 2 for each of them is migrated

"Default Field Configuration Scheme" didn't exist in my server version apparently, but is displayed in the cloud version as "migrated".

Priorities seem to exist twice as well, although with different names (5 on the server, 10 in the cloud). Translations were missing.

Also status entries for the issues are "duplicated". 5 were in our server instance. Now there are 12. 5 exist twice, some have the same names, some slightly different. The ones that have been in the cloud instance by default belong to 3 workflows, the migrtaed ones to one workflow.

Resolutions look fine, although the translation were missing.

It doesn't look clean to me, so I'm not sure if it's supposed to be like that and can be left as is, or if it should be fixed. In that case I would like to know how to do it properly.

Best regards,
Dmitri

[Andy Heinzer]

Hi Dmitri,

I understand that you recently used the Jira Cloud Migration Assistant to migrate from Jira Server to Jira Cloud, and in the process of doing this you have noticed what appears to be duplication of items such as workflow names, statuses, configuration schemes, etc.

This tool works a bit differently than the complete site import method.  The site import method will completely overwrite all the data when restored.  Whereas this migration assistant does not.  There are more details on what is expected to be moved over and what isn't in What gets migrated with the Jira Cloud Migration Assistant.

Having reviewed your list of items duplicated, I believe that this is all actually expected given the way that tool works. Since it does not overwrite data, your Jira site will still also have the defaults that it created before you imported this migration data.  But I can also see a potential scenario where you might use the migration assistant tool multiple times, and each time you might be duplicating some of these configuration elements in order to get that data into Cloud accurately each time.  We are aware that items such as 'Custom field language translations' are not migrated when using the migration assistant.  So my thinking is that this might be extending itself to status translations as well.

Did you run into problems using the complete site import method to migrate data from server to cloud?  Just curious as I think it might result in having less duplication of configuration elements here, but I could understand that there might be situations where this migration assistant tool is a better solution here.  There is a good guide that maybe you are already aware of to Compare cloud migration methods.  I find it to be a helpful resource when trying to figure out how to best migrate to Cloud.

Regards,

Andy

[Dmitri]

Hi Andy,

thank you for your response!

Yes, I've read the articles regarding the planning, the choosing the proper migration method etc. and think I choosed the best method with the Site Import, but somehow it didn't worky properly in our case.

The import as such went fine without any errors, but theresult was incorrect:

• we couldn't see the attachments in the issues that have attachments, i.e. they seemed to be missing
• The whole users / groups part is quite irritating:
  • The cloud instance seems to have some predefined groups, which are still there after the import, although the documentation did sound as if they would be removed and replaced by the groups we have in our server instance.
  • The users, that weren't site admins, haven't been displayed correctly in the issues related to them in some way. When viewing these issues, their names haven't being displayed, but something like "Former user (inactive)". They were active though. They didn't have accounts for the cloud, but this fact should only make sure, that they can't be assigned to new issues etc., but the old issues should still have their names properly assigned and displayed.

The migration assistant worked much better, except the described situation, which might be like that by design, but is not optimal and somewhat irritating nevertheless.

Would be good, if the migration assistant would respect / consider the translations and do some kind of mapping of the items to import to the corresponding items, that already exist in a cloud instance. In our case the instance was completely new and didn't have any data to consider, so that the assistant maybe should make a difference for the import, depending on the state of the cloud instance (new or with user data).

It seems to work with all these duplicate items, unless I fail to see something, that is missbehaving. I'm just unsure if it's ok to leave it as is, or if I should try to clean up the result somehow.

Best regards,

Dmitri

[Andy Heinzer]

Hi Dmitri,

I have created a support ticket so that we can better address your migration concerns here.  Please see https://getsupport.atlassian.com/servicedesk/customer/portal/49/MOVE-8900

I think it would be best to work on this problem there first.
Regards,

Andy

[Aman K Bedi]

Hi Dmitri,

I would need a few details and I have requested them on "https://getsupport.atlassian.com/servicedesk/customer/portal/49/MOVE-8900"

I could see that you mentioned "The import as such went fine without any errors, but theresult was incorrect:"

We can help you fix that. Please check above support request for more details.

Best Regards,

Aman Bedi