Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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 ?

4 comments

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.

Like aynes Varghese likes this

@aynes Varghese 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. 

Like aynes Varghese likes this

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.






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. 😎

Like Dawn MacDermid likes this

@aynes Varghese 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.

@aynes Varghese 

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. :)

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.

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. 😎

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. 

Like Lorenzo Phillips likes this

Also @aynes Varghese , 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.

Like Lorenzo Phillips likes this

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.

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.

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

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you