CLOSED: AMA with Chris Clarke, Migration Platform Product Lead, on all things Cloud and migration

[cc]

UPDATE: It’s a wrap for our AMA on Cloud Migrations. Thanks to everyone for taking part and sharing your question. Be sure to watch the Atlassian Cloud Migration space to get updates on new content, questions, and announcements.

We’re keen to hear your feedback on Atlassian Cloud migration documentation and information. You can provide feedback by:

Commenting directly in the Atlassian Cloud Migration space on the Atlassian Community.

Clicking on the “let us know about your experience” link at the bottom of any page on the Atlassian Cloud Migration Center.

Cheers,

Chris, Sarah, and the Atlassian Cloud Migration Team 

[Matt Doar · Accepted solution]

Can we ever expect to see an Atlassian Cloud offering with the goal of stability?

- Runs an enterprise release

- Uses Data Center

- All changes are communicated weeks before hand to customers

- Uptime of at least 99.99%

[cc]

Hi Matt,

Absolutely! We’re working hard to make Atlassian Cloud rock solid for everyone, including enterprises. To illustrate the point, from January 2017 to March 2019, we significantly improved reliability with Jira Cloud and Confluence Cloud while serving more customers (as measured by L1 support tickets). While we can’t publicly share the specific numbers, the attached chart helps illustrate the point.:

To further prove we mean business, we recently announced a premium plan for Jira Software and Confluence. In addition to product level features, this plan will give customers financially backed SLAs (99.9% to start), unlimited storage, and 24/7 tailored support to tackle critical issues.

With regard to communicating upcoming changes beforehand, we’re discussing it. We realize that many customers are happy to trade in being on the latest and greatest features set for stability and determinism. Watch this space.

Cheers,
cc

[Boris Berenberg - Atlas Authority]

Can you comment as to what caused that drop? A drop that significant in a 4 week timespan points to a huge change.

[Matt Doar]

I think the number of support tickets over time is related to the uptime, but not directly. Does Atlassian have plans to offer a different operational approach beyond Premium?

[cc]

Yep. The big improvements came when we wrapped up our migration to AWS.

Quote from one of the guys heading the migration internally:

There was a lot of instability in our older cloud environment due to custom configurations per customer. We spent a lot of time ensuring that our new cloud environment auto-scaled better for customer workloads.

[Mirek]

Hi Chris and Sarah,

Couple of points, feedback and questions from my side related to migration (to Cloud and overall)

(...) new migration platform, designed to make migrating from Server to Atlassian Cloud more intuitive, flexible, reliable, and scalable

What is the goal of promoting migration of large enterprise instances to move from on-prem solutions to cloud and why nobody is OPEN enough and comparing differences that people should be aware before making decision to do a change? 

On below page the recommendation to move to Data Center is clear..

https://www.atlassian.com/blog/jira-software/server-vs-data-center-whats-right

We’ve found that Jira Software, Confluence, and Bitbucket customers typically need more stability between 500 – 1,000 users. 45% of current Data Center customers have upgraded to this offering at the 500 or 1,000 user tier. For Jira Service Desk, we found that 50% of Data Center customers upgrade when they reach 50 agents.

Increasing the limits of users that could be using cloud .. first 2000, then EAP for 5000/10 000 and finally a goal to have it unlimited means that you want to migrate, maintain and be responsible for business of those large enterprise companies. That is a huge responsibility and enterprise scale is a lot different than small or mid one... Different needs and responsibilities.. That is why Data Center was introduced or Enterprise release on Server, correct?

Cloud version change so often that enterprise customers might not handle updating the business processes that help them in daily work. In addition nobody is saying anything about plugins when migrating to Cloud. You can create the best migration tools ever but it would never cover most of problems related to different functionality of plugins that are between Cloud and Server and all processes that companies have. Also the main "show stopper" is the version that people use that are very old and nobody would like to invest more time, resources and money to upgrade "to the latest one" only to migrate to Cloud, and later be frustrated that things cannot be the same like on current Server version.. "because the migration tool did not mention about it"

Those two platforms (if we compare for example Next-Gen project idea with normal Jira Server solution) are so different now that it might be impossible to get a easy migration process that would work for all customers .. especially those large customers that have a large number of heavy used plugins that do not exist on Cloud or have completely different functionality because of Cloud REST API limits ..

Customers would need to sacrifice some of there data or significantly change the process that was working fine on the Server version.

