Tips for Migrating Jira Server to Cloud as an Indie Dev: Handling Custom Workflows and App Data?

[Bunny]

I'm an indie mobile game mod developer (running a small site with 10K+ users for racing tweaks—CarX Street Mods), and we're finally ditching our ancient Jira Server instance (v8.20.5) for Cloud Premium. With Server EOL long past, it's time—especially since our custom workflows for bug tracking mod releases and user feedback tickets are getting clunky on self-hosted.

We're a lean team (me + 2 freelancers), so a phased migration makes sense: Start with users/groups, then data via JCMA. From Atlassian's guide, I know to test apps first (e.g., our ScriptRunner for automated permission audits), but what's the real-world gotcha for devs like us?

• Workflow Mapping: Our server has mod-specific schemes (e.g., "Drift Bug → QA Test → Release"). How do you recreate these in Cloud without losing automation? CCMA for Confluence pages too?
• App Compatibility: Migrating to Forge apps—anyone swapped Server plugins for Cloud equivalents without downtime? Tips for 1000+ historical issues?
• Data Cleanup: Pre-migration checklists mention archiving old data—how much is "too much" for Cloud performance? We're at ~5K tickets.

Planning a test run next week with the free migration trial. Grateful for any phased strategy tips, especially for solo admins—phased vs. big-bang? Tools like MAGIC for small sites?

Thanks in advance—excited for Rovo AI in Cloud! #JiraMigration #ServerToCloud #IndieDev

[Trudy Claspill]

Hello @Bunny 

Welcome to the Atlassian community.

I'll start with the easy question.

~5k issues is not a large amount of data for a Jira Cloud environment. I've worked server/DC to cloud migrations that involved millions of issues. There will be no noticeable performance impact based on that number of issues.

When you talk about workflows, the JCMA tool will automatically migrate your workflows including Status values and transitions. Customizations in your workflows that use functionality from plugins will have to be evaluated; some may migrate and others may not. Some may require pre-migration work. Most plugins provide feature parity information which you can find on the Support tab of the Atlassian Marketplace listing for the app. There is often also a link to documentation about if the plugin data can be migrated, and what steps are required to do that.

Due to the radical infrastructure differences between server/dc and cloud some apps cannot provide the same functionality in Cloud that they could provide in server/DC. In server/DC the plugins are usually installed directly on the same host as the Jira software and have access to all the files and database. That is not the case in Cloud. Apps are more limited in how they can access the Jira data; through APIs and the Forge platform.

I recommend that you carefully review the documentation provided by each app vendor.

Plan to do multiple migration tests. I usually like to do at least 2 migration tests to incrementally reveal and rectify problems and adjust my migration plan.

Plan time for testing the functionality following a test migration. Plan to test the plugin functionality. Make sure you identify and test any integrations with other apps such as source code, build, and deploy systems.

Be aware that if you are migrating things (i.e. schemes, fields, screens) for which a thing with the same name already exists in your Cloud instance, then a second instance of that thing may be created with "(migrated)" added to the name. This can be more impactful if you are migrating projects in phases.

There are Atlassian Solution Partners that specialize in Cloud Migrations (including Praecipio, for whom I work). You may want to consider reaching out to one to help you with you cloud migration assessment and planning.

[Ignacio Vera]

Hi @Bunny 

My suggestion is that if you’re not 100% sure how to do it, hire a partner to handle the migration.

If the budget doesn’t allow that, I recommend doing it all at once and involving a few key users for testing. Migrating 5k tickets is not considered a complex migration, especially since you only mentioned Jira.

I’m not sure what you meant about the Forge apps: do you have custom plugins developed for your company? If so, then yes, you’ll need to adjust them.

Also, make sure that all the ScriptRunner functions you use on Server also exist in Cloud, because sometimes they don’t.