Re-migrating the same project with making some changes in cloud instance

[Varghese Aynes]

Hello,

I already migrated the Jira projects from the source Data center version to the destination Cloud instance.

But now I made some changes in the Project name in the source but the Project key is same
and made some workflow changes as well.


Now if I try to migrate the project, what will happen in Jira cloud ? Does it accept the change and overwrite the existing data ?

[Lorenzo Phillips]

JCMA will not allow you to migrate the project again if the same project key is used. It will be flagged as a conflict and you will not be allowed to proceed until you resolve the key conflict.

Your choices will be to change the project key on the source instance to resolve the conflict (be sure to refresh the “check for errors) screen) or delete the project in the cloud.

[Lorenzo Phillips]

@Varghese Aynes my apologies, I assumed you used the JCMA in my initial response. If you did, then my answer is correct. If you used some other mechanism please provide those details and I’ll try to provide an answer accordingly. 

[Varghese Aynes]

Thanks for your quick response and for helping me out.
Yes, Iam using JCMA.
So we don't have the option to re-migrate a same project from Jira Data center to Jira cloud.

The overwriting option is not available. am I right ? Because until we complete a full migration of the Jira Datacenter, it will be in used by users and it gets workflow customization and adding few more fields or adding more issues to it in the Jira Data center.


So we need to update all these again to the Jira Cloud ? the only option is to delete the existing cloud project and migrate again.

[Lorenzo Phillips]

That’s correct, you cannot re-migrate projects with JCMA. It sounds like you’re new to the cloud so you should be using your cloud instance in more of a test mode right now, which Atlassian allows for customers new to the cloud. So you have to reset your cloud instance until you do your final push and cutover to it permanently. 

I’m actually doing (2) final migrations this weekend for (2) separate clients. One is server-to-cloud and the other one is a consolidation of (2) cloud instances. So I definitely feel your pain, but I always recommend doing at least (3) test migrations before your final push. This has worked well for my company and we have very few problems when we do the final migration. 

Let me know if you have additional questions. I’ve personally hundreds of migrations the past several years so I’m more than happy to help you if I can. 😎

[Thomas Hardin]

@Varghese Aynes Remember, when you delete a project in the cloud, it is moved to the Trash, which means that it technically still exists and will do so for 60 days. So, make sure you permanently delete it before attempting another migration. 

When we test this process, I will run a few projects with JCMA, then I use the APIs to delete them. Documentation link - https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-projects/#api-rest-api-3-project-projectidorkey-delete

What I like to do is use is a variation of the API, 'https://your-domain.atlassian.net/rest/api/3/project/{{projectId}}' where I can associate my API with a .csv file so that the column name in the file = projectId to match the variable in the URL and the rows have the applicable Project IDs. When I run this, it removes all projects and bypasses the recycle portion.

Just an idea that may help.

[Lorenzo Phillips]

@Varghese Aynes 

Thomas is correct about accessing the API and it is a solid option to explore, but if you are not comfortable writing you own code, I have an app in the marketplace that can be used as deleting the projects does not cleanup the schemes, scheme content, custom fields, etc. I'm not sure we're supposed to self-promote so to avoid breaking any community rules, I'd ask that you DM me directly if you're interested.

@Thomas Hardin as someone that uses the API, I would definitely be interested in your feedback on my app as well. If you're interested, please DM to discuss further. My goal is to fill a gap for us admins so the more feedback I can get, the better the app will be for all of us. My goal is strictly your feedback, not to sell. :)

[Taranjeet Singh]

@Lorenzo Phillips Could you please tell me the name of the app as I am looking to use such an app to clean up an already migrated project with JCMA?

[Lorenzo Phillips]

@Taranjeet Singh

My app is Instance Auditor (Jira). If you have Confluence, I also have Instance Auditor (Confluence).

The app has gotten even more powerful since this post, but let me know what you think--you can send me direct feedback at lorenzo@renwareinc.com.

Some things to be aware of:

• In several areas, my app will only show you what you have access to. This is by design as that is what is allowed in the API. So if you have an environment that has been modified from the defaults and the admins do not have access to everything, then you may still need do some things via the UI.
• "ALWAYS" be careful when deleting anything in the instance! Many areas of the API allow me to operate just like JIra where you cannot delete a workflow that is used by a workflow scheme. But other areas, such as issues type schemes, will delete regardless and just reassign the default issue type scheme to the project.
• Make use of the search and export features before deleting. Of course, deleting inactive stuff is a no-brainer, but there are times when you have something unused that may be important. A good example is filters. It may be owned by someone no longer with the company, but it may be used for a common report or gadget driving a key dashboard. In this situation, it is best to  identify the content, connect the dots, and either have a meeting or export the data and share with the appropriate resources/stakeholders.

