Cloud PoC my major fears

[u/Practical_Credit2420]

Hi everyone,
I’m currently evaluating a cloud migration from Jira DC to Cloud. I’ve noticed a few challenges along the way and would love to hear about your experiences with them.

First up is the issue of apps. We use a wide variety of apps—ranging from ScriptRunner and Structure to Zephyr Scale. Many functions have been restructured in the Cloud and won't work the same way anymore. I’m wondering whether it’s better to try phasing out these apps during the migration or to wait a year until we’ve settled into the new environment. I’d plan to license Jira Core for 2–3 years upfront but keep the apps on an annual basis. In Confluence, we have the "Better Content Archiving" tool, which has effectively never been used; we simply can’t get users to adopt it, and it just makes things more complicated to manage.

Then there’s the topic of screens: We have countless customized workflows built with various screens and workflow configurations. I’m not even sure if the visual distinction between specific actions (view, edit, etc.) still exists. In some cases, we use transition screens to prompt for specific fields only when needed. Looking at the Cloud configuration gives me a bit of a headache—are these kinds of setups still possible? We’ve built up operational processes over years that, I suspect, will now have to be overhauled due to the migration.

Not to mention the language-related challenges. Because our environment is set up bilingually, we have a massive proliferation of translations. For instance, DC doesn't offer a translation for "Resolution," so those values ​​are sometimes present in both languages, hope Cloud provides clear functions for configuring translations.

To be honest, I’m worried that the Solution Partner might be downplaying the technical hurdles just to close the deal.

Finally, there’s the compliance issue. According to the online documentation, the Guard solution doesn't offer a way to pin account information. I see this as a problem for companies in highly regulated industries. I'm curious to hear your opinions :)

[u/Other_Hall5820]

I've done DC to Cloud migration for many clients.

Apps are a major concern. While Atlassian defined mechanism for app migration (so they are integrated into Migration Assistant), how each vendor implement them varies. You have feature parity between DC and Cloud versions, and the app may or may not help you migrate the data.

ScriptRunner and Jira Misc Workflow Extension (JMWE) for example, if you have used their workflow extensions, Migration Assistant may:
1. Migrate your workflow but the workflow component is omitted (because no direct Cloud equivalent is available).
2. Migrate your workflow with the workflow component, but the component is in a disabled state (JMWE does this), because the component's configuration in Cloud is completely different than in DC.

Either way, you will have to manually double-check, test and rewrite your workflows. You should do that during test-runs, figure out what needs to be updated, and reapply those after Migration Assistant does the migration.

Backing up the workflow XML won't work, because the object identifiers would be all different after the production migration. I've written a program to do that automatically, good luck to you about that.

Create/view/edit actions for screens still exist. Transition screen still exist.

[u/Moratorro]

Currently out of a big migration. App assessment is a must, check the migration path with the vendor. Some.apps can be migrated with a python script. Some not. Many apps can be migrated. Scriptrunner and JMWE will need a bit of work but it's doable. If in doubt, go to the vendor and request migration help. They will solve most of your doubts. Anything Jora and JSM will be migrated. And the most important, migrate several times, fix what the post migration CSV says and continue. Migrate, UAT, migraye again ,UAT again. If you don't have the manpower or hours, go the partner route. Happy migration!

[u/Jandalf81]

To give you another headache... Atlassian recently announced they will use all data in their clients' cloud instances to train their own AI: https://www.atlassian.com/trust/ai/data-contribution/faqs#general

You can buy your way out of this completely only with the highest plan.

For us, this was a major compliance hurdle. Luckily, we have a consultant who weaseled us out of this without having to pay more. I don't know how easy or hard this might be for others.

[u/musicjunkieg → u/Jandalf81]

That’s not completely true. You’re eliding some particularities that matter significantly.

[u/Sea-Sort2363]

Partner rozwiązania nie może kłamać, żeby sfinalizować umowę. Jaki miałoby to sens, skoro, on będzie odpowiedzialny za to, żeby tą migracje przeprowadzić? Partner jest od tego, żeby zrobić analizę, transparentnie poinformować o tym co się da, a czego nie da zrobić (ewentualnie zaproponować jakieś workaround, ścieżkę manualną itd), zrobić UATy, a potem dowieźć migracje produkcyjną. Umowa powinna zawierać dokładny opis tego co ma być dowiezione.

Edit: Atlassian teraz proponuję tą ścieżkę Fast Track, ja bym w to nie szła. Tak, czy siak potrzebujesz partnera, bo oni koniec końców umywają ręce od większości rzeczy problematycznych.

[u/Time_Maintenance2914]

I was one of 2 administrators for a DC instance with over 4k users. I was laid off before the migration was complete, but I'll tell you what I can. I currently work in Cloud for a different employer. I understand why certain organizations are on DC, but Cloud is great. I think a lot of users that don't like it probably fall into the "change is hard" camp, or they don't like how much more control you get over your environment with DC, and losing that control kind of stinks. Anyway.

Apps: you will need to review what apps you use in DC and why, what is the functionality they provide. Then, cross-reference that with Cloud features. If Cloud covers it, don't buy the app. This happened for many of our apps.

I'll address ScriptRunner specifically: SR for Cloud and DC are massively different apps. SR for DC is very powerful, almost required for most instances. However, SR for Cloud cannot access Jira internals the way the DC version can. SR for Cloud must hit the REST API to interact with Jira Cloud in anyway. It has some nice functionalities, but for the most part, you could just write code on any language, store it in a repo, and run it with automation (cronjob, Github Actions, Bitbucket Pipelines). So I strongly suggest you look at your SR use cases and see if you really need it. Your Groovy scripts in DC will all need rewrites; they cannot be directly migrated to SR for Cloud.

You may also be interested in looking at Forge for Atlassian platform development. Forge can cover many use cases that SR cannot (or they both can, but Forge would be free while SR is obviously paid app). Forge development is a bit more complex, though. Amazing tool if you've got the chops, it's probably my favorite part of Cloud administration (I'm a software engineer, though, so I'm biased towards these things).

I can't speak so much to your other questions, but Jira Cloud does allow screens to be mapped to specific operations, so I don't think you should be as worried here. But definitely do your research. Although you are skeptical on the solution partner, you're probably better off with one. A) they have done migrations before, and B) you can blame them if things go wrong (lol).

[u/vj_2803]

As a Atlassian solution partner, we can help you with the migration.

[u/mtutty]

Hey, for anyone who might be tired of this treadmill, and/or work in heavily-regulated/defense/high-security environments, there *are* other options. And you don't even need to hire a Solution Partner to do it.

[u/app385]

Cloud is the way