Cloud Migration, Guides

How to build a strong Cloud Migration strategy

Are your Cloud Migration expectations anchored in reality? Make sure you’re on the right track with this concrete plan for moving to Atlassian Cloud.

Agenda​

 

Your excitement about moving to Cloud is legitimate. After all, it is the gateway to future-proofing your business, unleashing a world of opportunities, and saving your company a significant amount of money. These benefits often create an illusion for businesses that once they migrate, everything will magically work out. This couldn’t be further from the truth.

Without a step-by-step and realistic plan in place, it is easy to lose control of your migration journey. Expectations not matching reality, you might even end up in a state worse than where you started. This guide is a foolproof, phase-wise plan to help you build a robust Atlassian Cloud migration strategy.

 

5 questions to ask before moving to Cloud

  1. Is Atlassian Cloud right for my business / operating model?
  2. What is our strategic approach to our toolset?
  3. What does it take to migrate?
  4. What will we lose and what will we gain?
  5. What does Atlassian provide in terms of migration enablement?

Let’s look at each of these questions in more detail:

1) Is Atlassian Cloud right for my business / operating model?

Bet you weren’t expecting this, but Atlassian Cloud is not a one-size-fits-all solution for all enterprises aspiring for modernization, thanks to variables such as security, privacy, infrastructure, etc. However, if you want to restrict your instance to your company, or make it fall under VPN, you might have to wait tad longer, as those options are not yet available in Atlassian Cloud. The exciting bit for companies with a Cloud-first approach is that over the last 2-3 years, Atlassian has been upgrading the features and functionalities of its Cloud products consistently for customers.

Before you are cloud’ward bound, ask: Is Atlassian Cloud the best way for my enterprise to move forward? Fret not if the answer is “no”; you will always have option to host your content on Data Center which also offers customization options.

2) What is our strategic approach to our toolset?

Everybody wants to make the most of a plethora of cost-saving, efficiency-driving advantages that comes with Cloud. The key is to build a robust migration strategy during the pre-migration phase itself, and not wait until the move commences. Plan with precision, conduct rigorous testing, and collaborate with Atlassian platinum solution partners  for expert help. Rest assured, these small actions will keep many a giant roadblock at bay.

3) What does it take to migrate?

Cloud migration depends on various factors such as size, add-ons, version of the instance, and the likes. For instance, if you’re in the older version of an add-on which is Cloud-incompatible, plan for upgrades accordingly.

4) What will we lose and what will we gain?

While there are common factors between Data Center/ Server and the Cloud, they offer many distinctly different features too. Be prepared to lose some of your favorite functionalities, but rest assured, the gains outweigh the losses.

For starters, you will save big on money as well as maintenance. Offering a hassle-free user experience, it is also way easier to handle or administer a Cloud instance than a Data Center or a Server.

5) What does Atlassian provide in terms of migration enablement?

About 90% of Atlassian’s new customers choose Cloud. The Australian tech giant has further announced that they have over 10 million people using their Cloud products, thanks to its top-notch security and high-performance features.

Pick the brains of the Atlassian community if you’re looking for an unbiased opinion, honest feedback, or key information from the horse’s mouth. Shoot your questions on community.atlassian.com, and you’d be surprised at how many members extend help with relevant resources. Reach out to Atlassian through the move ticket, because they will already be having an overview of how different scenarios work. The Atlassian team will either provide hands-on guidance or connect you to the technician who can assist you in the process.

 

Find out whether Atlassian Cloud is the right business model for you:

  • Keeping up with regular server updates: Decide if you want to have a self-hosted server that retains elements like a custom DNS or an instance inside your PPM that is not exposed to the public. For instance, healthcare-focused enterprises must adhere to stringent security regulations. While Atlassian has covered a lot of these regulations, there might be certain internal factors specific to the enterprise undergoing the migration. With the end of licenses, server upgrades, and maintenance costs in terms of handling an AWS or Windows server being taken care of by Atlassian, bid adieu to stress with Cloud and focus on your core business strengths better.
  • Cost of governing users, groups in multiple locations: Don’t fret over having set of ADs if it is excluded from your plan. In case you do, ITPs provide a way for you to integrate with Ads.

 

Take advantage of Atlassian accounts