Migration from "from Server to Atlassian Cloud more intuitive, flexible, reliable, and scalable", but what about migrating from Cloud to Server? Why this cannot be done in similar way? Why nobody invest time to get this also make similar so that customer can make a switch both sides easily? Why there is no similar page for Server like for Cloud? (https://www.atlassian.com/cloud-migration) .. https://www.atlassian.com/server-migration gives 404.. As a example currently when already using couple of Next-gen project it is not possible to migrate to Server (due to differences between platforms), so why not bypassing this somehow when doing a backup and make it possible?

That is why I think this AMA should cover all migration questions between platforms (not only to Cloud). What I like is that you invest time in making migration more "intuitive, flexible, reliable, and scalable" but what I so not like is that it looks like pushing towards one solution (cloud) without proper information that this migration would not be exactly 1 to 1, might fail or change your business process (which is also a part of migration process). Many customers still think that Cloud is like 2 years back and earlier - a latest version of Jira Server just hosted by Atlassian somewhere (since it is not even officially mentioned that is AWS), so when they realize that is not how they imagine then it is tool late and hard to get back. It should be all clear and transparent.

What you see is not what you get after migration in this case..

[cc]

Hi Mirek,

Thanks for the thoughtful feedback and questions. I’ve highlighted your major points and questions to address:

Differences between Atlassian Server and Atlassian Cloud:

We recognize the need for better transparency about the differences between server and cloud for customers who are considering migrating. We're working hard to provide more clarity and openness so customers can make more informed decisions.

In the meantime, we have documentation available that highlights the key features and functionality that differentiate our cloud and server products.

Scale:

As a company, we're prioritizing scale in cloud. Just a year ago, Atlassian Cloud supported up to 2,000 users. Six months ago at Summit Europe, we announced our early access program for 5,000 users. Two weeks ago at Summit US, we announced general availability for 5,000 users and an EAP for 10,000 users.

Our eventual goal is to support unlimited users on the cloud.

Data Center compared to Cloud:

Depending on a customer's needs, Data Center could be the right fit. We want customers to choose what works best for them. In the meantime, we’re working hard to make Atlassian Cloud great for customers of all sizes, including enterprises.

Cloud changes and updates:

See my answer to @Matt Doar in his question above.

App availability in Atlassian Cloud:

We’re working with Marketplace vendors to increase app availability in Atlassian Cloud. We’ve seen significant growth, with approximately one-third of Server apps available in Cloud, we've seen a 78% YoY increase in cloud app listings and a 59% YoY increase in cloud app installs. Furthermore, we're working on APIs to enable even more vendors to build their Server apps on Cloud.

Upgrading before migration:

One of the objectives of our migration assistants is to support older Server versions. For example, the Cloud Migration Assistant for Confluence (CMAC) can migrate data back to version 5.10. We’ll repeat this for Jira when we release a migration assistant in the future. Our goal is to make migration easier than upgrading, which is only possible if you don’t have to upgrade in order to migrate.

Migration difficulties with Jira Next Gen:

While Next Gen does introduce significant changes, we're fully committed to maintaining a reliable migration path from Server to Cloud far into the future. Without this, we would strand our Server customers, which would be bad for everyone.

Hopefully this helps address your concerns. If not, you know where to find us.

Sincerely,
cc

[Boris Berenberg - Atlas Authority]

The new migration tool in Confluence is absolutely excellent. Can you disclose anything about a similar tool for Jira?

[Sarah Schuster]

Hey @Boris Berenberg - Atlas Authority ,

I'm really glad to hear that the Confluence Cloud Migration Assistant has been helpful to you!

While we can’t disclose dates, a migration assistant for Jira is a high priority for the team. Compared to Confluence, Jira poses additional complexities that must be considered when building a migration tool. Unlike Confluence (where spaces are essentially isolated), Jira is composed of projects that rely on shared global configurations, which makes incremental project and configuration migration a huge challenge.

Be sure to watch this space for updates and new information.

Best,
Sarah Schuster

[Partha]

@Boris Berenberg - Atlas Authority  assume you have seen https://community.atlassian.com/t5/Jira-Migrations-Early-Access/About-the-Jira-Cloud-Migration-Assistant-early-access-program/gpm-p/1165638

[Boris Berenberg - Atlas Authority]

Yup, hope everything has been well on your end ❤️

[Bryan Trummer - ReleaseTEAM]

Hi Chris,

What do you see is the biggest challenge when migrating from Server to Cloud? Do you see companies migrating from Data Center to Cloud as well?

[Matt Doar]

That would be interesting to hear of a company moving from DC to Cloud. I've not met any myself

[Sarah Schuster]

Hey @Bryan Trummer - ReleaseTEAM,

Last year, the biggest challenges we saw for customers migrating from Server to Cloud were the need for understanding, planning resources and knowing what to expect from their migration. While we did provide them with some documentation explaining basic steps to migrate, there was no single source that was easily searchable, and brought all the content together in a structured and organised manner. Working closely with customers to develop their migration strategy, the Migrations team developed migration planning guides for Jira and Confluence as a resource for customers to plan and execute their Server to Cloud migrations. We regularly update these documents as we get customer feedback, or tooling improvements, to ensure these documents help migrating customers.

Additionally, everyone involved in the Migrations team, from design, product, development and support helped to revamp our Cloud Migration Center as a one-stop-shop for customers to plan their migration from Server to Cloud, as well as the opportunity to speak to one of our Customer Success Managers about their migrations needs. We always welcome feedback on our site and planning guides.

After planning, the next questions we hear from customers are "what data should I migrate", "how do I migrate apps" and "what is the best approach to merging and consolidation my data?"

For this, we offer automated migration tools, documentation, and support.  

Best,
Sarah Schuster

[Matt Doar]

So, no customers moved from DC to Cloud?

[Sarah Schuster]

Hey Matt Doar [LinkedIn]

For DC customers who have migrated to our Cloud, they have been able to use our Server documentation successfully to migrate their data from DC to our Cloud via self-service or a partner. The only exception is that in order to migrate Confluence to Cloud, a full site export from Confluence Server is required, as the Confluence Cloud Migration Assistant is not yet supported for Data Center. 

Update (Aug 19th, 2019): The Confluence Cloud Migration Assistant now supports space-by-space and full site migrations from Data Center. 

Thanks,
Sarah Schuster

[Matt Doar]

Well yes, the steps should be about the same for DC or Server migrations to the cloud. But I'd be surprised if any customer who had chosen to move to DC at some point would then move to Cloud later.  But tell me I'm mistaken!

[Sarah Schuster]

Hey Matt -

Yes, some customers have chosen Data Center first, then have since moved to our Cloud. And with our recent Summit announcements, inquiries are really picking up!

Cheers!

[Taranjeet Singh]

Hi Chris,

The document https://confluence.atlassian.com/confcloud/cloud-migration-assistant-for-confluence-959303217.html mentions

• This tool does not migrate any app data. You'll need to check with the app developers to confirm whether you are able to move app data across. You can check what apps you're using at my.atlassian.com.

Are the  data for applications like Confluence Questions and Confluence Team Calendars also not possible to migrate with this tool? If not, what are the alternatives methods recommended by Atlassian to migrate these apps' data from Server to Cloud?

[Sarah Schuster]

Hey Taranjeet Singh -

The bad news:
At the moment, our automated migration tooling does not support migrating Confluence Questions or Confluence Team Calendars data.

The good news:
We’re working on it! In the meantime, our Migrations Support team has successfully applied manual workarounds for customers who request it. Contact them here for more details.

Thanks,
Sarah Schuster

[Taranjeet Singh]

Hi Chris,

The document https://confluence.atlassian.com/confcloud/cloud-migration-assistant-for-confluence-959303217.html mentions, mentions

"If you use an external user management system, we recommend syncing it with your local directory before migrating."

Does this mean that before migrating users and groups, we only need to sync external user directories (like we do for LDAP/AD by clicking on Synchronize button on User Directories Administration area)?

or

Does this mean that before migrating users and groups, all users and groups existing in external user directories, need to be re-created or migrated to Confluence Internal directory?

If this is the case, what is the best way this can be accomplished? The users and groups migration seems to be the the most crucial thing while migrating from Server to Cloud.

[cc]

Hi Taranjeet,

With the recent release of the Cloud Migration Assistant for Confluence (CMAC), you can now optionally migrate users and groups from your Confluence server’s local directory to Atlassian Cloud, depending on how you manage users and groups:

1. If you aren’t using Atlassian Access to sync your corporate user directory with Atlassian Cloud, you should use CMAC to migrate users and groups, in addition to spaces. This will ensure that any users and groups in your local Confluence server directory are migrated to Atlassian Cloud before spaces.

2. If you are using Atlassian Access to sync your corporate user directory with Atlassian Cloud, given that your users and groups will already exist, you should skip users and groups in CMAC and only migrate spaces. Users and groups referenced in spaces will resolve to already-sync’d users and groups.

So to answer your question directly:

1. If you aren’t using Access to sync users and groups and you want to migrate them from your local Confluence server directory, you should sync your local server directory with your LDAP/AD and use CMAC to migrate users and groups.

2. If you are using Access to sync the users and groups in your LDAP/AD directory (and those users and groups are the same as those specified in your local Confluence server directory), you can skip using CMAC for users and groups.

If you have questions about what option is best for you, please contact us.

Cheers,
cc

[Taranjeet Singh]

@cc Thanks, but that did not answer my original questions. There is a confusion in the statement "we recommend syncing it with your local directory before migrating", which I wanted to clarify.

Does "syncing" here mean we only need to sync users and groups from external user directories (like  LDAP/AD) by clicking on Synchronize button on User Directories Administration area)?

