More and more customers are grumbling about the complexities of managing multiple app-specific dependencies when migrating app data during Server->Atlassian Cloud migrations. Migrating core product data is scary enough without also having to juggle app migration.
The question is: Should Atlassian develop a general migration framework that invokes vendor-supplied export and import end points, orchestrated by the Atlassian “Migration Assistants?” Or would that be expensive overkill? As Marketplace vendors we’d love to hear from you.
My preference would be for there to be a document (Atlassian hosted) where vendors can contribute contact information, basic steps, and a link to vendor provided documentation on migrating from server to cloud. This would be similar to the document where Atlassian is recording which apps/vendors are ready for the site rename facility.
It sounds very beneficial to customers to offer that level of simplicity. I think that will also require some sort of designation / certification that a vendor has implemented those endpoints - so customer can easily identify the apps which support the migration.
One of the other complexities we see in these migrations, is when something doesn’t happen as expected by the customer, it can be very difficult to coordinate the support or engagement across Atlassian and App Vendors and pinpoint what may have gone wrong. I think the supportability of the migration path is another key open question.
BUT please be aware that it would have to be version dependent. Is somebody could have been running a version that is 6months old. During that time the cloud version has moved on and the info that might have been uploaded might not be enough (ie the user would have to upgrade the plugin to the latest version.
OR in some cases - the upgrade might not either work or be possible at which point the framework needs to show the appropriate steps.
Unlike Atlassian we don’t necessarily have all of that knowledge ahead of time (the version matrix would be insane - just thinking of the version combinations possible on jsw).
All of that said - if we had a module type that could define an interface where we can just handle the upgrade bits (with some type of transaction support over http) it would make it a lot easier for vendors to support. If this existedthen this would also be an awesome way to embed instructions for when manual interventions would be necessary (ie don’t have an external webpage).
The other gotcha though is (like I mentioned up a bit) is that we’d probably need to have an opt-in list for various versions - ideally on the marketplace so that we can easily kill the support on a per version basis after release (also has the benefit that you can use that to flag to customers about support).
For me, most of my server apps can’t run on cloud because of the feature set discrepancy. For one that can it would time consuming for a small company to develop. You have different versions, like @danielwester said, plus try to map user names/keys to account ids. All this seems like a lot of work to support.
What was presented at AtlasCamp 2019 sounded like a positive direction to go in, but I think some of the finer details may take some time to finalize like how partial migrations (e.g only one or two projects) work.
I can imagine customers wanting control of what “config” they want to migrate from each app, so the possibility for some kind of app-specific export UI may be necessary.
It looks like other partners already spend a lot of thoughts and know most of the pitfalls.
Honestly - we didn’t
Is there any documentation how a typical Server to Cloud migration (without apps) looks like?
What will be the same and what will be different?
E.g. will it keep the same issue keys & ids?
Yes. If Atlassian is serious about bringing Server customers to the Cloud, then a smooth migration experience for those customers is critical.
Currently customers moving from Server to Cloud have to reconfigure everything for a lot of apps. For other apps, the procedure depends on the app vendor, but can be quite different for each of them. Not only missing feature parity, but also the efforts required for the migration can be a serious obstacle to move to Cloud.
We should think from a customer perspective: It would be much easier if the customer could start the migration directly from within Jira/Confluence/… Then Atlassian together with the apps vendor are taking care of all the details behind the scenes. This certainly does have a fair amount of complexity, but I think it’s doable and worth the effort. The migration framework outlined so far does have the potential to get us there.
In addition to what was already said, I’d like to point out two major constraints:
migration needs to be incremental - i.e. it cannot be a one-time migration, but rather a smooth, incremental synchronization of configuration and data between the source Server instance and the destination Cloud instance. The reason is that migration takes a lot of time, and you cannot stop your source Jira while you’re implementing all the required changes on the Cloud
workflow migration needs to be supported. Jira Server/DC customers, especially the larger one, have customized their workflows using multiple third-party apps that offer workflow extensions (Conditions, Validators and Post-functions). To be able to migrate to Jira Cloud, they need their workflows to continue working the same way. This obviously requires having the same apps being available on the Cloud, but it’s not enough.
First of all, API and architecture differences mean that not all Server workflow extensions can be ported to the Cloud, and when they can, they might have to work very differently. But also workflow extension configurations are different between Server and Cloud. It starts with condition, validator and post-function class names that are different. It goes on with configuration format (multiple params vs. a single JSON param). And of course, because of API and architecture differences, the configuration themselves need to be adjusted, sometimes very extensively.
Let’s take for example a simple “point-and-click” (no scripting) Condition. The classname will need to be changed (because Jira Cloud uses a single “adapter-style” Condition class, instead of using an app-provided class on P2). The <param> elements will need to be morphed into a single JSON configuration string. But also, the Jira expression that implements the Condition will need to be generated and saved into the JSON configuration, because that’s how Cloud Conditions work.
This means that any Server-to-Cloud migration tool needs to be able to re-configure workflows, and use app-provided code to adapt the configuration elements during the migration. Also, this app-provided code cannot rely on writing to the Cloud workflow since there is no REST API to modify workflows.
Finally, there will always be a lot of manual workflow adjustments / reconfiguration to be done, especially if you used any kind of scripting (e.g. ScriptRunner, JMWE, etc.) because the languages and/or Jira APIs are different and thus the scripts need to be re-written.
For our apps that we have for Cloud and Server/DC now, the implementation of the envisioned migration framework/architecture would be do-able, it would be rather straightforward, which doesn’t mean there’s not a lot of effort in it. So the question is if or if not enough customers would go down that route - not only with regard to our app, but in general.
In our specific case, I’d say it depends. Right now we have been in the lucky situation where we would not need an app migration framework. Relevant data is stored in entity properties - so simple export-import should capture those.
One problem we noticed though is that Server and Cloud implementations are drifting apart and this may make an app migration framework necessary for us in the future too. Specifically, indexing array entity properties stopped working in Jira Server 8.x which forced us the change the data format in the Jira Server implementation and therefore making migration more difficult.
Ultimately, I’d say an app migration framework is for the benefit of customers and vendors if it can account for the different requirements from most vendors.
