Migrating from server to cloud

[Raymond Wan]

Hi all,

We are interested in migrating a server instance of Confluence v6.15.2 up to the cloud using Atlassian's migration procedures.

We've asked some questions to Atlassian's IT support and I have read through some of the documentation.  But I guess there is one thing that still worries me.

Our Confluence is:

• protected from the outside world via an institutional firewall; the server should have outbound access, but no inbound access
• behind a load balancer using nginx -- the load balancer is on a separate server from where Confluence is, but both are behind our institutional firewall
  
  
  

Will either or both issues give us problems with the migration?  Unfortunately, I'm not the person who set up the above so removing them is not going to be easy.  Migration to the cloud was hopefully going to get us away from this setup, but now I realise that maybe it will prevent us from migrating...

If either is going to be a problem, I was thinking of backing it up and restoring it on to a computer that it outside of our organization and then migrating from that.  Is this recommended, or should we just "give it a try" first?

Also, the backup is about 25 GB in size...  I know how long depends on our connection to Atlassian's cloud servers, but any idea how long migrating will take?  i.e., hours...days?

Thank you!  Any advice would be appreciated!

Ray

[Craig Castle-Mead · Accepted solution]

Hey @Raymond Wan 

You're going to want to upgrade your Confluence from 6.15.2 to one of the MUCH more recent versions - I can't remember off the top of my head if Confluence Cloud Migration Assistant (CCMA) requires a specific version of the product, however 6.15 was released in 2019, and I would be very surprised if CCMA worked seamlessly with the 6.x version - and if you run in to ANY issues with the migration, I'd guess support will get you to upgrade, so better to get ahead of it - though https://support.atlassian.com/migration/docs/confluence-cloud-migration-assistant-supported-versions/ does seem to indicate 5.10.0 or higher is supported....

As for how long will ~ 25GB of data take - as you indicated, there's a lot to consider (your location and bandwidth, number/size of attachments, which region you're migrating to, etc etc). https://marketplace.atlassian.com/apps/1219672/confluence-cloud-migration-assistant/version-history does show that CCMA 3.3.1 supports splitting the migration in to stages - eg: pre-synchronising the attachments (the bulk of the size), then you can do additional incremental syncs - then on your final production move, it's a final incremental sync that you need an outage window for.

CCM

[Raymond Wan]

Hi Craig,

Thanks for posting a reply!

Our license has expired already so we cannot upgrade past 6.15.2.  However, that link you put up does imply that maybe it might be ok as long as it is higher than 5.10.0 .  We plan to sign up for the free trial and ultimately go to a payment plan (probably Standard, the lowest tier).  So, I'm not sure if doing so will enable us to upgrade.  I think we will see -- but thanks for the warning!

I have been reading about the migration steps, but I didn't notice the incremental syncs -- that will certainly help.

Of course, I'm worried about about any outage.  But I think we should also prevent any writes to the Confluence instance during migration or else the original and the migrated version will "deviate" from each other.  Would you (or anyone else reading) know if there is a way to allow two instances to deviate for a "short period" (i.e., however long it takes to do the migration) and then quickly sync the difference?  If that was possible, I think I'd be less worried of however much time is needed.

Thank you for your help!

Ray

[Daphne Zhang]

Hello,

Daphne from Atlassian here 👋🏼

We’re doing research on how customers are using our Migration documentation, and we’re interested in speaking with customers who are migrating (or have recently migrated) less than 1000 users and who are not using (or did not use) the services of a Solution Partner.

What’s involved in the research:

• We’ll schedule a 1-hour session at a time that’s convenient for you. The session will be conducted over video-conference, so you can participate from anywhere.

• During the research, we'll start with a general chat to get to know you, and then we’d like to hear about where you are in your migration journey, and what documentation you’ve been referring to.

• As a token of our appreciation, you'll receive an e-gift card worth $100 within 5 days of completing your session.

If you're interested in taking part, please contact me on dzhang3@atlassian.com to schedule a time that works for you. If you have any other questions at all, feel free to reply to this message or email me directly. We look forward to meeting you!

Cheers,

Daphne Zhang

(Migrations Experience Design Team)

[Pramodh M]

Hi @Raymond Wan 

It should have an outbound access (From LB) to IPs & whitelisted URLS, that should suffice.

Here are those

https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products ( CCMA Communications )

Thanks,

Pramodh 

[Raymond Wan]

Hi Pramodh,

Thank you for your reply!  Obviously, this addresses are whitelisted from the server itself and not within the Confluence administrator's interface.  Is this correct?

I have administrator's access to Confluence, but not to the underlying server.  Whitelisting a set of addresses is also (unfortunately) not just a matter of running a command; but might also require approval from a larger committee.

I guess this might be a stumbling block to our plans of doing a direct migration (as opposed to one from a cloned instance outside of the firewall).

Thank you for your help!

Ray