or

Does it mean that all users and groups existing in external user directories (like  LDAP/AD), need to be re-created in Confluence Internal directory, if they do not exist in Internal directory?

If second is the case, what is the best way to re-create or migrate users & groups from external user directory to Confluence Internal directory?

The confusion exists because I am not sure if all users and groups must first exist in Confluence Internal directory in Server before they can be migrated to Cloud using CMAC or the users and groups can directly be picked up from external user directory in Server while migrating to Cloud.

[Caterina Curti]

Dear @Taranjeet Singh

Thank you for your patience! I have been working with Chris and Sarah to answer the outstanding items for you.

Let me try to provide more details on this subject here and please do let us know if there are still any open questions.

To answer your question:

• Yes, we recommend customers to synchronize the user directories right before running the migration.

• No, users and groups don’t need to be created or migrated in the Confluence internal user directory.

The Cloud Migration Assistant for Confluence migrates all users and groups from every user directory that is connected at the time when the migration runs. This includes the internal user directory (available at the time of the installation of a Confluence server site) and any additional user directory that has been setup (e.g. LDAP/AP but also Jira or Crowd).

The “sync” is required so that we make sure that the users and groups from the external user directories are exactly in the same status as in the source (LDAP, AD, etc.) before triggering the migration. We just updated the documentation to explicitly mention this.

