Why does the migration assistant tell me that spaces exist in a cloud site that I reset?

[Rob Horan]

I am running some test migrations from server to cloud, and in Confluence I am running into a serious problem, and after tests with a new site it looks like something is wrong with the site.

SOOOOOO.....

How can I fix a cloud site that I can't migrate to because server tells me the spaces exist on it, even though I've deleted and resurrected it repeatedly?

[Evgenii Maidebura]

Hi,
1. After migration confluence, I can't find space on the cloud site.
2. I can't test the migration to the end, because when choosing a space with 3 users, I get an error:  "that I have more users than the test migration allows", I had to migrate without users, tell me what I'm doing wrong?
Thank you   

[Ana Retamal]

Hi @Rob Horan !

I've checked with our Migrations team and looks like you don't have a ticket open with them. This team is fully dedicated to migrations to Cloud and their focus is to help users go through this stage as smoothly as possible. I'd highly recommend you get in contact with them, they won't only help you assess, plan, and solve the issues that might come up during your migration, but will also use your feedback to continue improving the process for future migrations :)  

You can reach out to them through this form, selecting the option 'Migration support'.

Kind regards,

Ana

Atlassian Support

[Rob Horan]

Hi Ana,

Thank you.  I don't have a ticket open with the migration team because I'm gathering information that can be applicable to all, not trying for a one-time migration of my organization's content.

[Sri Kumar]

Hi @Rob Horan ,

Good day Again.

You can try to reset the Migration Plugin on the server-side and see if that helps, below is a reference link for the same:

- Restore the Cloud Migration Assistant for Confluence to its default version 


Regards,
Sri

[Rob Horan]

Thanks - this seems to be limited to one particular Cloud site, thankfully.

This really seems like there is a problem with this particular cloud site, like something with the reset process flat out failed.

[Rob Horan]

@Sri Kumaris there a Jira version of this doc?  I went looking but couldn't find it.

[Sri Kumar]

Hi @Rob Horan ,

Is there a Jira version of this doc?

Unfortunately, we don't recommend resetting the Jira Migration plugin as it sometimes causes a lot of additional issues and it's hard to fix them. That why we haven't posted an article about resetting the plugin. 

If you need to rest the plugin please raise a case with us.  

• https://support.atlassian.com/contact/

-Sri

[Rob Horan]

You don't want a case for every single exercise I'm going to run :)

But I understand, thanks

My questions aren't coming from a place of 'I have one server and I'll be done with it forever one day' - I'm looking for a reproducible process that does not involve destroying my cloud site every time I want to re-run a migration.

[Rob Horan]

@Sri Kumarsorry, followup.

If there is no article on resetting the server, and there is no way to do so from a user's perspective, how do you recommend performing a test migration that does not involve purchasing two sites? 

Right now if I perform a migration from Jira Server to a Cloud site I cannot remigrate to that site without failure, even if i wipe that site clean via site restore.

So it seems there is no way to use the same cloud site for testing and then final migration without resetting the server since all subsequent migrations flat out fail.

[Saif]

Hi @Rob Horan ,

You can use the same site for test and production migration without failure, there is a way out of it. Instead of resetting the site using Site restore, you will need to reset it by deactivating and activating the product. This will make sure that when you use the plugin next time in production migration, it will generate a new migration scope on the plugin end and hence will not consider the previous test migration mappings.

I'm looking for a reproducible process that does not involve destroying my cloud site every time I want to re-run a migration.

I can understand you are looking for a way that does not involve destroying your Cloud site, but at the moment we have manual reset as the only option.

Thanks,

Saif

[Sri Kumar]

Hi @Rob Horan

Good day. Apologies for the delay.

We totally understand your view, need and how useful it would be for you to wipe the test data at ease. 

We have below the feature requests raised with our Dev team. 

• Provide a mechanism to wipe all Jira data from a given site
• Provide a mechanism to wipe all Confluence data from a given site

We request you to share your feedback in the form of a comment on the above tickets. Meanwhile, the temporary workaround would be is to reach out to the Migration support to reset the Jira Migration plugin or reset the clous site by unsubscribing and re-subscribing Jira.

- Sri

[Rob Horan]

@Sri Kumar - I plan to do so, thanks.

Please understand I am not asking for my own site - rather I am working on a general process that can be applied to client migrations.

I appreciate the help I have received - I just wish the documentation was a bit more up front about critical details like this.

For example, last week I attended the weekly migration demo. Here is the Q&A I engaged in:

How can users use the assistant to migrate to the Cloud, perform UAT, and then perform a second migration for production use? The tool leaves artifacts behind which prevent subsequent migrations.
Hi Robert, The admin would be the person responsible for using the cloud migration assistant. I would recommend leveraging a Sandbox if you are on Premium or Enterprise plans, and if you are on Standard, open an evaluation site and name it something to indicate it is a test site. That way, you can wipe test data to perform multiple tests and minimizes risk.
So, just so I understand, Standard users should open a trial site per migration test. What if testing extends past the trial period?
Yes, that is what I would recommend. We can extend the trial up to 90 days!

If the expectation is that users are going to require separate sites for test and production then shouldn't this be stated up front in the documentation?

I'm not saying this to be rude, and I apologize if that is how I come across, but the sudden EOL for Server has been VERY uncomfortable for many, especially because of the trial & error approach people need to take. Testing is extremely important, so people should know up front exactly how they can test, and retest, and retest ad nauseum, until they get it right.

[Rob Horan]

Also note that for one client, Atlassian provided us with a script to wipe the server free of all migration artifacts.  This led me to believe this was a standard procedure.

However, in a previous statement, you mentioned that this approach was problematic for Jira.

What makes it a workable solution in some, but not all cases?

In any case, don't the servers need to be cleared of migration artifacts before migrating to the same cloud site again?

[Rob Horan]

ignore this