Happy Migrations Month! If you haven’t heard, this January we’re hosting exclusive events, giving away cloudies, and sharing helpful resources as part of our #CountdownToCloud celebration.
Hopefully you’ve read the interview with Sean McKenna, Senior Software Engineer and Team Lead at Lucid, about his migration story. We also hope you’ll check out what other members of Community have learned so far this month. And as always, don’t forget to visit and bookmark the Cloud Migration Center to get started on your journey to Cloud.
As Head of Product, Migration Journey, I’m interested to know: what questions can I answer about Cloud migrations? Is there any feedback you’d like to share directly with me and the migration team?
Comment directly on this thread and I’ll be back with other Atlassians on January 31st to get your questions answered. Everyone who participates by adding a question will be entered to win a cloudie!
1. During large migrations we often tend to see timeouts or database connections issues. How are you planning to ensure that the efficiency and performance through CMA's (Cloud Migration assistants) is top notch? Not to mention, it is still much better than site imports!
2. What role does Atlassian support plays to resolve apps migrations complexities? Reaching out to app vendors directly seems like a blocker. Is there a plan to onboard app vendors on a single support portal?
3. When can we expect dashboards & cross-project boards to be migrated using JCMA?
Hi Utkarsh. Answers to your questions below:
1. From @Jason Wongour resident Jira migration expert:
Site import is very fast as it read and writes at the database layer, bypassing API validation. For this reason it is not transparent to data problems and a little risky if your source has integrity issues. However it is fast.
With the same hardware and internet connections the CMAs are slower as they do have to migrate data through APIs that apply data validation (for good reason). The longer time taken will increase the risk of timeouts. Generally speaking however, the connections with the CMAs are more stable. For example, when attachments reach a timeout on site import we recommend breaking attachments into smaller chunks and running multiple sessions that fly under the timeout window. For the CMAs, attachment migration will usually run for as long as it takes without timeout.
We are looking at techniques to pre-migrate what we can, so that you “send ahead” as much data as possible which will reduce the payload for the final migration (usually production run).
You will already see this technique in the CMAs where you can send ahead Users & Groups or attachments as a pre-migration task that can run for very long periods prior to your migration. When you then come round to the final migration, you have already sent the data ahead and so the residual time drops a lot as the CMAs only need to migrate a handful of users, groups or attachments that were recently added.
We’re working on seeing if we can get this technique to work on other data objects such as issues. Hard to quote what gains we will see, but on paper the statistics show it has the potential to rival, if not surpass site import performance.
2. I agree. Having to get support directly to Marketplace partners to achieve basic app migration isn’t scalable. To solve this issue, we set out 2 years ago to build an app migration framework to enable app developers to build automated migration paths as a seamless part of the Cloud Migration Assistants. I’m happy to say that 2 years later, CMA app migration is in public beta and general availability is right around the corner with ~90 supported apps!
With regard to a “single support portal”, that’s an interesting idea! I’ll chat with the peeps internally and see if it gains traction.
3. We’ll add support to JCMA for migrating dashboards and cross-project boards eventually, but aren’t committing to dates yet. We still need to figure out how to handle project dependencies (what to do when some projects haven’t been migrated yet) and current thinking is to add support for filters (including cross-project) first, then add dashboards and cross project boards on top.
1. When would Jira Cloud to Cloud migration assistant start supporting Jira Service Management projects?
2. Does JCMA support migration of 'Email Requests' settings for Jira Service Management projects?
3. Are there any recommendations or best practices for speeding up or improving the performance of running migration plans for projects with large number of issues (say, 100k) using JCMA.
4. In Jira Server or DC, it is very easy to get the count of total issues in Jira or any project from Jira's Issue Navigator page, but after migration to Jira Cloud, there is no way I have noticed to get such counts readily from Jira's UI or Jira's Issue Navigator page. It is often needed to tally issue counts during migration testing. Is there a way to get such counts from Jira Cloud UI that I am missing; or if not, is there plan to implement this in Jira Cloud UI?
Hey Taranjeet and Adam. Answers to each question below:
1. The team is actively scoping JSM project migration as part of our cloud-to-cloud migration roadmap for Jira. We’ll likely roll it out in early access in late calendar year 2022 or early 2023. For more information, you can follow this JAC ticket.
2. Not currently. Migrating email request settings is complicated and some customers actually prefer to set it up again in cloud.
3. From @Jason Wong, our resident Jira migration expert:
The simplest advice is to cleanup what you can - see what you can do to reduce the issue count by looking for old or inactive issues.
You could try the approach of aggressively reducing backlogged issues that haven’t really been worked on - try the JQL search where you look for issues that haven’t been updated in the last year, say < -365d https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-fields/#Updated
Consider leaving these issues Server/DC.
If that is not an option, you could apply a workaround by creating a secondary project for the purpose of archiving and moving old or inactive issues there. This will get your primary project’s issue count down and you can then migrate the secondary project later on in less sensitive migration windows.
Cleanup workarounds are not an option for you, we are working on improvements to the speed of issue migration and testing out better pre-migration features that will reduce the time taken in practise so watch this space!
4. A good question for Jira Cloud team, whom we’ve pinged. We’ll get back to you with their answer as soon as we have it.
Hi Dave. Our migration roadmap philosophy is pretty simple at heart and goes something like this:
Develop migration paths that make it feasible for as many customers as possible to migrate to our most popular cloud destinations (Confluence, JSW, JSM, Bitbucket, etc.) without too much trouble. We call this “migration coverage.”
Layer on capabilities that increase the completeness of migrated data, reduce data loss, and require less manual effort to move and/or repair data that isn’t covered by default (e.g. 3rd party Marketplace apps). We call this “migration fidelity.”
Continuously improve the reliability, speed, and scale of our migration tools so that they are as painless, predictable, and require the shortest downtimes as possible for even the largest datasets. We call this “migration reliability at scale.”
While we’ll always have to juggle all three, the general trend is:
With the recent availability of JSM and Bitbucket migration tools, basic coverage is in place for most core products
We’ve made good strides recently on fidelity (i.e. app migration) and will continue to plug the most critical gaps
We’re focusing more than ever on making our tools as reliable as possible for as many customers as possible
Our roadmap reflects these trends. For details, see: https://www.atlassian.com/roadmap/cloud?category=migrating& (filtered on “Cloud Migrations”).
@cc - thanks for summarizing your migration roadmaps three pillars - and sharing those feedback methods. Glad your team is watching the Cloud migrations collection on Community. 💪
It's been a crazy first quarter - I'm just getting to reading your response! Hopefully you see my response, weeks later. 🤣
Hi Chris & Team,
Thank you for taking the time to answer some of these questions.
I have already successfully migrated to the Cloud. What is the best way for people in my situation to provide feedback on the migration process?
And, what or where is the most helpful medium to share the experience with others who haven't completed the migration yet?
Hi Jimmy. Congrats on your successful migration! We’re always looking to better understand and improve the migrations experience. If you’d like to share feedback, please email firstname.lastname@example.org and we’ll connect you someone on the migration team.
It’s always helpful when those who’ve migrated share their experience in Community and help answer questions in the Cloud migrations collection, just as you do often!
One of the justifications we often hear from the community regarding why a member is on Server or Data Center is that there is a more robust set of tools available for Server and DC clients.
Specifically related to Confluence, what are the top five blockers that the team has identified for Server/DC -> Cloud migration, and how soon will they be available on Cloud prior to the migration period deadline?
Hi Andy. We’ve made solid progress on Confluence Cloud in the past couple of years, but if I had to list five migration blockers, currently in progress, here’s my shortlist:
Server/DC app availability in Cloud - in progress - While there’s more to do, >600 new Cloud apps got added to Marketplace last year and most Marketplace apps are Cloud apps!
Migration paths for Server/DC apps in Cloud - in progress - Automated migration paths are in development for over 40 Confluence apps! The pace will only increase.
Data residency (core and app data) - in progress - We shipped core data residency in Standard & Premium last year and app data residency is on the roadmap for calendar 2022!
Enterprise user scale (20k users and above) - in progress - We raised the Confluence user limit to 20k last year and we’re on track to raise it again to 35k later this year!
Enterprise security and compliance - in progress - HIPAA compliance is a public roadmap commitment for calendar 2022 and FedRAMP - Moderate for calendar 2023!
What’s on your “top five” list?
When a site is migrated to another site (cloud to cloud) and if the origin site is under the annual plan any credit left (product or app) is lost.
A migration experience is more than just the technical aspect of it, therefore the financial aspect should be taken into consideration as well as we customers feel that it is not acceptable that the credit can't be transferred to the destination site even though both sites are under the same organization. If data can be migrated, credit should be able to be migrated as well.
Hi Joao. I hear you and agree!. The migration experience is about more than just moving the bits. As you’ve discovered, our pricing incentive work to date has been more focused on Server-to-Cloud migration than on Cloud-to-Cloud migration. I’ll take this feedback to the pricing team ASAP.
My company wouldn't mind moving to cloud but we have an ITAR compliance requirement.
Atlassian is claiming to be going for FedRAMP moderate last time I checked and this seems to satisfy most ITAR requirements and should theoretically be ITAR compliant to my knowledge.
Does Atlassian have any plans to offer ITAR related plans or just claim to be ITAR compliant along with FedRAMP moderate?
This is our companies main issue with migrating to cloud at this time.
Hi Michael, we know that customers have many important security and compliance requirements to consider as they explore Atlassian Cloud. That’s why we made our Cloud Roadmap public and created a security and compliance section on the roadmap.
ITAR compliance is not currently on our roadmap and we do not have plans at this point in time to include it as part of our FedRAMP ATO. We are, however, evaluating it as a future roadmap item and would love to hear more about your team’s specific use cases. Please feel free to share your requirements and use case in the Trust & Security group on Community.
Our migration will consist of (2) Jira instantiations and (2) Confluence instantiations. Each product has its own database.
Can we discuss how to perform a cloud migration to combine these products so we end up with (1) Jira and (1) Confluence environment?
What is the best method to migrate (4) different databases down to (2)? Can that even be done?
Looking forward to your responses.
@Patricia Cully - hi Patricia!
If you were to migrate the two source Jira instances into a single Jira Cloud instance, then you would have one database (Cloud-powered!).
Can you rephrase your question, or add some additional context to it? When combining instances, the data naturally will be combined.
Hi Patricia. Let me know if I'm not understanding your question correctly.
The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant can be used to “merge” data from multiple instances by selecting a common Jira or Confluence cloud site as the destination for selected projects and spaces.
That said, while this is indeed possible, merging instances adds a new layer of complexity to your migration that you should understand before you begin. Generally speaking it will involve merging what were once 2x independent Jira instance admin domains into one domain in your final destination. To discuss your migration strategy with our Migrations team, please raise a Support ticket.
We use the Comala Document Management add-on as core functionality to our business processes. In the heavily regulated industry we work, Confluence is not compliant without the features that Comala offer.
I understand from Comala that Atlassian has failed to deliver on its commitment to rollout many cloud features that are required to allow Comala to reach feature parity. Indeed you are far behind the promised roadmap. While at same time you are compelling us to move with price rises and upgrade lockouts from 15 Feb 2022.
We would love to migrate to the cloud but simply cannot.
Can I we please have a discussion about when Atlassian will deliver the required features.
See here for information on the issues. https://wiki.comalatech.com/display/CDMC/Migrating+to+Confluence+Cloud#MigratingtoConfluenceCloud-ComalaDocumentManagementCloudFeatureParity
Hi @Richard Brookes. Thanks for your patience. While I don’t know the specifics about what is required for Comala to achieve the parity you require for compliance, I’m committed to finding out.
Could you send your meeting availability for the next two weeks to Elizabeth on our Product Marketing team at email@example.com? We can get a meeting scheduled with you, me, and the relevant folks from our Confluence team.
If neither is viable then it would make more sense for us to migrate to a different platform entirely than to migrate to the cloud version of BitBucket. Support for this in BitBucket server has also been very poor, to be frank.
We've been told previously by Jira Service Management consultants that moving our data from the Server product to the Cloud and Data Center violates your TOS currently based on some of the data that is stored in our project issues.
Who can we get in touch with to confirm we wouldn't be violating TOS by moving to Data Center?
Hi Amber. Assuming your instance would remain behind your firewall, migrating to Data Center shouldn’t violate our TOS. That said, if you’d like to learn more about data security in the context of Data Center and Cloud, please join the Trust & Security group in Community. Our Trust Team is there to help.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events