Atlassian account is a feature which is exclusively available to Cloud customers. There is no additional pricing related to hosting users, so you can get it done for free through your Atlassian accounts.

  • Security compliance, responsibilities, and risks: Address your company’s specific security needs by ensuring that Atlassian Cloud has passed all the compliance tests. If it falls short of the standard, it’s time to re-evaluate your options.
 

Phases of a successful migration

1) Discovery Phase

  • Process: The Discovery phase is meant for identifying and analyzing the items you are planning to migrate. This entails evaluating the current state of your Jira or Confluence if you’re still hosted on a Server. If you’re hosted on a third-party application, then use this phase to brainstorm on the things which you can migrate over to Jira Cloud or Confluence Cloud, and the items you want to leave behind.
  • Downtime: If you’re migrating to Cloud, there is no downtime per se, but you will have to at least turn your instance into a read-only mode during the maintenance window. However, be mindful that users can still access the content which is available on Jira, Confluence or third party tools.If you want to avoid migration which is irrelevant and convoluted, be sure to set up the read-only mode. Skipping this step inevitably results in migrating over a fraction of your content, while others would be left in your server. This is where a Cloud Migration roadmap plays a critical role. Consider conducting a Sandbox testing or a Sandbox migration, and let the users test the instance, decide a date for migration, and plan things accordingly.
  • Cost Licensing: How much money are you going to shell out for your Cloud migration? If saving is your focus, then it would be worth taking a look at the advantages of moving to Cloud. For example, on a Data Center instance, the starting user tier is 0 to 500, which is rarely the number of users hired by small and medium size companies. In Cloud, on the other hand, the starting user tier ranges from 0 to 10, moving on to 10 to 15, then 16 to 25, and finally, all the way to a 100. The option of different user tiers enables teams to plan their budget accordingly and not overpay for unnecessary users. If the need arises, user tiers can be upgraded in a jiffy. Your best bet would be to collaborate with an Atlassian partner company to pick the best pricing in your bandwidth.
  • Documentation of risk and features: Understand the risks associated with Cloud, which might be related to potential access when your content is stored in the location. If your company has a policy that allows storing it locally, seek clarification on those things where Cloud servers are hosted.
  • Raise a move ticket: We cannot emphasize this enough: Raise a move ticket in the pre-migration phase for a hassle-free transition to Atlassian Cloud. Take advantage of Atlassian’s dedicated migration team to walk you through the migration process from scratch, get estimates on pricing, and get support over weekends. Set up a Cloud instance, and if you are migrating from Server or Data Center, share their numbers, involve the migration team, give a description, and Atlassian will respond to you in a time-bound manner. The support team will set up meetings or screen-sharing sessions to analyze your prospects of moving to Cloud. There are flags that Atlassian can enable, so all the hidden features that can be enabled from the backend will also be applicable for your migration.

2) User Acceptance Testing

It is recommended that your User Acceptance Testing spans over 2 to 3 weeks. This phase helps eliminate chances of miscommunication, become cognizant of errors and document the missed features— key factors that come handy in the production migration phase.

  • Cloud migration trial: Even if you have a valid (or invalid) server license, you can apply for a Cloud migration trial that offers you a 2 month extension of your Cloud migration plans with the user tire which you have on server. A company with 100 user tires in the server will be getting the same user tire on Cloud as well without paying for those user trials, and even extend its migration trials up to 12 weeks.
  • Data Clean-up: A lot of customers have unused data in their instance (eg: inactive workflows created in the past) that needs to be cleaned up. When you migrate the data to a new Cloud instance, all your data will be fresh, and you’ll not mess up your storage with a lot of unwanted data.
  • User Cleanup: This is similar to data cleanup. In server, there is an option to create user accounts without a valid email address. In contrast, when you migrate those user accounts to a Cloud instance, it is mandatory to have a valid email address. You can do the user clean-up beforehand to migrate only the specific set of users which you want to migrate to your Cloud instance.
  • Addon compatibility document: Most of the customers use an add-on to upgrade their features with the Jira instance. However, not all add-ons are currently compatible on the Cloud instance. The objective behind creating an add-on compatibility document is to check whether server add-ons are compatible with Cloud add-ons. On the other hand, data of certain addons can also be migrated to the Cloud instance. Check with each and every vendor about that plugin, and find out whether there is any migration path available for that add-on to be migrated to Cloud. Have an add-on compatibility document prepared first, and then consult with your users to figure out if they actually need them, how many projects are actually using that addon, and the likes.
  • Sandbox instance: A sandbox instance is a useful tool which enables you to delete and re-import your data multiple times.
  • Draft a run-book: Once we are done with the User Acceptance Testing with all the criteria, it’s time to draft a run book for your future production migration. Once the run book is clear, it’s smooth migration ahead.

