Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Migrating to Jira Cloud? A few things worth adding to your checklist

Hi all,

We've been talking to a lot of teams planning their move from Jira Data Center to Cloud, and there's a pattern: most migration plans focus on data, permissions, and workflows themselves, but app parity often gets checked late, sometimes after the migration is already underway. By then, teams discover a feature they relied on daily simply doesn't exist on Cloud, and there's no direct swap waiting for them.

Here are a few things worth checking early, based on what we've seen come up repeatedly.

  1. Check which of your apps have no Cloud version at all

Not every Data Center app made the jump to Cloud. Before you migrate, pull a list of every app your teams actually use day to day (not just the ones in your admin panel, the ones people actually open) and check each one's Cloud availability individually. Don't assume a popular DC app has a Cloud equivalent just because the vendor still exists.

One example we run into often: Help (Conditions Validator) doesn't have a Cloud version. If your teams use it to see which workflow conditions are met before attempting a transition, that visibility disappears on Cloud unless you plan a replacement. More on this below since it's a common one.

  1. Look for feature parity gaps, not just missing apps

Sometimes an app does exist on Cloud, but it's not a one-to-one match. Features get dropped, rebuilt differently, or moved into a different pricing tier. This is easy to miss because the app "technically" migrates, so it doesn't show up on anyone's radar until users start asking why something looks different.

  1. Re-check your access and permission models

Cloud and Data Center don't always handle visibility and restrictions the same way. Some apps that restrict by group on Data Center switch to project roles on Cloud, or vice versa. If your permission setup is more than a few rules deep, it's worth mapping the old model against the new one rather than assuming it will carry over cleanly.

  1. Test the actual user workflow, not just the admin config

Migrations tend to get validated from the admin side (did the workflow transfer, do the fields exist), but the real test is what an end user sees when they try to do their job. Have someone walk through a real transition, not just check that the workflow scheme imported correctly.


Back to that Help (a.k.a. Conditions Validator) example

Since it's one of the more common gaps we've seen, here's a bit more detail in case it's relevant to your setup.

On Data Center, Help shows users a clear view of which conditions are met or not, right in the work item, along with the full ALL/ANY condition tree and status indicators. Without a replacement, Cloud users just see a transition button that doesn't work, with no explanation why.

Our cloud app, Workflow Building Blocks covers the same ground (conditions visibility, ALL/ANY logic, status indicators) plus a bit more, like validators and post-functions through a visual editor, checks against linked issues or hierarchy, and automated actions on transition.

WBB Help (1).png

Conditions Help in Workflow Building Blocks for Jira

It's not a perfect match though. A few Help features don't have an equivalent yet (Transition Description, Hint Button, Status Descriptions, Custom Button Colors), and access management works differently (project role instead of project/group). Worth checking if either of those matters for your setup.

If it's useful, we put together a full feature comparison here.

Curious if others have run into similar parity gaps during their migration, happy to compare notes.

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events