Skip to main content

Migrating Adaptavist Plugins

Looking for tips, advice and FAQs about how, where and when to migrate your Adaptavist apps? We've pulled together resources to make it easier to find what you need.

Migrating Adaptavist plugins

A word from our Head of Product Management, Adam Wignall

We understand there are a lot of challenges for those facing migrations away from Server, so, to make it simpler, we've tried to pull together all the things you need to know when you’re making your plans.

We’ve split the information out into sections for each product to help you find what you’re looking for fast. We've included the questions that we get asked most frequently by migrating customers, links to relevant documentation, and any events (such as webinars) that might prove useful.

We don't assume that you're headed to Cloud: we know that it's not for everyone. It's our intention that the information in this section helps you to explore your options on whether Data Center, Cloud, or a hybrid of the two is the best fit for your organisation.

We hope it helps.

Adam

Adam Wignall, Head of Product Management at Adaptavist

FAQs

These are broad questions that we get a lot about migrating apps. To see FAQs about specific plugins, such as ScriptRunner for Jira or Content Formatting Macros for Confluence, head here.

  • Definitely! For instance, each ScriptRunner app has a dedicated team working to improve it at all times: we have no intention of stepping off the gas for those who are staying on-premise. 

    After Atlassian officially sunsets Server, any new features developed for on-premise environments will be deployed to Data Center only.

  • This really depends on the size of your migration and its complexity.

    For some instances it can take just a few weeks, whereas for large-scale, complex migrations, it can take months. In general, we always advise a good cleanup before a migration to minimise what you take across. If you’d like to discuss an upcoming migration project, speak to one of our experts.

  • This is almost entirely dependent on the complexity of your instances and setup. If you have very few customisations, it can be a relatively quick transfer, but if there’s significant customisation then this will take more planning and consideration.

  • You have several options for connecting your new Cloud instance to external systems, so you may wish to get a third party involved to look at this and advise on the best approach. Connecting external systems usually involves some level of refactoring, and you might want to consider tools that help you connect across ecosystems. Our experts are on hand for advice if you need them.

  • We get this question a lot and it is a totally fair one, so here's why there are clear differences between our Cloud and on-premise products:

    The first factor is product maturity: our apps followed the same trajectory as their Atlassian counterparts. On-premise solutions like Server and Data Center came first and were the obvious market preference for a long time as Atlassian Cloud grew its capabilities. 

    Naturally, then, we began to recreate your favourite apps on Cloud as Cloud itself became more established. This development has been steered by your feedback about the features you most wanted to see on Cloud, and what they should look like. In some areas, we are still playing catch-up, and your feedback continues to inform our priorities.

    The second factor (which has occasionally slowed us down on this catch-up) is that Atlassian Cloud infrastructure is totally different to Atlassian on-premise infrastructure. Key differences in access points and technologies on Atlassian Cloud means that we have had to build the same features in different ways: it hasn’t been as simple as mimicking what we already had and we are working daily with Atlassian to make sure we can deliver any outstanding features.

    Please see each product below for a full feature comparison and details of how you can give us feedback on what you most want to see arrive next on Cloud.

  • Sadly, no. You’ll have to rebuild these on Cloud because the Atlassian Cloud products are different to their Server/Data Center equivalents. We offer a Scripting Service that may be able to help take these plugins across.

  • This might be possible depending on exactly what your plugin is doing. Find out what is possible with Forge in its current version here.

  • This depends on your tier. On Jira Premium and Enterprise you can get a sandbox environment where you can clone production data and test changes in a safe environment. If you’re on the standard plan, consider spinning up a new, free instance where you can test setup and configuration.

  • When using the Connect development framework, you can follow the Atlassian guide here to deploy an app or plugin. It’s also worth noting that Atlassian is working on a new development framework, Forge, that you may want to consider using for development and deployment of your plugin.

  • This depends on the plugin. Some host all of their data in the Atlassian product, and hence follow the same rules. However, many apps host the data on their own machines. ScriptRunner for Jira Cloud is a good example of the latter, although it does offer data residency in certain regions for new customers (soon to be available for existing customers, in more regions).

Webinar

Upcoming webinar: Migrating ScriptRunner for Jira to Cloud

Are you thinking of migrating from ScriptRunner for Jira Server or Data Center to the Cloud version? Would you like to know what you can do on Cloud? Or maybe you're unsure how you should go about migrating? Then this webinar is just for you!