3) Production Migration

What is Atlassian access?

It is a user management tool provided by Atlassian which you can link with your AD, and enable SSO, multifactor authentication, automatic provisioning, user provisioning, and more. Although it is a paid product, you can use the free version where you verify the domain and then manage your user accounts. Want enhanced features like SAML 2.0 integration, user provisioning, automatic user provisioning, authentication policies, dual authentication or multifactor authentication?  Simply upgrade to the paid version.

  • Atlassian Access: Currently in the Cloud instance, the SSO can be enabled only through Atlassian Access. So it is always recommended to enable Atlassian Access product, and verify your domains before production migration commences. Only then will your users be able to easily navigate your production site without any hindrance when you go live.
  • Post-migration: If any discrepancy is detected once the data is migrated, the remaining content can be migrated in the post-migration phase using some other methods like CSV to migrate the post-migration data.
 

Migration Methodologies

  • Migrating a Cloud instance to server or DC instance: Our recommendation would always be to use the cloud site import.
  • Migrating from a server or DC to a new Cloud instance: If it is a new Cloud instance, you can always use Site import or JCMA. Please note, whenever you import any data from Server/DC to a Cloud instance via site import, all the data on Cloud instance will be overwritten. Go with site import if it is a new Cloud instance, and opt for JCMA if you do not prefer to migrate dashboards or filters. Remember, JCMA does not migrate your dashboards and filters.
  • Cloud to Cloud migration: Traditionally, Cloud to Cloud migration can be done in two steps. First, you need to migrate the Cloud instance to a Server/DC instance, and then from the Server instance to DC, you then need to migrate to the Cloud instance.
 

Moving over content from legacy tools to Jira or Confluence

  • CSV approach: If you use CSV content on Jira, take a CSV export, format it properly according to Jira’s terminology, and then do CSV import to move over a lot of content. It’s quite complex, as a small mistake while performing the CSV import would land you up in a situation where a lot of issues get imported, calling for a manual clean-up. This demands precision, and it is recommended that inexperienced people conduct it in a non-production environment.
  • Custom Scripting: You can use scripting and move over content to Jira using APIs, and also avail the JSM API option to perform legacy migration from server to Cloud. The existing set of options are available for Jira to Jira. If you want to do a server to Cloud using JCMA-there are a lot of factors that you are allowed to consider, such as shared content. You only migrate over projects and users along with compatible add-on data (some marketplace vendors provide Cloud migration assistance). We will only be able to move over the content of those add-ons and any other add-on in which you won’t be able to move the content directly as some things might break. This is why testing migration is important—identify the loopholes and come up with a solution as a post migration approach. A lot of workflow-related features using external add-ons get lost and you perform a post-migration check to address it.
 

How to build a Cloud Migration Strategy

  • Users: Check whether you’re going to migrate entire or partial set of user directory. For the entire set, you’ll migrate everyone that is present on your user directory (active, inactive, as well as partial users). It is also possible to migrate a specific set of users using partial user directory. If you want to migrate the entire set of users, you can go with Jira Cloud Migration Assistant (JCMA). If you want to migrate just the partial user directory,  opt for free upload of users done through CSV methodology before we migrate data to the cloud instance.
  • Data migration: This depends on factors like whether the target Cloud instance is having existing data, or it is a fresh Cloud instance. If the customer’s preference is to migrate only a few contents from the Server to a Cloud instance, that is also possible through JCMA. If you’re targeting to migrate just a part of the content, you can either use CSV file import, or you can go with the JCMA. If an existing cloud instance, you need to go with JCMA, and if it is a new Cloud instance, you can directly go with site import.
  • Attachment migration: Attachment comes in a data folder within your bar folder. If the data folder is greater than 5GB, you can go with Cloud File Uploader— a new Atlassian feature with which you can directly import file data folder greater than 5GB. If the folder is less than 5GB, you will be able to migrate traditionally by splitting your 5GB file into a chunks of 2GB or 1GB, and then migrating one part at a time.

