Dr. Ankita Mehta-OpsHub, Inc Atlassian Partner

Hi @Prabhu Palanisamy {Onward}, I have seen teams approach this in different ways. I suggest taking a phased way – start with a pilot, check results, and then plan the rest in phases. To your second point, scripts can work for simpler migrations, but if you have historical records, comments, attachments, custom fields, and…

Hi @rumceisz, If the immediate requirement is simply tracking how long an issue stays in In Progress, I’d separate that from the migration itself: For the next 12 months: If you already have ScriptRunner but don't have someone available to modify scripts, a built-in automation approach may be easier to maintain than…

Hi @Jiahao Song, What a detailed and insightful set of replies above, really! cover the temporary remote-link approach and JCMA’s handling of links when both projects eventually move to the same Cloud site. One additional consideration I would like to add is how much migration activity you need to manage while those waves…

Hi @Yegane, That's a solid shortlist. The "best" choice usually depends more on workflow and growth plans than on feature checklists alone. Look at how deeply the tool integrates with Jira issues, workflows, and permissions rather than just whether it has a Jira connector. Consider how easily QA teams can create, organize,…

Excellent breakdown. This covers most of the areas teams should evaluate before moving from Jira Server to Cloud. One thing I'd add is the importance of reviewing historical data quality before migration. Over the years, many Jira instances accumulate unused custom fields, outdated configurations, and large volumes of…

Hi @jameers , Great question! :) One lesson that often comes up is that the technical migration itself can be easier than understanding and simplifying what already exists in Jira. Many Data Center instances have accumulated years of custom workflows, fields, permissions, apps, and project-specific exceptions. Moving…

Hi @Edgar Manuel For a setup with three Atlassian instances, I’d recommend approaching the consolidation in stages rather than treating it as a single migration. 1. Start with an assessment of the three instances Identify the projects, users, workflows, custom fields, attachments, history, JSM configurations, and…

Hi @Sherwin Soriano Yes, you can migrate tickets from one Jira Cloud site to another. Whether you need an additional tool depends on how much data you want to move and how different the two Jira setups are. A few things to check: * Data scope: Decide whether you need to move only tickets or also comments, attachments,…

Hi @Biancha First of all, I am wondering that how could I miss answering such a meticulous question and reading some of the best answers. The answers shared above are really useful, especially the points around using Atlassian’s Cloud-to-Cloud copy capability and treating this as a repeatable runbook. Just adding one more…

Hi @Utkarsh Chandel For enterprise migration, data hygiene before the move is just as important as the migration tool itself. These specific steps must be included: * Review project and field setup: Decide whether to reuse existing project templates, workflows, and fields, or clean them up before moving to the new system.…

Hi @Diogo Malvezzi That’s a solid answer above already, especially around JCMA limitations with older Jira versions. Given your setup, a few additional things I’d keep in mind: * Upgrade path complexity: Jumping from Jira 6.x to a JCMA-supported version isn’t always straightforward. Multiple hops, plugin compatibility, and…

Hi @Aruna Ramesh kumar Interesting approach, and yes, it’s definitely possible to migrate attachments using Jira REST APIs like you’ve done. A few points to be considered: * Your approach is valid but limited at scale: REST APIs can handle attachment migration, but bulk scenarios like 1000+ issues often run into rate…

Hi @Katerina Valouchova That’s a fair point others have raised, especially with the long-term direction shifting toward Cloud. * Timeline matters: If Data Center is only a short-term step, it is worth weighing whether another migrations would be needed later. * Current constraints: Some teams still choose Data Center due…

Hi @WW _ 정유정 When moving from Jira Data Center to Jira Cloud, Zephyr Essential (Server/Data Center) does not carry over directly. Zephyr on Cloud is a separate app, so you would typically need to install and subscribe to the Cloud version. The Server/Data Center license cannot be reused on Cloud. Also, it’s important to…

Hi @Meena The above answer covers the basics aptly. What usually makes the difference is how deep your sync needs to go. A few additional things worth thinking through before you decide: * Depth of sync needed: Basic connectors handle ticket creation, but full context sync (comments, attachments, updates) needs more…