Finally, feel free to setup a time with me for a demo or to answer questions before you actually remove anything (if necessary). I am more than happy to assist your efforts and obtain your feedback to make the app better. :)

Enjoy!

[Taranjeet Singh]

Thank you for sharing the app info!

[Varghese Aynes]

Thank you very much for your response/suggestions/Ideas.
I really appreciate it. 

Currently, we are performing with the test environment with a few sets up of projects but every set gets new errors.

This time get a new error: Duplicate users exist.

Without going to Database, how to find and delete the duplicate users in Jira.

[Lorenzo Phillips]

Are the errors on the server side or cloud? On server side, I tend to use the User Management for Jira to locate duplicate accounts. On the cloud, I use Access to locate them. If there are too many to quickly remove, I User Management for Jira cloud version.

Unfortunately, I would expect some different errors each time. That’s why I do a minimum of (3) test runs—but we’ve gone as high as (7) test runs. The goal is to identify all of the errors so we account for everything.

Also, you may want to use some of the dark settings to avoid having to upgrade JCMA. You don’t want to do all of your testing with one version and get to your final run and it forces you to upgrade the app.

Finally, make sure you’re putting together your runbook as you’ll most likely need the Atlassian migration team to update some of the URLs post-migration. Not sure if it is required but they always ask for it so I’ve had my team just do it and attach it to demonstrate we’re following their processes for partners. 

Let me know if you need anything. I’m here for you. 😎

[Thomas Hardin]

We had similar issues with users, which were caused by 1 of 2 things:

1. Since we were linked with AD, we needed to have some local users in case we need to access the instance for emergencies. There were some emails that were duplicates, but in this case, we were able to quickly fix the local emails.
2. With AD linked to our instance via Crowd, users that left the company were inactivated. For us, that resulted in their email address being removed from AD. So, when we synced with Crowd, those emails were removed from the DB and we would then get duplicates were the duplicates were blanks. This was a much bigger issue because we needed to get passed the review in order to conduct the migration. 

For #2, we ran some simple SQL queries where we would take the username and combine it with our domain. So, username = johnq and domain = @somewhere.com. This would then become johnq@somewhere.com. If you're using Postgres, this may work as it certainly helped us. We had hundreds of users with the blank emails causing duplicate errors.

update cwd_user set email_address = (lower_user_name || '@somewhere.com') where email_address is null or email_address = '';
update cwd_user set lower_email_address = (lower_user_name || '@somewhere.com') where lower_email_address is null or lower_email_address = '';

Without knowing your sync schedule with AD, nor how many projects you are moving, you may want to adjust the schedule so that when you do run the queries, they DB doesn't reset back to it's original state.

At the time, we didn't know if the email address or lower email address was the cause, so to be sure, we corrected both. 

I hope this helps.

And as always...Be careful when working with your DB. 

[Thomas Hardin]

Also @Varghese Aynes , I wouldn't recommend deleting users before confirming whether, or not, they have history tied to them. If you decide to delete and user with history, you will lose it. We have multiple instance dating back 10 years or more, and we needed to retain that history for audit purposes. So, prior to making that decision, think about your long term needs for old data.

And to @Lorenzo Phillips  point. Measure 3 times before making your cut. Test Test Test until you're ready.

[Varghese Aynes]

While migrating, I found duplicate users on the Data center side of Jira. I don't find an option to delete the duplicate users from user Jira UI under User management other than DB, i was looking to find an option to delete the users.

These users are not sharing any issues in Jira.

[Thomas Hardin]

When creating your migration package are you selecting all users or just the users associated with the project(s)? And, the only way to delete the user(s) is through the User Management section of Jira when managing them locally or from AD, which may be difficult if you do not have access to it. 

Without knowing, it sounds like making an update to the user info in the DB may be your option. But, this isn't a step that is recommended without first understanding the impacts and considering all other options.

[Varghese Aynes]

Is there any way for me to download all the Jira users into Excel from Jira Data center version