Attachment migration by traditional import: Site Import gives you the option to upload the media or attachment. There is a specific format that you need to follow to import content from Server to Cloud. You need to have those directories ready in a proper way, and  do the migration in multiple iterations.

  • Add-ons: Some add-ons are compatible with both Server and Cloud instances. Check with the vendor whether they are having a Cloud Migration path as it makes the transition easier.

JCMA has a few disadvantages which could be overcome by either using CSV method after one migrates the data through JCMA. So if you use JCMA, your cross-product boards, notification schemes, project avatars, etc will not be migrated over, and needs to be manually migrated using CSV import or recreated on the Cloud instance. If you’re going to use cloud site import, it is a straight-forward method. One disadvantage is if you’re using an external directory, the users will not be migrated. In that case, those external directory users can be migrated through JCMA. One can migrate those external directory users through JCMA and do just the data migration through cloud site import.

When you migrate over to the Cloud instance, all you have to do post migration is use application links and reconnect  for a lot of content to come back.

If you are a Jira Service Desk customer, it is managed differently on Cloud. So customers who are added on these Service Desk projects will need to migrate it in a different manner  in contrast to how it is handled on Server/Data Center. When the migration planning happens, you need to collaborate with Atlassian and make sure that this is executed smoothly.

 

Migration Assistant Tools

The migration assistant tools currently available are Jira & Confluence Cloud Migration Assistants. Jira service management migrations is on the pipelines, and beta testing for BitBucket Cloud Migration Assistant is underway. The Jira Cloud to Cloud Migration tool is also likely to be launched soon.

If you are a Jira Service Management premium or enterprise customer, you get features like Opsgenie, as well as an asset management solution involving Insight Asset Management and Insight Discovery, available for free.

If you are planning to have an exact replica of sandbox, Atlassian doesn’t just create it and give it to you. One needs to take a backup and then re reimport it on the Sandbox instance. Atlassian only provides you free licenses and a way through which you can do the testing without extra bucks. Take advantage of Atlassian loyalty discounts if you are planning to migrate from Server to Cloud.

Did this article give an impetus to your Cloud Migration plans? Whenever you encounter stumbling blocks in the security or compliance department, and the transition seems difficult, consider the possibility of outsourcing your Cloud Migration to a specialized provider. Zero stress and you can continue to focus on your core business strengths…that’s a win-win!

FAQ

What if you want to move data related to inactive users?

Yes, it is possible. While you can create multiple users with the same email id on Server, Atlassian Cloud doesn’t allow the same. For Cloud, instead of username, email is recognized as a unique identifier. The process of migrating unused data over to Cloud for storage is not complex-you just perform the migration and take it forward. Remember, while there are space limitations with the standard version of Cloud, there are no such limitations in Jira Premium, Confluence Premium or Jira Enterprise.

I would like to have more details about external directory user migration.

If you want to migrate an external directory user to Cloud instance, that will not be possible by Site Import, so opt for JCMA or CSV3 upload. Consider whether you are going to migrate entire users (JCMA), or if you’re going to migrate just a part of it ( CSV).

What is the difference between a sandbox instance and cloud migration trial?

Atlassian provides sandbox instance only to its enterprise customers, and the pocket pinch is high. This entails using a cloud trial to do your UAT migration, conduct the testing, and sign off. Reach out to Atlassian support, just mention that you are performing a migration trial, and they will guide you with the process. For the production trial, when you set up a Cloud instance for migration, you get two months of trial-provided your support period is not going to end before the time you are performing the migration.
However, in terms of sandbox versus cloud trial, sandbox is only available for an enterprise customer, and free of cost. A Jira premium or a Jira standard user will not be eligible to get a sandbox instance. You can have as many trials as you want, but it should be a different URL because it is just for testing purposes.

 
 

[DEMO] Talking Cloud Migrations

https://youtu.be/k3dQNwOSb4Y
Need help with Cloud Migration?
Feel free to contact us, we will get in touch with you ASAP