Welcome back everyone, to today's webinar: Plan your Jira Server to Cloud Migration. So let's get started: before we get things kicked off let's do some very quick housekeeping. No doubt you'll have questions and when you do use the control panel on the side of your screen to ask them. If we have time we'll get to your questions as fast as we can, and if we can't get to them at all during the webinar, we'll follow up with answers as soon as possible.
Let me first take a moment to tell you about us here at Praecipio Consulting: we're in Atlassian Platinum Solution Partner and we've been doing this work since 2008. Over 99% of our projects are Atlassian related, and this includes work around DevOps, IT ops, Agile and Scaled Agile. We have hundreds of clients across the United States, ranging from small and medium businesses all the way to the top fortune 5. Our clients include the world's largest retailer, the top media company, and the top automotive retailer. This also includes the largest healthcare services company and electronics manufacturer. We do pretty much everything there is to do in the Atlassian world, everything from implementations and training, custom development, licensing and upgrades, managed hosting and managed services.
In today's webinar we have Isaac Montes, Technical Solutions Architect at Praecipio Consulting, and over the years Isaac has performed many cloud to server migrations for our clients.
Isaac you can take it from here!
Isaac Montes: Hello everyone my name is Isaac Montes, Technical Solutions Architect at Praecipio Consulting. I performed many Atlassian migrations over the years and in this webinar we will cover migrating Jira Server to the Atlassian cloud. During the introduction we'll talk about cloud in general: advantages and disadvantages, and a quick exercise. Then we'll cover the stages of a migration. This is where we'll explain the whole migration process. After that we'll talk a bit about troubleshooting and a couple of common issues, followed by alternatives to the cloud and we will finish with questions.
So now let's go over the introduction, starting with some statistics: Gartner projects the Cloud Services Industry to grow exponentially by 2022. The market is expected to grow 17.5% in 2019. Following this trend we're seeing more and more enterprises wanting to move their server to data center applications to the cloud. But in most cases there is not a clear path they should take, and how to plan for such migration.
Some of the advantages of moving to the cloud include the scalability and availability: Up to 2,000 users, the system is not run on your own infrastructure, there are no additional hardware requirements and their associated costs, there is no additional stress on your IT department, there are no maintenance tasks and the systems can be up and running quickly and be used for short term projects. But these advantages come with some limitations: you have limited customization for your apps for the moment, less administrative options, less flexibility with integrations and you are on the public Internet, you're not behind the firewall.
Some of the things to be aware of is that the cloud is built for stability and not customization. There is currently a 5,000 user cap and announced at Summit that there were working to get to 10,000 users. Data residency is another issue: data centers are in the U.S., Ireland, Singapore, Germany and Australia! And this is for Jira, other apps may have different location than the Jira application. Third-party apps likely host data from one location and many top apps are overseas. No cloud applications for Bamboo and Fisheye Crucible. Bamboo is replaced with pipelines and Fisheye Crucible is replaced by Pull Requests. The data can only be accessed via REST API, there is no database log access.
Now we'll go over a few examples and an exercise. Here you will see client A, B and C. I will give you some time to decide if they need to go into the cloud or they need to be hosted on a server.
Client A: medium-sized company, will have around 300 active users, headquartered in New York but a large presence is in California. Migrating first server has been on Atlassian customer for five years and will want to bring most of the data. Will be using single sign-on implemented Okta, at least adhere and we will need to manage users.
Client B: a lot of legacy data. Has been Atlassian customers for a long time, and cut a lot of issues. Service that's heavy, they need to have high availability for their customers and third party users. They have been using many third-party apps for years, they want to keep all data intact.
Client C: Enterprise customer. They have 4500 users and will be onboarding another two thousand users over the next year. Flexibility is important, they want their teams to work from a common system, but they have unique needs, all them non-Atlassian: they want to have Jira Confluence and Bitbucket.
Client A: medium-sized company that is migrating from Server and will reuse its single sign-on is a good candidate for the Atlassian cloud, as Atlassian will support all their requirements.
Client B: a lot of legacy data! They need higher validity for their service desk and third party app users. They will be a good candidate to move to its server data center, since they need high availability and third-party apps may not be available in the cloud.
Client C: an enterprise customer whose flexibility is important and it's all in on Atlassian. They should stay in server but potentially migrate to the cloud once they increased their user limit to 10,000 users.
Planning is very important! There is not two of the same when it comes to migrating to the Cloud. While some instances can be simple to migrate, others may face complexity and bigger impact to end users, require more diligence when it comes to migrating.
Now we will take a look at the migration stages. There will be three main migration stages: Staging, Migration and Post-migration. During Staging there'll be three phases: Preparation, Testing and UAT. During preparation you will be preparing your migration, reviewing security, upgrading applications and creating a free trial account for the cloud. Then moving into testing, you will perform a test import to the cloud. Document everything you do! Document issues, runbook and configurations. Then move into the UAT. You’ll have a test team doing UAT, a team you will review results, perform changes, update a runbook and then you go back and test again to set a production migration date.
Then on the migration stage you do the production migration. You set your outage, you put Jira Server to read only mode, migrate the data to you’re UAT and set a date for end-of-life for the server instance. Then between the production migration and roll-up support, you have a go live or no go live decision. This is where you decide to go ahead and keep your data in the cloud or rollback and continue to use Jira Server.
Then during the rollout support, users are on boarded to the cloud, you will continue working as usual and continue supporting users that will embrace changes, and then you will end-of-life the Jira Server. This is during the post-migration.
Now we will move into more details about staging. You will need to determine what type of migration you need to perform and if you'll meet your requirements. You'll need to start building the runbook and determine what requirements need to be met to migrate the instance. And then you need to test your migration: test the runbook and make sure is accurate, then you rinse and repeat.
What type of migration do you need to perform? When migrating to the cloud, either we go to a new greenfield instance of the cloud or we migrate to an existing instance of the cloud. This is called a merge migration. In this webinar we're only covering migrating to a new cloud instances. Merge are way more complex since you first will need to migrate your cloud to a server instance, perform the merge on server, then push back to the cloud. This is to prevent overwriting your existing cloud data.
Review your security: you want to make sure that Atlassian cloud meets your security team requirements. Atlassian provides information around security, privacy and compliance policies. For more information visit the Atlassian Trust Center.
Review your installed apps: to migrate Jira Server to the cloud we need to make sure we are at the version compatible with the cloud. In case not, upgrade to the latest server version. In addition to that, we need to make sure our apps or also call add-ons are compatible with the Atlassian Cloud. To check compatibility, we need to look at compatible version. Does the I don't have a cloud version? Verify the commutation for add-ons’ specific migration steps. If the add-on does not exist find similar functionality with the other add-on. If no replacement, determine if add-on is critical to the team. And also verify adfd-on data can be migrated without typical means of migration.
Now we talk about migration planning. You need to gather your team for the migration. Make sure you gather the various stakeholders in your organization that use Jira. Make sure they are aware of everything that is happening. You need to communicate often the status of the migration and when will things happen. Make sure you provide communication plenty of time for stakeholders to ask questions and provide feedback.
In most cases an upgrade may be needed. You need to follow the right upgrade pack, in some cases applications will need to be upgraded in steps rather than going straight to the latest version. Always remember to backup! That is essential! If you don't back up, there's chances that you won't recover the data as you used to have it.
You also need to know what data will migrate. Data migrated will include users groups and permissions, site data including projects issues and Jira configurations, any custom mail handlers you set up in server, application links attachments, project avatars and logos. Data that will not import are the migrator’s user information. If you're the person doing the migration, you will need to re-add yourself to your previous groups after migrating.
Apps or also called add-ons. App data is not included in the backup when migrating from Jira Server to Jira Cloud. Some apps do have the capability to export and import their data, but you will need to check with the app developers or direct documentation to confirm if this is possible.
User avatars. Users will need to update their avatars at Id.Atlassian.com. after migrating.
Passwords. Users will need to reset their passwords in the cloud after the migration.
And time zones. Time zone information on a per user profile will be lost.
As we mentioned before, communication is very important. You need to let your customers or users know when will it happen, what will be the expected down-time. You will also need to make sure you freeze any changes: this will include adding add-ons, removing add-ons, and other configuration changes. Also you need to provide necessary information on how to access the cloud instance once the migration happens. Make sure they have contacts in case they have issues or anything comes up.
Now you need to prepare your Jira Server. Here's the guideline for upgrading Jira in preparation for the cloud. It is always recommended to upgrade to the latest version. version 7.13.1 or higher, you will not need to upgrade before migrating. Between 7.6.0 and 7.13.0 you may want to upgrade before migrating. For server versions prior to 7.13.1, all timestamps including the ones created on issues and history dates, will be interpreted as UTC time. If these dates are important, we recommend upgrading to a version 7.13.1 or above, unless your server system is already UTC.
Between 7.0 and 7.6 we advise upgrading to 7.13 or higher before migrating. Migrating versions between 7.0 and 7.6 may work but these versions are no longer guaranteed to work without requirement an upgrade. Anything below 7 you need to upgrade. Additionally if you are using an external user directory like LDAP or AD on your Jira Server Instance, those users won't be imported during the migration. You will need to either migrate those users to an internal user directory before migrating, or create the user accounts after the import is completed. This applies even if users are stored in the Atlassian cloud.
Many backup because they have seen the dark side of failing to do so. Blessed are those that back up who have not seenit: this is a quote from T.E. Ronneberg. It is very important to back up. Do xml backups in server, in addition to your organization's typical backups. Set up your Atlassian cloud instance. For more information on how to setup please visit Atlassian.com.
Test migration: run a test migration. Test migrations not only help us identify potential issues, also they are a rehearsal for running the production migration. The more test migrations you run the more predictable the production migration become. The test migration also provides us with a lot of data that will help with planning of the production upgrade. Some of that data includes the timeline. During that you have your outage window, verification and testing, UAT and roll-back in case needed.
You will also have a record of issues: you will need to resolve known bugs and also know that some issues are not show stoppers, and can be resolved after going live.
Runbook: dial in the runbook with all details for the migration, note the right milestones for proper communication, know when there is a critical issue that requires a roll back. The rollback procedure should be documented.
Also testing and UAT procedures should also be documented. When setting the times for each step allow for some buffer for the unexpected. By this point all communication should have been sent and Jira should be put into read-only mode. If Jira is behind a proxy or load balancer, it's possible to redirect users to maintenance page.
It’s recommended to keep all communication channel open in case things don't go as expected, whether it be chat room or open conference call. This prevents wasting time trying to find a place where everyone can communicate and come up with the right decision.
Always start on schedule and follow the runbook. If small changes need to be made in the process, make sure you update the runbook. In the event of a rollback, you’ll need to perform the migration again and knowing those changes ahead of time may save time in the process.
At high level the migration would look like this: by this point your cloud instance should already be ready to receive the import. Note: the import will override everything in the current cloud JIra instance. First the outage starts, you will back up your Jira server system. If you want to include attachments and avatars zip those in the following structure. Import your database backup from step 2, import your attachments and avatars, verify everything's in working order. There will be several in-between steps, potential workarounds and troubleshooting. We will not cover those, since it changes depending on your instance. Here's the diagram for the attachment and Avatar structure.
Now we move into migration verification. It's important to run some verification tasks before we can call it a success and users can start logging in to the cloud instance. Make sure there's nothing missing: you may wish to start using the instance before the attachment import completes but it's not recommended. You need to check for attachments, comments, projects, issues, permissions configuration settings, and also review permissions. Make sure everyone has the right permissions to the systems as they have been impacted due to the difference between cloud and server. Verified needed apps are installed and if any integration is required all verification steps may be different depending on the instance. These are just some of the basic things to look at.
Once you feel comfortable, announce the go live, and onboard your users. User should have been provided a set of instructions like the following: verify everything works as expected, know the new URL of the site, how to reset their password, contact for questions and concerns, a portal for training issues if any found, know what are the most notable changes between server and cloud, links to the documentation. Note that as time passes rolling back may be more difficult, as users create more data and such data may be lost if rollback is necessary.
Now we will talk about some of the most common issues users encounter when migrating to cloud. Failure due to version mismatch: the import to the cloud fails to a version mismatch. Always make sure all apps and the application itself is upgraded to a necessary release. If that is the case and you still see an error, first always let Atlassian support know of the issue you're encountering. This particular scenario is common to see when an app was installed a long time ago, whether be for evaluation purposes or as a mistake, it will create tables within the database, and in most cases those tables will transfer to the XML export. When this is imported it will cause issues or it will ask for the app to be installed. For a workaround, you can either follow the correct operate procedure for your a particular app, or clean up the database tables for apps that are no longer used.
Users not migrated: another typical issues regarding the migration of users. In some cases users may not be migrated weather it be because of duplicate users or inconsistencies with the database. This may become a blocker. In most cases the issue is resolved by removing duplicate emails which that doesn't cloud relies on usernames. If the problem is more complex or if you are using external user management, you may be required to export the users and groups into CSV for later importing. Submit a request to Atlassian with the CSV export for support importing the users and group memberships.
These issues are common but do not represent the whole extent of issues that you can encounter. This is why it's very important to test, test and test again. You can find more information at Atlassian documentation for known issues, but unless you have a reference to them which you will get while testing it will be pretty much impossible to identify if an issue applies to your instance.
When the Atlassian cloud is not an option, we can look for alternatives. For example, you need some functionality your server provides, but the cloud doesn't. You don't want to own and manage the infrastructure and all the overhead in costs that come with it. You may look to host your instance somewhere else. Some of the benefits of a managed hosting service include optimal performance, LDAP connectivity, data center scalability, increase infrastructure control, hands-free maintenance of your instance, and hardware and additional customization options.
A good example is our very own AWS cumulus, or expert design Atlassian optimized hosting solution for enterprise SAAS, which provides scalable, failsafe, highly available cloud hosting for your applications. It’s built to ensure 24/7 application availability, our managed hosting delivers server and data center additions for Confluence, Bitbucket, Jira software, Portfolio for Jira and Jira Service Desk.
AWS cumulus will reduce the cost of ownership: setting up your own servers can be costly. With our managed hosting services, you get Atlassian server and data center instances without the hassle and costs.
Increase flexibility: if you need both of the features for the cloud and Atlassian servers,with our managed hosting you get the best of both worlds. Your data will be safe and sound. Easily you can add additional system resources without the growing pains. You can scale your instance without sacrificing functionality or accessibility.
Now we will go over some of your questions. If we don't get to your question we'll get back to you via email. Our first question: is there a search limit in the cloud? This will depend on which plan you choose. Standard plans currently have a storage limit of 250 gigabytes, while premium clients offer unlimited storage.
Next question: how much downtime should we expect during our migration? Like with said in the presentation, no two migrations are exactly the same. We recommend running a test migration to assess your plan and how long your migration may take, including any expected downtime.
Can we connect Jira Cloud to my other Atlassian server products? Yes, you can connect Jira cloud to other Atlassian server products using application links. You will need to set this up after you migrate.
Can I switch my self-hosted license to a cloud license? No, your current self-host license and maintenance won't transfer to the cloud. These are two separate licenses and are paid separately. However, Atlassian offers extended cloud trials that provide a free cloud site for remaining self hosted maintenance period or a minimum of 60 days, whichever is longer. These trials will help you transition to cloud at no extra cost.
Well this is it for today. Thank you very much for your time, and if you have any additional questions feel free to reach us at contact.praecipio.com
