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

Question

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

Aman K Bedi · Answer

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

Andy Heinzer · Answer

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

Dmitri_ufzknp · Answer

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