Merging two or more Atlassian instances is a big undertaking, and it's important for businesses to understand what they're getting into before embarking on this complex initiative. To help prepare you for these "merge migrations," the Isos Technology team has rounded up all our cloud-related resources and put them in one place—our Cloud Resource Center.
In the Isos Cloud Resource Center, you'll find links to recorded webinars, whitepapers, and blog posts on Atlassian Cloud...plus, you can even take a Readiness Quiz to evaluate how prepared you are to move to the cloud.
We've also pulled together some best practices that will help you prepare for an Atlassian merge migration. We've included them in both the video below and this blog post.
In order to prepare for a merge migration, the first thing you should do is move your organization off of default schemes. And that’s true for any Jira instance, whether you're doing a merge migration or not.
The reason, in this case, is that by doing a migration, you may run into collisions when different Jira pieces come together.
Default schemes are one of the first things we look for in any organization’s configuration, and we advise moving off of them right away.
The second best practice is to upgrade your tools. When you go to the cloud, you'll automatically be switched to the most recent version of the Atlassian tools.
Even though the upgraded version of a given tool will be different than what you may have on your server, it will still be closer to the version in the cloud. Moving all your tools to the most recent version is a standard procedure prior to any migration.
The next step to prepare for a merge migration is to prioritize Jira projects and spaces.
This often has to do with the time constraints of a migration. Let’s say that you have to move your data over a weekend, for example, because you can't afford downtime during the week. The migration may take more than two days, however, so you’ll need to decide the projects that need to move first.
Also, it’s important to find and confirm the owners of those projects. Even if somebody is listed as a project admin, they may no longer be responsible for those projects or may no longer be with the organization.
You'll need people available who know the projects you're moving well. And the same goes for Confluence instances.
Further, make sure to prioritize which personal spaces and global spaces have to move first. Identify current owners, especially for global spaces. Personal spaces include names, but you’ll still need to determine if the people with personal spaces still work for the organization and if they need it.
The next step is to identify critical third-party apps inside of Jira or Confluence that you need in the cloud. All of those apps’ functionality, or even availability, might be different in the cloud.
After identifying the apps, we do an analysis to evaluate what it will take to move, which is very important. Over time, some apps may no longer be in use, or they’re being used by just one project or one space.
The app analysis is key because you’ll have to decide what apps to keep. And how that will affect the migration. To learn more about migrating apps to Atlassian Cloud, check out our whitepaper on this very topic.
Another common obstacle with Atlassian Cloud migrations is a lack of communication between IT and Risk Management or Information Security (InfoSec) departments. It’s important to loop them in before migration because third-party apps work differently in Cloud than they do on Server. For example, in Server, the computation and data transfers all occur on your instance. In Cloud, complex computations have to happen on third-party app servers.
We've seen many security departments veto apps because they don’t want to share proprietary data or because a vendor doesn’t have the certifications necessary for compliance.
It’s always important to check on compliance standards early, and they vary by industry. Financial organizations have certain standards, for example, whereas education organizations might have different compliance needs.
Failing to review these standards early can cause significant problems. We’ve seen weeks of Atlassian merge migration work wasted because somebody finally notifies the Risk Management department about the change, and the entire approach has to be revised.
In short, make sure that your Risk or InfoSec teams are aware of your migration, because they may have to review the process for compliance concerns.
The complexity of an Atlassian merge migration can vary depending on different variables, the first of which is the number of instances being merged.
Most migrations are two into one, or three into one. But you can also have multiple instances in your organization that have to be merged into one final destination. And the number of instances can have a significant impact on the timeline of the migration effort.
Within those instances, it takes time to move each component to the destination, whether it be the cloud or on-premise. And the length of rehearsal time, as well as the number of iterations to prepare for those migrations, can be a factor, as well.
One of the other significant factors, especially when moving to Cloud, is the number of customizations that you have in your environment. And that's anything that you've done to make it your own and useful for your team, such as:
Some apps have a really clean migration path that we can follow. Some, however, don't. And those require a lot more effort to ensure that no data is left behind during those migrations.
This is one place where Isos’ experience in merge migrations comes into play. We’ve had experience with many third-party apps through other migrations, and we use that experience to speed up the process.
Looking for more information on implementing Atlassian merge migrations? Click here for Isos’ Cloud Resource Center.