Migrating from Jira Data Center to Jira Cloud
Migration Behavior
Feature Bundle does not support automated migration through the Jira Cloud Migration Assistant (JCMA). This is because the entire app is built on configuration rather than on its own custom data or objects, so there is nothing for JCMA to transfer.
Migrating Feature Bundle to Cloud means recreating your existing Data Center configuration natively in your Cloud instance, rather than moving data across automatically. This is also a natural opportunity to revisit those configurations, since the Cloud version offers considerably more capabilities than Data Center in several areas, described below.
Both in Cloud and in Data Center, Feature Bundle configuration is accessible in the same two places: the Feature Bundle section under Global Settings, and the Feature Bundle section under Space Settings.
What Is Not Migrated
None of your Feature Bundle configuration is transferred automatically by JCMA - everything needs to be rebuilt manually in Cloud.
| Feature | Data Center | Cloud | What this means for migration |
|---|---|---|---|
| Additional Fields (called Request View Enhancer in Data Center) | Limited field support | Much broader range of supported fields | Configuration isn’t carried over. Review which fields you currently use and whether new ones are now worth adding. |
| Customer Actions (called Edit Request in Data Center) | One edit form per request type | Multiple edit forms per request type, each with its own conditions | A single DC setup may translate into several more targeted Cloud configurations. |
| Ticket Journey (called Request Steps in Data Center) | Configurable | Configurable | Configuration isn’t carried over and needs to be rebuilt manually in Cloud. |
| Announcement Banners | Limited scope | Configurable across all customer-facing screens, with detailed display conditions and extra settings | Worth redesigning rather than replicating as-is. |
| Request Access | Fully configurable - see the Data Center Access Configuration docs | Not available | See note below - no migration path exists for this feature. |
| Time Tracking for Non-Agents | Fully configurable | Not available | No Cloud equivalent exists. |
| Bulk Add Holidays to SLA Calendars | Fully configurable | Not available | No Cloud equivalent exists. |
| Export and Import Request Types | Fully configurable | Not available | No Cloud equivalent exists. |
| Rename SLAs | Fully configurable | Not available | No Cloud equivalent exists. |
Additional notes
Request Access: Basic access restrictions are natively supported by Jira Service Management Cloud - see Atlassian’s docs on adding or removing restrictions on request types. The more advanced, Data-Center-equivalent version is currently blocked by a platform limitation and isn’t offered by any app on the Atlassian Marketplace; we have an open backlog item with Atlassian to address this.
“Not available” features: These have no Cloud equivalent at all and no migration path. If your team relies on any of them, factor that into your migration planning. If any are essential to your workflows, contact our support team so we can advise on possible workarounds.
Recommended Migration Plan
- Document your current Data Center configuration. Go through every Feature Bundle feature you use in Data Center and note down the business rules and conditions behind each one - screenshots or written notes are fine, since there’s no built-in export.
- Compare against Cloud’s capabilities. Use the feature comparison above to decide, feature by feature, whether to replicate current behavior or redesign it using Cloud’s expanded options. If your workflows depend on Request Access, plan for its absence in Cloud now and check whether Jira Service Management Cloud’s native access request functionality already covers your basic needs.
- Design the target Cloud configuration. Build it around what you actually need going forward, not a one-to-one copy of the DC setup.
- Build and validate in a sandbox. Set up a Cloud sandbox or test instance with Feature Bundle installed, configure it there first, and check each feature against the business rules you documented in step 1.
- Migrate the underlying Jira project(s) to Cloud via JCMA or your usual process - this covers your Jira data; Feature Bundle configuration is handled separately.
- Recreate and verify the validated configuration in production, once the underlying migration is complete.
- Test every configured feature end to end, from both the agent and the customer perspective, to confirm it behaves as expected.
- Review Cloud’s newer capabilities (multiple Edit Request forms, the broader Additional Fields list, richer Announcement Banner conditions) and consider whether further refinements are worthwhile now that they’re available.
- Communicate any behavior changes to end users and agents, particularly the removal of the Request Access feature.
Need Help?
If you run into any issues during migration, feel free to reach out to us any time through our support portal.