Hi All,
I am planning on going with the migration using Early access program for Cloud to cloud migrations, There are some points I am not sure about in order to start with migration such as field schemes, workflows and fields on the destination site to be influenced by the migration while its all active projects with the customers.
Can you share your experience if you already did such a migration recently, please? What were the places you had to fix after the migration and working with customers how much of a downtime is needed approximately for the migration.
Hi @Vera Valshonok ,
I recently did a cloud-to-cloud migration. It was a simple migration of only 1 Jira project.
The migration is pretty straightforward. All schemes, workflows, etc .... are automatically migrated.
However, you need to investigate before the migration if the workflows, schemes, custom fields already exist in your destination site. If so, they might get overwritten (not sure if the migration assistant will warn you about this).
There is no downtime involved as both source and destination site remain active. You need to beware offcourse of changes made to the tickets in the source site, during the migration.
Migration time depends on the amount of projects, issues, ...
Best regards,
Kris
I need to move only one project to begin with as well. I am worried about the part of things to be overwritten as it can seriously influence work process with other customers on the destination site. How did you check that?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If possible, keep your workflows, scheme's, etc .... for the project you are going to migrate, separate from the existing projects on your destination site. Make sure they have unique names. In that case, there should be no interference.
After the migration, you can always change your project settings on the new environment in a more controlled way.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you!
So basically, I should check on the same named workflows, schemes, custom fields ( so there won;t be duplications) and check all during the downtime after the migration in order for the customers not to be influenced.I Right?
Also I see that not all the fields from existent tickets are migrating. It meanings they are custom fields and I would need to create them in advance before the migrations?
Do you know how can I make sure these fields stay not to loose the info in the opened ticket while the migration or will i have to add these custom fields to the request type form and then manually edit info into them (checking the info on the source site?)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Custom fields are normally automatically migrated. But you should check for duplicates and differences in configuration of individual custom fields.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
could you elaborate what do you mean under the individual custom fields , please?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've noticed that, If after my fist migration that i did ( withing 14 days that it is active in the dashboard), I make changes (open tickets + add customers to the project on the source site )and then I want to do another migration to the same project to update it on the destination site with the changes that were done on the source site, it is impossible for me. I get an error saying that such project already exists.
Was it the same for you?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The migration manager 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.
you can change the project key on the source instance to resolve the conflict or delete the project in the cloud.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Changing project key did not help , anyway after I was asked about groups and organizations and I had to agree for them to be merged which causes some changed int he destination site in the users that move.
So I had to delete previously migrated project fully , also from trash from Jira and then run migration once again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.