Hi @Désiré Dadie This issue is because story points are handled differently in Company-managed and Team-managed projects as already stated in one of the above responses A few additional things you may want to keep in mind: * Field independence: Team-managed projects create their own fields, so global fields like story…

Hi @taylor That's a good approach already shared above of keeping Jira logic inside Jira and using external tools for connectivity is generally a good baseline. A few additional things you may want to consider as your setup evolves: * Scope of automation: Zapier/Make work well for simple triggers like form submissions, but…

Hi @QA Team Adding a bit more context to the points already shared about permissions and Cloud transfer between Jira sites. A few things may be considered while trying to move the project between Jira Cloud instances: * Admin access on both sides: For Cloud-to-Cloud copy options to work, the same user usually needs…

Hi @Dharani Dharan D Just to add to the helpful responses above. Since this is a Cloud to Cloud move in Jira Cloud, the Jira Cloud Migration Assistant usually doesn’t come into the picture. The Assistant is mainly used when teams are moving from Server or Data Center into Cloud. For Cloud-to-Cloud migrations, the data copy…

Hi @Ashok Murugesan Thanks for sharing the details. Since the client wants to retain several years of request history for audit purposes, a few practical points are worth considering early: * Native export limitations: JSM can export issues to CSV, but this mainly captures ticket fields. Comments, attachments, and full…

Hi @Jordan Collins Welcome to the Community! A few things worth keeping in mind during a Jira Server → Cloud migration: * Define the migration scope first. Decide whether the plan is to move the entire instance or only selected projects. Large environments often work better with phased migrations. * Check app and…

Hi @Marc -Devoteam- Shall make sure in not posting answers on the solved posts and also answer within the community guidelines. Regret the inconvenience caused. Thanks

Hi @Edward Moxley Good call doing a test migration first. That’s the best way to surface issues early. A few areas to double-check: * Custom fields and field contexts alignment. * User mapping and inactive account handling. * Marketplace app dependencies. * Issue links and cross-project references. * Cleanup residual…

Hi @Melissa C Hi Melissa, That approach you’re thinking about makes sense. Having Jira trigger the workflow and letting ServiceNow handle approvals can work well, especially when the approvers are executives who won’t log into Jira regularly. A few practical things are worth thinking through while setting this up: •…

Hi @dkpatel patel Welcome to the Atlassian Community, Cloud migrations can feel overwhelming, especially when production environments are involved. A structured roadmap makes all the difference. A few key considerations: Start with dependency mapping-apps, integrations, identity, and data flows. Prioritize workloads based…

Hi @Harshveer Kaur That CloudFront 400 error usually points to a request formatting or endpoint issue rather than JSM On-Call itself as pointed out by Marc above. Here are a few things to check: * Verify endpoint URL and authentication headers (token format, content-type). * Confirm BMC Helix API expects specific payload…

Hi @Patrick Joder Welcome to Atlassian Community! Moving from Zephyr Server to Xray Cloud is doable, but test data structure differences need planning. I’d consider: Mapping test case fields between Zephyr and Xray carefully. Preserving execution history and status transitions. Handling attachments and inline test steps…

Hi @Daniel Witkowski Hi there, Yeah, this one trips up a lot of teams. Even if you’re not using Assets, the migration assistant doesn’t just check data. it validates whether the Assets capability exists in the source environment. A few things worth reviewing: * Make sure the Assets/Insight app is fully uninstalled, not…

Hi @Daniel Witkowski Hi there, That Assets validation can be confusing, especially when you’re not even using it. A few things worth checking: * Confirm the Assets/Insight app is fully uninstalled in Data Center (not just disabled). * Check for residual configuration objects or custom fields referencing Assets. * Review…

Hi @RG Exporting a full project from Jira Data Center with all fields, comments, and attachment references isn’t fully covered by the standard export options, especially if the target is Microsoft Dynamics 365. A few things to consider: * Native export limits: CSV gives you issue data but not actual attachments, and XML…