Atlassian Cloud Migration

First of all, we need to understand a bit of the history of Atlassian products.  15 years ago, there were no different offerings for Atlassian tools - it was a single, monolithic Java application running with a Tomcat webserver, that you would host on your own hardware¹ - what we would call Atlassian Server today.  In 2011, everything changed with the release of Atlassian On-Demand.

On-Demand was Atlassian's first foray into what we'd now describe as SaaS, and as you'd expect from a first foray, it was not without its issues.  At this time, Atlassian would simply host the same version of the Atlassian tool that you would download and host yourself.  Although broadly fulfilling the role, it exposed Atlassian to challenges in scalability, alongside challenges exposed by the Spring-based Plugin system that is prevalent even today across Data Center Apps.

In 2014, it was time for a refresh, and Atlassian refactored their offering and rebranded as the Atlassian Cloud we know today.  This was the point that the codebase for Cloud really started to diverge from the Server and Data Center offerings - the biggest change of course being the removal of Spring-based Plugins, and the introduction of Connect and subsequently Forge-based plugins.

We are now 11 years on from the original forking of the Atlassian Cloud, and the tools are not just technically different, but visually and even functionally different at this point.

¹Strictly speaking, there was also Confluence Clustered - the first pass at what would eventually become the Atlassian Data Center product today.

Effectively, although the products provide the same broad function, and are provided by the same developer, the Atlassian Data Center (or equivalently Server) products are, in some ways, very different products to their Atlassian Cloud siblings.

Some differences are very obvious - for example, given the differences in the App ecosystem between Plugins v3 on Data Center and Connect and Forge on Cloud, there can be dramatic functional changes in Apps between the two.

Taking the ever-popular ScriptRunner for Jira from Adaptavist as an example, on Data Center, you write Groovy code which runs within your Atlassian application's Java Virtual Machine, and interacts directly with the Java APIs, allowing for near-limitless functionality - including allowing your custom code to run arbitrarily within the normal activities of the system, for instance pausing the rendering pipeline when loading an issue, and executing a custom Condition.

On Cloud, ScriptRunner primarily uses the Connect framework¹, which is inherently asynchronous.  Your Groovy code is run on Adaptavist's servers, and your Jira Cloud instance is interacted with asynchronously through REST APIs.  This comes with many advantages - not least limiting the negative impact of code on your system's performance - but also significantly restricts the functionality of the tool.

Some differences on the other hand are more subtle, but have the potential to have a much broader business impact - for example, the way that Boards function across the two tools has some dramatic implications.

On Data Center, an agile Board is an independent object - when created, they have no parental link to any other object in the system, with the exception of the implied link provided by the associated Filter.  This enables teams to work across projects without being associated with any given project, which can be very useful depending on the setup of your business.

On Cloud, when created, a Board must have a parent object - either a Project or a User.  With User typically being used for personal boards, a Project association is by far the most prevalent choice.  Although broadly not impactful for day-to-day usage, for teams with matrix-style associations between Teams and Projects, this can be problematic.  The User Interface will associate a Board with a singular project, and with the recent (and exciting) implementation of the Teamwork Graph to support Atlassian's growing AI tooling, this could have significant impacts on the quality of the information provided by Atlassian's AI offering as a whole.

¹It should be noted that the Behaviours add-on for ScriptRunner utilises Forge.

Well, yes and no.  The reality is that for the majority of customers looking to migrate from Server or Data Center to Cloud, everything that's been said above will have a really limited impact on the day-to-day usage of the tooling.  Most Atlassian estates are relatively small, allowing for more agilility in making changes to align to Cloud paradigms, and haven't been configured and customised to exploit the full power of the Data Center platform.

For those that either have large or complex Atlassian estates, however, this can seem overwhelming - the path in front of them has moved from a simple Cloud Migration Assistant journey to what might seem like a complete platform change.  Why should a company in this situation even consider moving to the Atlassian Cloud in the first place?

If a Cloud Migration appears complex, this can be seen as an opportunity to refresh and renew your Atlassian estate to better align to your current business needs.  Not only can this approach simplify and streamline the users' experience of the tools, it can actually reduce the cost and impact of a migration process.  By taking a step back and analysing what the business needs are for the tooling, a design can be produced that not only supports business process, but also aligns to the modern Atlassian Cloud paradigms.  Change Management costs can be reduced by actively engaging with users through the analysis and design process, and teams can be working with a tool that supports their day-to-day activities rather than gets in the way of them.

The team at Echidna Solutions have had immense success with this approach across a wide range of businesses - from small, complex businesses to some of the largest users of Atlassian tools in the world.  Contact us for a discussion, initial analysis, and a quotation.