Assessing apps for cloud migration

More customers are making the switch to the Atlassian Cloud as the differences between the Atlassian Data Center and Cloud feature sets continue to grow. An increasing number of features are being developed exclusively for Atlassian Cloud, which will not be available in on-premises versions. Additionally, improved security and data residency solutions are making the transition to the Cloud easier. As a result, the barriers to moving to Atlassian Cloud are gradually diminishing.

As teams embark on their journey to Atlassian Cloud, one of the most common questions that arise is, “What should we do with all the apps and integrations in our Data Center instance?” While this is just one of many considerations when preparing for the move to Cloud, let's focus specifically on a proven app assessment process. Apps and integrations typically fall into the following classifications:

• 3rd party apps that were acquired on the Atlassian Marketplace

• Homegrown Apps made specifically for Data Center by your internal engineering teams

• Integrations that connect Atlassian tools to 3rd party tools using off-the-shelf technology via either the Atlassian Marketplace or directly from another vendor

• Integrations built internally by an engineering team, typically utilizing WebHooks and/or APIs to connect

Phase 1: Preliminary assessment

When assessing the ability to move functions to Atlassian Cloud that your teams may depend on, there are 4 key steps in the preliminary Assessment process by-product (Jira, Confluence, etc.):

Step 1: Catalog Apps/Integrations installed on the source product, identify the Supplier, create a link to the product page if applicable, and identify as an [App] or [Integration]

Step 2: Classify whether each item cataloged is a 3rd Party Commercial product, or Homegrown

Step 3: Assess team usage (High, Medium, Low), and use cases for each App

Step 4: Determine the criticality of each app and integration for the teams (Must Have, Should Have, Could Have, Won’t Have).

Sample tracking spreadsheet: 

After capturing the preliminary details for each App and Integration, it’s time to advance to the next phase and gather more detailed information.

Phase 2: Investigating Atlassian Data Center vs Cloud offerings

Once all apps and integrations are identified and classified, the next logical step is to look at the path for that app/integration in the Atlassian Cloud environment. Key attributes that need to be assessed are:

• Availability: Is the App even available in the Atlassian cloud?

• Feature Parity: The App is available in Atlassian Cloud; however, it's well known that Apps are not always functionally the same on the two platforms. 

• Can the Integration take place? Atlassian Cloud is not nearly as open to admins and SysAdmins as the Data Center is. There is no access to the database, and each Integration needs to be assessed. Chances are fairly high that most Integrations will work, but they will need to be rewritten.

• For homegrown apps, there is a very high probability that these will need to be completely rewritten. 

• Does the App no longer exist in the Atlassian Cloud because it is now a native tool functionality? This is a best-case scenario where the previously paid-for App (Automation for Jira, for example) is now built into Atlassian Cloud. 

• Is there a path to alternative solutions in Atlassian Cloud for apps that no longer exist or for new core features that are redundant?

• Check the cost! This can also be a significant deciding factor in keeping items identified as “should Have” or “could Have” on the roster of paid-for apps.

Reviewing feature parity, cost, availability, and potential coverage now with native features is critical in designing the migration plan, budgeting for the future, and creating a migration plan. Careful analysis is also critical to ensuring the user base has the tools they need to continue their work in an environment that supports their mission.

We recommend expanding the tracking sheet with additional columns of data for each app/integration:

• Cloud availability: Yes, No, Cloud OOTB

• Alternate Options: Identify if there is an alternate product to replace items not available in Atlassian Cloud

• Feature Gaps: For items that are in Atlassian Cloud, are there significant differences in features and function?

• Atlassian Data Center cost

• Atlassian Cloud cost

• Cost D=delta: [Cloud cost - DC cost]

Phase 3: Finalize app list, prioritize, security review

Once a thorough ledger of apps and Integrations is cataloged and assessed for availability, features, cost, utilization, and criticality, it is time to scrub for items that will move to Atlassian Cloud, those that are Cloud Out of the box, and those that will be deprecated for any number of reasons that make the most business and technical sense. A final app and Integration list then gives the team a list of priorities to focus on as they vet for security and start to design the migration process for the app data.

For the final roster of apps and Integration moving to your Atlassian Cloud site, continue to expand the columns of data with additional sortable info:

• Priority: Tiers 1 through 3 usually suffice and give the security teams reviewing apps a path to follow. If moving multiple teams, take into account how pervasive the app's use is, as well as early adopters in the Cloud and their needs. 

• Vendor contact, trust center Link: This is a good starting point for the security team to glean info on the app and find additional contact info for the vendor to review and fill in security profiles for each.

• Security review status: Keep it simple: Open, In Progress, and Complete

• Security resolution: Pass or fail

• Security notes: Allows the Security team to identify reasons for failure and possible paths to pass

Security reviews are essential when migrating to the Atlassian cloud. This applies not only to the core products like Jira and Confluence but also to each app and integration being implemented. For instance, the same security requirements and concerns that apply to the core products also extend to each individual app. Some examples are:

• Data residency

• Data sensitivity (HIPAA, GDPR, etc)

• Data transfer, or encryption

• FedRamp requirements 

• Connect or Forge architecture

Phase 4 Communicate!

Setting a final app list won’t always come with 100% agreement within your organization, so it is essential to carefully review the evaluation process and results with the stakeholders and ensure that items that will be deprecated are clearly communicated as to why. It is also very important to identify alternate paths for achieving the same or similar results if this is your business direction. In some cases, it’s simply not possible to carry forward from on-prem to the cloud with the same feature set. The good news is that Atlassian and its partners in the ecosystem are continually tackling the needs of its customers with significant improvements in feature parity, security, performance, and adoption of new technology! Investments by Atlassian and the partner ecosystem are hyper-focused on the cloud platform.

Additional consideration: Migrating multiple teams to a multi-site cloud enterprise?

In some scenarios, larger enterprise organizations are migrating multiple teams from multiple DC instances into a single enterprise org cloud, which is then divisible into up to 150 sites for Jira, Confluence, and so on. As it pertains to app assessments, this means that apps are licensed at a site level by the number of users granted access to that site at the org level. This can present an opportunity to lower the license counts on certain apps if a very small slice of team members is utilizing the tool.

For example, a large organization may have 5,000 users connected to the org via Atlassian Access, but 50 of those users are provided with a site-specific to the HR team. They use a specific app that no other team in the organization has a need for. Therefore, they are able to only pay license costs for those users accessing that specific HR Site under the org umbrella. It can save high costs over an Atlassian DC or Cloud Standard/Premium implementation and can also present a strategy opportunity to segment teams into microsites to reduce app costs for those users who are actually leveraging those capabilities. 

A second consideration when taking into account multiple instances migrating into an Atlassian Enterprise Cloud instance is to perform a comprehensive app assessment as outlined above but add a step to take a close look at each team instance apps independently and then across the multitude of instances moving over. This will gain further insight into the differences in business needs, usage levels, and use cases. This additional layer of analysis will allow more informed decisions on what apps to keep, what to deprecate or look for other solutions for, and possibly how to segment the Cloud Org into app-centric sites.

Cool tip: Build this out in Jira!

Why use a spreadsheet when you can build this entire process in Jira? Apply workflow and assignments, and track the project properly!

Ready to streamline your transition to the Atlassian Cloud?

At Isos Technology, we specialize in guiding organizations through every step of the migration process, ensuring your apps and integrations are effectively assessed and optimized for Atlassian Cloud. Don’t navigate this journey alone—contact us today to schedule a consultation and let our expert team help you make a smooth and efficient transition!