Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,464,993
Community Members
 
Community Events
176
Community Groups

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

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.

2 answers

1 accepted

2 votes
Answer accepted
Phill Fox Community Leader Apr 26, 2022

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

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

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

Many thanks Nick. It's helpful information.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events