There is no need to have all users and groups available in the internal user directory when running a migration for Confluence using the Cloud Migration Assistant for Confluence (irrespective of Atlassian Access being setup or not on the target Atlassian Cloud site).

Does this clarify the remaining items?

Cheers,

Caterina - Atlassian

[Taranjeet Singh]

Hi Chris,

Can you discuss comparison or pros & cons between using "XML data backup" vs "Cloud Migration Assistant for Confluence" for migration from Confluence Server to Cloud?

Does XML data backup from Cloud include any app data?

[Sarah Schuster]

Hey @Taranjeet Singh,

Here are the pros and cons between leveraging the Confluence Cloud Migration Assistant versus XML Data Backup to migrate Confluence from Server to Cloud.

Confluence Cloud Migration Assistant

Pros:

• Move space by space (or all spaces): Choose which Server spaces you wish to import into Cloud. These might be all your spaces, current/active spaces, or all non-archived spaces. Spaces migrate in parallel, without having to individually export and import them. The import is in your control.

• Migrate and sync users and groups: You can easily migrate your users and groups to Cloud, and sync users from Server with Cloud whenever you need.

• View progress: Watch the progress of each space as it imports into Cloud.

• Increased reliability: Failure is isolated to individual spaces, meaning if one space fails, others continue to migrate without having to restart the process.

• Data Center to Cloud Migrations - Supported (Aug 19th, 2019)

Cons:

• 3rd party app data - Not accessible from cloud (yet)

XML Data Backup (“Full Site Export”)

Pros:

• Data Center to Cloud Migrations - Supported

Cons:

• All or nothing - There’s no way to choose which spaces to move.

• Manual, Isolated. No ability to continuously sync users from Server to Cloud.

• Limited visibility. Hard to visualize progress the way it is implemented.

• Low Success Rate. If a particular space gives you issues, you must troubleshoot/resolve the issues for that space, then perform the full site import again.

• 3rd party app data - Not accessible from cloud

Going forward, your best option to migrate Confluence from Server to Cloud is through the Confluence Cloud Migration Assistant.

Thanks,
Sarah Schuster

[Nic Brough -Adaptavist-]

Hi Chris,

I've already been asked a few times about what a "migration platform" is.  People understand the idea of a "platform" for running stuff - Cloud, Server, DC, all "platforms" for running a service.

But a "migration platform" does not seem to make a lot of sense.  It sounds like there's a massive piece of software arriving that would make moving from place to place a case of "here's my data, move it without effort".  Is that right?

[cc]

Hey @Nic Brough -Adaptavist- ,

Migration “platform” means we’re leveraging cloud-based microservices across multiple Atlassian products, for everything from routing data to multiple destinations, to making migrations faster and more resilient no matter how large the data gets.

Hope this helps,
cc