"Downtime" when migrating a Confluence space from Server to Cloud

[Kasper Fast]

Hi,

I'm planing to migrate spaces from our Confluence Server to Confluence Cloud.

I have been reading the Cloud Migration Assistant documentation https://support.atlassian.com/migration/docs/use-the-confluence-cloud-migration-assistant-to-migrate/. I can see that it mentions "downtime":

You can choose to migrate space attachments before migrating other space data. In general, the more attachments you have, the more downtime you can expect. We recommend that you migrate attachments first. This can help reduce the time window for the remaining space data migration.

And I also saw this documentation here about "downtime":

https://support.atlassian.com/migration/docs/reduce-your-migration-downtime/

I'm a bit unclear what exactly is meant by "downtime". For example, will the Migration Assistant automatically put my Confluence Server in maintenance mode and block off users access when I start migrating a Space?

I'm asking because I want to test the Migration Assistant with migrating a small "test" Space to Cloud just to see how it goes. But I don't want to affect anything else or impact any users who use other spaces on my Confluence during that.

[Phill Fox · Accepted solution]

HI @Kasper Fast 

Firstly welcome to the community where other users try to provide each other with help and assistance.

Your question about "downtime" with JCMA is an interpretation of the word. In this case what it means is that from the point you commit to the move with JCMA to the target cloud instance you should not make any further changes to your source (server) instance.  As you cannot guarantee that those changes would be picked up and migrated.  The ability to preload attachments is useful in that it minimises the window for the transfer as attachments generally make up the majority of the heavy lifting, so it makes sense to move as much of this as possible before your migration window. 

I would very strongly suggest testing multiple times with trial cloud websites to make sure you are aware of what does/does not transfer as whilst Server and Cloud are similar they are not identical and you will find differences to be aware of in the migration process. Some of these you can mitigate in advance of migration and hence the multiple test runs. 

Phill

[Kasper Fast]

Many thanks Phill. I had a feeling it was like that but wanted that have it confirmed.

[Nick Dring]

Hi Kasper, I recently moved JIRA and Confluence to the cloud.

I guess downtime is mentioned because you don't want your users editing and creating content on Confluence when you do your real migration.

I don't think Confluence blocks access during the migration, or rather I haven't read that anywhere, indeed most guides tell you to put your Confluence or Jira in browse mode

I didn't have any issues running test migrations with users being able to access Confluence at the same time.

Migration testing is really important so I would suggest you do it many times right up until the same day. Don't worry about running a lot of them, the more the merrier.

It's also important to write yourself a playbook and update it whenever needed so you end up with a list of steps to follow before and after migration. 

Remember to communicate with your colleagues in advance and keep them updated as necessary.

In my case, we announced the migration a few weeks before. I ran a few recorded sessions showing users who access Confluence what the main changes were.
We migrated over the weekend so Friday evening I put everything in browse mode and then started the migration.

Our biggest issue was with old users as our company LDAP removes the email address from deactivated users which caused problems with the JCMA.

Hope it helps!

Nick

[Kasper Fast]

Many thanks Nick. It's helpful information.