Prepping for your Atlassian Ground to Cloud Migration

For the past year, Ground to Cloud migrations have been the hot topic for anyone in the Atlassian ecosystem now that they have announced the end of life for their on-premise Server deployment option. So, as an Isos Technology Solution Engineer, I have spent the past year discussing this type of move with dozens of customers and prospective clients. In this blog post, I'll cover the top things Isos, as a Platinum Enterprise Solution Partner, likes to discuss about Ground to Cloud migrations.

Know Your Environment

This might be a no-brainer for some readers, but not everyone that has conversations with Atlassian partners about migration services is the person most intimately familiar with their Jira instance. Ground to Cloud (G2C) migrations introduce several layers of complexity involving third party apps from the Marketplace, instance customizations, external integrations, and underlying product differences between the deployment options. This complexity therefore implies risk when considering a move to the cloud, and that risk is something we like to consider and quantify when estimating the level of effort needed to take your environment into the cloud.

The primary factor in determining level of effort is volume of your instance for each of your products, which is something we can most easily ascertain with the System Information page of each product. You can find that Sys Info with these quick steps, as it resides in the administration settings of each product. However, keep in mind that this will include everything about your instance, and if your organization doesn't want all the historical data, or has unused third party apps installed, that is something you should make your solution partner aware of during your conversation, since we can exclude parts of your instance to reduce overall costs of the move.

With that in mind, we often request additional information alongside your System Information to give us context about your environment. This typically includes a prioritized list of apps so that we don't add unnecessary hours to migrate apps your team doesn't actually use. We also ask about any customizations and external integrations you have and will still need in the cloud, so we can recreate or migrate those to the new environment. Sometimes functionality that you have had to add to your Server or Data Center environment comes natively in the Cloud product, so making us aware of all of those instance quirks can also cut down on costs.

Have you thought about User Management and Authentication? It works a bit differently for Atlassian Cloud products than it does on-prem! Crowd is the traditional product for on-premise SSO and user management, whereas in the cloud, Atlassian Access is that product. Access will allow you to manage, provision, revoke, and approve users and their access to your product suite, as well as integrate with several IDP SSO providers such as Okta and AzureAD. We recommend all companies moving to Atlassian Cloud include an Atlassian Access implementation to help them seamlessly manage their users. 

Understand the Process

The amount of complexity to a Ground to Cloud migration cannot be understated. As mentioned above, third-party apps and customizations/integrations are the largest factor in said complexity. Apps that exist on Server or Data Center may not have a Cloud version; the cloud products for Jira, Confluence, and Bitbucket are entirely different code bases than their on-premise counterparts, and require entirely different versions of their vendor apps.

Some app vendors on the Marketplace have created Cloud equivalents, and also participated in Atlassian's call to create a migration path for their apps to move to the cloud, but not all of them have done this. This is a big reason why we like to narrow the scope of the migration to the apps that are critical for the work you do in Jira or Confluence. We will often have to either create our own scripts to migrate your apps, manually recreate what you have on server, or migrate your server app functionality to another cloud app that is similar in functionality.

The process for moving each app differs since they are all unique in development, and the process for each is continually changing, usually for the better, making it easier to migrate along with your Jira or Confluence data. That's all to say that the app migration process, and estimation process is complicated. We are constantly updating our "t-shirt" sizes for each app we migrate to make our level of effort estimates as accurate as possible.

That said, our migration process is a comprehensive journey to ensure that your product data and third party app data come over to the cloud in the cleanest and quickest way possible, and to prevent any loss of data, functionality, and up-time for your users.

We often recommend a Cloud Readiness Assessment for our customers who have more complex environments, several products, or lots of apps with lots of data. That way, we can have an extended discovery session and really dig into how you use your apps, requirements for your external integrations, and functionality of your customizations. The assessment will give us a detailed view into what we will need to move over, and allow us to create a unique plan for your environment. That results in a more accurate proposal for the migration itself. For those of you with pretty standard out-of-the-box implementations, we often don't need to look much deeper than your System Information to estimate your move to the cloud.

The Plan phase is part of every migration, during which we sit down with your stakeholders or migration project lead and develop a detailed, comprehensive plan for the migration. We will also loop in Atlassian's Cloud Migration Managers, who are involved in all migrations to the cloud to ensure everything goes smoothly.

The Prep phase is all about preparing your current on-premise environment and data for transport. If needed, we will upgrade your products to the latest long-term supported version during this phase. Primarily, this phase consists of workflow and scheme grooming (data grooming) and user/data mapping to align your data to the cloud environment.

This is an activity our clients often ask to tackle themselves to reduce costs if they have internal resources who are familiar with their data. We frequently see instances that have duplicate workflows, issue types, custom fields, etc. that could be unnecessary data we don't actually need to move to the new cloud environment. This is a great opportunity for companies to clean up their messy data and start with only what they really need in their new Atlassian Cloud home.

The Test phase is the longest part of our migration process as it involves several rehearsals of the migration with our engineers, User Acceptance Testing (UAT) by the client teams, and Data Validation and Acceptance before the final cutover (Migrate phase). Rehearsal time is dependent on complexity of your migration and volume of data and often takes a few rounds to ensure we have nailed down the process. UAT is a collaborative effort between our team and yours to ensure that all the data mapping, grooming, and ultimate migration looks how it should, and there wasn't any data loss or improper transformation during the process. We also do one last round of Data Validation and ask the client to check our work for final sign-off before pulling the migration lever.

The Migrate phase is pretty intuitive, as it is when we do the true migration to your new production Atlassian Cloud environment, and is the only real downtime for the migration. This will typically happen over a weekend, or whenever your teams have the highest tolerance for downtime. We will work with your teams to determine the best time for that tech window to occur.

The Launch phase is post-migration during which we can optimize your cloud environment, train admins and end users, and provide best practices and guidance around using the tools and scaling your instance in the cloud. We have enthusiastic and knowledgable expert trainers administering Atlassian training classes, as well as our own Isos Training Curriculum and unique to your team custom Learning Paths to get you up and running in your new home.

Finally, the Cloud BAU phase is for on-going support once you've settled into your cloud environment. We offer instance Health Checks for all of our projects, Managed Services to help grow and expand your instance, and License Management to take all the pressure off of you when it comes to navigating the gauntlet of Atlassian Cloud product licensing.

Talk to a Solution Partner 

This undertaking may seem daunting, as it involves a lot of moving parts, risk factors to consider, and unknowns to worry about. Luckily, you have experienced Solution Partners to leverage for your migration to Atlassian Cloud  and veteran engineers who can help you avoid common pitfalls.

We highly recommend reaching out to a partner to learn more about the process and to get a quote for your Atlassian Ground to Cloud migration. We find that a lot of clients underestimate the difficulty that these migrations pose, so keep in mind everything I've discussed in this post. I am sure any partner will ask you about each of these parts of your environment before giving you a proposal or SOW for the work.

Come prepared to the meeting! Have your System Information pages ready. Know what apps you want to migrate. Have an idea of what kind of customizations or integrations your current environment has that you will also need in the cloud. Know which cloud products you may need alongside your current products (Access *cough* ).

To close out, I want to share a matrix I put together for high-level understanding of the complexity of your migration. We have general ballpark costs that go along with these colors, so reach out to a sales rep from Isos on our website if you are interested in starting a conversation about a migration.

I hope this gave you some valuable information and context! Thanks for reading!