There is a rumble in the skies over the software world, with cloud technology drawing an increasing amount of attention, focus—and hype. Now more than ever, IT decision makers need to separate the signal from the noise that surrounds cloud software and SaaS, in order to make sound choices for their organisations.
And for business-critical Atlassian tools, clarity about cloud couldn't be more important.
To that end we offer this hands-on review of a tool we use for Atlassian Cloud SaaS migrations in our professional services practice, the Jira Cloud Migration Assistant. We'll separate fact from buzz, and give straight talk about what the tool does and does not offer for teams undertaking such a migration.
The changing climate of Atlassian in the cloud
Atlassian Jira in its original form was made specifically for software engineers. But as it has matured, its effectiveness for managing many kinds of work has meant that teams of all types have embraced it. And while it's easy to expect a software company to host its own Jira instance, other sorts of organisations with non-technical teams may not be willing or able to do the same.
Outsourcing the Atlassian platform can be a great solution for these orgs, via an Atlassian Partner managed service, or via Jira Cloud—a SaaS tool delivered to users' web browsers by Atlassian. While the latter has some inherent limitations, both models can help non-technical teams have an easier start with the tools, and avoid the resource investment of running their own infrastructure.
So, what if your organisation wants to move to Atlassian's Jira Cloud SaaS platform, but you already have a system hosted on-premise via Server or Data Center? Can it be moved to Cloud in a straightforward manner?
The short answer is 'it depends', and the Jira Cloud Migration Assistant is one piece of the bigger puzzle. Let's dig in to learn what it does and does not do.
Jira Cloud migration: why do we need an app for that?
The ability to move data easily is a core requirement of any software tool migration. But Jira databases are not inherently designed for this, and digging into the systems to execute a migration can be quite complex. Teams tackling it often encounter steep learning curves, and can introduce potential failure points when writing scripts and performing manual processes necessary to move Jira environments.
It's not surprising, then, that Jira migrations are often fraught with costly delays. In fact, being veterans of dozens of migrations for complex global organisations, our Consult Professional Services Team are often the ones who are brought in to get troubled migration initiatives back on track.
Atlassian is well aware of these challenges. To help, they released the Jira Cloud Migration Assistant as an add-on app to the Atlassian Marketplace in March of this year.
Key benefits of the Jira Cloud Migration Assistant
The first thing to keep in mind is that the tool itself is still quite new. It should not be judged as if it were a well-established product that has had years of development maturity. Still, its packaging is in fact its first benefit—the tool can be easily found on the Atlassian Marketplace and installed for free.
With the busy Jira administrator front-of-mind, the Cloud Migration Assistant was designed to be simple to use. It has a fairly straightforward user interface, and there's rarely a need to read its lengthy documentation. Simply select a project, click through radio box selections, and begin the data migration process. The app does all of its migration activities in the background, freeing admins to focus on other tasks.
Migrate Jira data in five straightforward steps
Though the app cannot deal with complex, interconnected projects, or with app data of any kind, it does offer a fair amount of choice in the kind of data it can migrate. This includes help with a common migration pain point: when a Jira Server instance is protected behind a firewall, the standard Jira Cloud system import cannot access attachments. The Migration Assistant, however, is an app on that very system behind the firewall. It can reach out to Jira Cloud, offering a time-saving method for safe data transfer.
Data and user migration: useful functionality
Most Jira Core and Jira Software data can be migrated using the Jira Cloud Migration Assistant, though there are limitations and caveats to bear in mind. An extensive list of what can and cannot be migrated can be found here.
Although it's possible to migrate one or several Jira projects at the same time, best practice is generally to migrate data with the Migration Assistant on a project by project basis. This avoids bringing the entire company's work to a halt, offers staged roll-back opportunities, and allows an amount of cherry-picking for what needs to be migrated and what can be left behind.
It's also important to define the migration process early on, since projects are often interconnected using issue links. The impact any broken links will have on working teams during the migration process should be understood and planned for.
To ensure data such as reporters and assignees is retained, the Migration Assistant tool migrates all of the users found in a Jira Server instance. This can cause a problem if there are too many users however, and unfortunately at the time of this writing one cannot with the current version you can't select a subset of users. One workaround is to deny nonessential users application access, thereby preventing them from being counted toward the total number of licenses used.
The Migration Assistant does have functionality to create a migration plan, but once it's been created, the plan cannot be modified or copied.
Migration planning, but no editing allowed
Once the migration is underway, the tool can be left alone to complete its work. The Migration Assistant does not require babysitting, as it does all of the important checks (such as project key clashes and missing email addresses) up front.
App assessment: some lifting required
A recent update of the Migration Assistant has added a function called the App Assessment. It checks for cloud versions of apps that are currently installed on the system to be migrated, and offers three possible status options along with links to pages containing differences in app functionality—all based on information provided by individual app vendors. The three migration status options for each app include:
- Needed in cloud
- Not needed in cloud
- Use alternative
When choosing the option "Use alternative" there is an extra page with a search field that the user can use to find cloud alternatives for the functionality they need.
The Migration Assistant will then offer to install these apps on the selected Jira Cloud instance.
While the App Assessment itself does not perform a migration action, it's nonetheless a helpful way to build a checklist for further planning, and to get ahead with installation of cloud apps on the new system.
As the Migration Assistant is still in its infancy, there is much that is not yet included. Atlassian is aware of these shortcomings—they are working steadily on the features in the product's roadmap, and a new version of the app with significant changes every three months is their release target. They are working with app vendors to address the lack of app migration functionality and to extend the tool to encompass as many apps as possible in the future.
As the Jira Cloud Migration Assistant matures and the vendor community responds to Atlassian's call, the number of supported apps will grow. Users should keep both the Migration Assistant and their Jira apps updated to stay compatible with the latest developments.
Plenty of room to grow
Those who have experience with Jira migration will likely find the Migration Assistant simplistic in its current form. There is no ability to customise the tool, nor APIs to create scripts to assist in the migration, and configuration items cannot be cherry-picked.
Only basic checks Included
The only workaround for some of this functionality is to migrate an empty project without issues to either 'and' or 'in order to' put the configuration in place before running the actual migration.
The Migration Assistant checks for duplicate users and invalid email addresses, which are simple-yet-important controls as Atlassian accounts must be unique and have a valid email address. It also checks to see whether a given project already exists in cloud, but it cannot update any pre-existing projects.
A simple tool in its current state
In our experience, the Atlassian Cloud Migration Assistant can be likened to a hammer that does one specific thing: migrate Jira projects. In its current state It is a very good hammer—a good, but small hammer, which does what it does well and without supervision.
Companies with simple, self-hosted Jira servers that use few or no apps will benefit most from migrating with the Jira Cloud Migration Assistant tool. Our recommendation is that organisations who are considering migrating, and who do not have specific self-hosting requirements such as security or regulatory compliance, consider doing it soon. If they can work with the limitations of the cloud environment and its app ecosystem, making the move to Cloud while their systems are in their current state is wise. The process is likely to get much more difficult as time goes on.
Larger organisations—those with more mature and deeply-integrated use of the Atlassian tools, and with rich customisations of their systems and processes—will still need a thorough and rigorous migration process. An individualised strategy including iterative planning, app functionality management, and moving configurations and all of the other facets of Jira systems that are outside the scope of the Migration Assistant tool is necessary if they wish to move their systems to the Jira Cloud SaaS platform.
Help on your journey
Are you looking for expert advice on Atlassian Cloud migration and as-a-service toolset options?
About the author: Krisz Kovács is a technical consultant with Adaptavist, and is currently a lead on the world’s largest Atlassian Cloud SaaS migration performed to date. Krisz has many years of system administration, QA engineering, and Atlassian configuration experience, in addition to his programming and database background. Chris is a fierce advocate of Agile and Scrum methodologies and has more recently found himself digging deeper into the world of DevOps practices.