4 min read

What's the deal with Atlassian's Jira Cloud migration tool?

By Bradley Ode on Jan 14, 2021 10:45:00 AM

Blogpost-display-image_Whats the deal with Atlassians Jira Cloud migration tool (1)Atlassian's Jira Cloud is more popular than ever as companies continue to see the benefits in cloud-based technologies. For those of you already on server, the latest announcement from Atlassian might prompt you get to a head start on looking at migration options. I had the opportunity to work with Atlassian's Jira Cloud Migration Assistant (JMCA) earlier this year and now is a more pertinent time than ever to share those findings. 

What is the Jira Cloud Migration Assistant?

Jira Cloud Migration Assistant is an add-on introduced by Atlassian earlier in 2020 to help clients migrate their data from Server to Cloud. It is a migration assistant and should be viewed as such. There are many things that JCMA does well, but it does come with it's limitations and should not be viewed as a one-and-done solution for most organizations. With that being said, companies with small Jira Server footprint will get the most use out of the tool.

At a glance

What can it do?

  • Jira Software and Jira Core Project data
    • Details
    • Roles
    • Screens and Schemes
    • Workflows
      • Most native workflow functions
  • Issue data
    • Most custom fields
    • Issue history
    • Rank
    • Worklogs
    • Attachments
    • Comments
  • Boards linked to projects being migrated
  • Active users and groups from User Directories

What are the limitations?

  • Jira Service Management- no Jira Service Management data can be brought over with JCMA at the time of publishing
  • Third party app data
  • User Avatars/Timezones/Passwords
    • Passwords will need to be reset after migrating unless the client is using SSO
  • Global configuration items
    • Since JCMA operates at the project level no system settings will be brought over
  • Certain custom fields
    • Single and Multi-version picker
    • URL
    • Select List (cascading)
    • Select List (multiple choice)
    • Project picker
  • Certain workflow functions
    • Validator: required field, field changed
    • Condition: user in group, in project role, field value, subtask blocking
    • Post Function: clear field value, update custom field, copy value from other field, delegating
  • Links to entities that are not migrated

I don't have Jira Service Management, but what's this you say about app data?

Unfortunately, Marketplace Apps will need to be handled on a case-by-case basis. The JCMA tool provides a mechanism for assessing which apps can be migrated from server to cloud, but does not migrate the data via the tool itself. Instead, the tool will scan your instance and provide links or paths (i.e. instructions) to external documentation if it exists.

These paths can be a bit confusing as you are taken to the individual app vendors' sites. These can be radically different from app to app. In our case, many apps did not have a path forward and, instead, we are prompted to contact the vendor.

What about users?

JCMA will bring over all active users and groups on each migration initiation (which may or may not be what you want). You have the option of giving the users product access before running the migration, but in my opinion, it is best to wait until after the migration in case things go awry. After running the migration, the users will need to be invited to the Cloud site.

Should I use JCMA? Or perhaps another method like site import?

When the instance to be migrated is small, well managed, and with little complexity, the JCMA tool will handle your data with finesse. The JCMA tool is also more useful in merges when you are trying to merge a small, relatively simple Jira Software Server instance with a larger cloud instance. This is due to the fact that the JCMA tool itself is very project-centric. However, an abundance of app data, complex workflows, and many external integrations can be some of the things that might stop an organization from using this tool. If you are in any way unsure, contact us -- we've got your back.

My Experience

Overall, I found the JCMA tool to be a simple and effective way to transfer small amounts of project data to a cloud instance. It does what it says it will do, with only minor hiccups along the way. My experience a few months back is likely going to be different with yours as Atlassian continues to invest heavily in Cloud offerings. As always, do your own reading and don't be afraid to ask for help.

Further Reading

Topics: jira blog migrations cloud atlassian-products
3 min read

How do I migrate to Cloud if my apps aren't compatible?

By Jerry Bolden on Dec 23, 2020 1:06:11 PM

Blogpost-display-image_How do I migrate to Cloud if my apps arent compatible-

How many people are ready to move to the new hotness: Atlassian Cloud?  While this is becoming a more focused platform for Atlassian, there are some things that each company/team will need to think about as they move to the cloud:

1. What do I do if my current Server/DC apps are not compatible? 

2. What do I need to understand about my current set up within my workflows?

Apps are used to upgrade the out-of-the-box abilities of Jira, Confluence, and Bitbucket and most people not only become reliant on the apps, but may not even know they're using the apps for their day-to-day work. While there are quite a few apps operating on all three platforms (Cloud, Data Center and Server), some apps may not be available for all three platforms. For example, an app may be supported for Cloud-only or Data Center only.

While trying to migrate to Cloud, you need to understand which Apps are also compatible in Cloud and which ones are not. You can navigate to Atlassian Marketplace and set your first filter for Cloud.  Then, simply search the App name and the marketplace will do a good job giving you other options that have some of the same features as your current Data Center/Server app. Look through the recommendations and compare the current features you use with some of the recommended apps features.  The best thing is to also download a trial version of those apps in Cloud, but also if you are still on Data Center/Server, see if they have an app trial for those platforms as well.  

The other side of this will be having apps that exist on Cloud as well as on Data Center/Server but may affect your workflows.  For example, Automation has come included within the cloud, but JSU Automation Suite for Jira Workflows exists as a separate app on Data Center/Server.  While this app is now integrated into the Cloud,  when importing the data, workflows, etc. during the migration, you currently cannot use the Atlassian Cloud Migration tool and the links to the automation can fail. 

Reach out to those specific App vendors for support and open a ticket to understand what the migration path could be from Data Center/Server to Cloud. For example, In JSU's case, you have to redo all the affected workflows and their validators, conditions and post functions.  While some applications will be compatible, others will either require a little manual reconfiguration or finding ones similar in features to your current Apps.

Migrating to Atlassian Cloud is becoming more and more seamless as Atlassian continues to focus on the Cloud platform. But where apps are concerned, you will need to either find apps that already have a Cloud version or look for the Developer to review similar options and features. 

If you need guidance with your Atlassian Cloud migration, Praecipio Consulting is here to help! Contact us and one of our specialists will contact you shortly, and in the meantime, here are some helpful resources that you can start with

Topics: atlassian migrations cloud atlassian-solution-partner marketplace-apps
4 min read

How is Confluence Cloud different from Server/Datacenter?

By Morgan Folsom on Dec 18, 2020 1:06:00 PM

Blogpost-display-image_How is Confluence Cloud different from Server-Datacenter-

If you've recently moved from a Confluence instance that was hosted by your organization to one on Atlassian's cloud, you may be noticing some differences in how the tools work! The experience is quite different, and we know that can be a bit overwhelming if you've spent a lot of time getting used to the server UI. The change will require some adjustments, so we've provided a quick overview of things to keep an eye out for so you can get back to expertly collaborating with your team.

Navigation

Let's start with getting to Confluence! You can of course access your instance via the new link provided by your IT team https://yourcompany.atlassian.net. But, if you're looking to get to Confluence from your linked Jira instance, the application switcher looks a little different. The application switcher now lives in the grid icon(Screen Shot 2020-04-17 at 11.09.36 AM). Select that and you can navigate to any linked applications, including Confluence. 

Creating pages

Page creation looks different in the new view - you'll notice that there is now only one option to create pages, the Create button. This functionality has made it a lot more intuitive to create pages from templates! In Server, users need to consciously make the decision to create from a template (selecting the '...') or a blank page. Now when creating pages available templates will appear on the right, allowing you to filter and search through templates. With this new navigation you can even see previews of the templates before you select them. 

Keyboard shortcuts

This is the change that threw me off the most when switching between the products, because I rely very heavily on shortcuts! Here are three that I use a lot that have changed:

Action
Server/Datacenter
Cloud
Insert a Macro { /
Start an ordered list 1. 
Change header level Cmd/Ctrl + 1/2/3... # / ## / ###

 

To see a full list of shortcuts, you can select Cmd/Ctrl + Space while editing a page and a dialog will appear and display all of your options. 

Page layouts

The experience in Confluence Cloud is more mobile friendly, so pages are more narrow by default than previously. However, you can still expand your pages to span full screen if you've got a lot of content. Opening the page layout options hasn't changed - you select the icon in the editor. However, the page layout editing experience has changed so you can work on it within the body of the page, instead of at the top.

Screen Shot 2020-04-17 at 11.24.48 AM

You'll notice the arrows pointing out - those allow you to span full screen for either the entire page (top) or the specific section (bottom). The same options to edit layouts are available but you can see them in-line instead, which makes for easier navigation while working them into your pages. 

Panels

The Panel macro is one of my favorites - I like the ability to break the page up visually, and they are a great way to do that. Atlassian has revamped how panels work in Cloud so that instead of having separate macros for different types of panels: Panel, Info, Warning, Note, Success, etc. they are all just one macro, and you can switch the coloring as needed by selecting different icons. 

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

The last change I want to highlight is perhaps my favorite. When editing Confluence previously, you might've noticed that when you insert macros, many of them appear different while editing vs. viewing the page. In cloud, we now see that macros like the Jira Issues macro pictured below actually shows the content while editing now. 

Screen Shot 2020-04-17 at 11.31.30 AM

Switching between tools or views can be tough, but with Atlassian's cloud platform you'll see a lot of changes that make the user experience run more smoothly. Now you've seen some of the changes, you're ready to hit the ground running!

Thinking about switching to Cloud? Contact us to talk about how we can help!

Topics: jira atlassian migrations server cloud data-center confluence-cloud
1 min read

Atlassian Hosting: What are my options?

By Morgan Folsom on Aug 20, 2020 2:15:00 PM

Atlassian Hosting options

One of the most important decisions that your organization has to make with regards to your Atlassian applications is which hosting option you'll use. Not only will you will want to review the differences between Cloud, Server, and Data Center, but unless you are using Atlassian's Cloud platform, you'll also have to make key decisions about infrastructure. Praecipio Consulting offers Cumulus Cloud, our managed hosting solution to help make your decision easier. 

Amanda Babb, our Principal Consultant, was recently invited to chat with the hosts of “CarahCast,” Carahsoft’s new podcast dedicated to bringing listeners the latest in Government IT case studies, technology trends, recent legislation news, and Government IT best practices. 

In the podcast episode titled “Hosting in the Cloud with Atlassian,” Amanda discusses Cumulus Cloud, our comprehensive hosting solution that manages server and data center editions of the Atlassian suite, the value it brings to the enterprise organization, and why it's different from any of the other solutions out there.

Listen to Principal Consultant Amanda Babb outline all of the above and more in this Atlassian Podcast with our partner, Carahsoft. 

Topics: atlassian migrations cloud hosting atlassian-products podcast
5 min read

3 Simple Tips for a Successful Atlassian Cloud Migration with Atlassian Confluence

By Bryan Robison on May 7, 2019 10:39:00 AM

It’s no surprise that Atlassian Confluence has become a mission critical application for your customers and support teams alike. You may find yourself in one of these scenarios:

  • Your company has recently acquired another company (with its own Confluence instance) and you’d like to combine the two

  • You’re using Confluence Cloud and have decided to make the switch to Server in order to leverage a particular add-on

  • You just had a successful product launch

  • People are simply adopting it in droves

Whether it’s making the move from Cloud to Server, consolidating two or more instances, or upgrading your instance to Confluence Data Center, migrating and consolidating Confluence may seem like a daunting task. However, migrating can be stress-free by creating an action plan that includes choosing the right strategy, focusing on the different versions of instances and add-ons, and relentlessly testing for errors. Here are 3 simple tips that will ensure that you have a successful Confluence migration.

Tip 1: Choose a Migration Strategy

Confluence instances come in all shapes and sizes and the particulars of your instance(s) can help you choose an effective Migration Strategy. Here are three examples:

Single Cloud Site to a NEW Server/Data Center instance

Export your Cloud site to XML using the backup manager and restore onto the latest version of Confluence Server following Atlassian’s instructions. Please note, in most cases add-on data will not be migrated as part of the XML backup so check with your add-on vendor to determine if they provide any type of data migration assistance.

Complete Server/Data Center instance to an NEW Confluence Cloud Site

The instructions are similar to migrating from Cloud to Server but in the reverse. There are more restrictions on moving from Server to Cloud, the most important is that your XML backup file must be smaller than 200MB. Consult your version matrix to determine add-on availability and compatibility. See Atlassian’s detailed instructions for migrating from Server to Cloud.

Restoring a Confluence Site from XML will overwrite any existing data. If you need to preserve data in your Confluence see the instructions below for migrating to an existing instance.

Confluence Cloud/Server Site to an EXISTING Confluence Instance

To migrate a spaces or spaces from one site into another existing site you have to use the Space Export method rather than backup/restore. This method can be a bit labor intensive as it involves exporting and importing one space at a time. Again, consult your version matrix for any incompatibilities between Confluence or add-on versions.

Users and content permissions will not be migrated using the Space Export method and will have to be recreated in the target instance.

If you’re migrating Jira at the same time, migrate the Jira project first to ensure that macros are updated to the new Jira location.

Tip 2: Create a Version Matrix

Each Confluence instance is different. When you’re changing platforms or consolidating instances you need to carefully review the differences between Confluence and add-on versions, determine whether upgrades are necessary, and identify any “gotchas” prior to starting your migration. A simple version matrix like the one below is an easy way to quickly identify those items you need to pay special attention to.

Product

Source Version

Target Version

Notes

Confluence

6.4

6.8

  • PostgreSQL 9.2 is no longer supported

Secure Content

2.0.3.1

2.2.0.1

  • Required for 6.8 Compatibility

  • Administrators can reassign ownership to any user

  • Improved Reporting Macro

  • Contact SCB owners with custom messages

  • Secure content blocks look better exported to PDFs

  • Improve performance and UI of secure content admin screen

  • Added Autocomplete in Macro editor key field to help locate pre-existing keys

DocuSign for Confluence

1.1.4.1-GA-6.1

1.1.5

  • Improved tabular output for Envelope List Macro

  • Multi-Select status for Envelope List Macro

  • Confluence 6.6 compatibility

 

Tip 3: Test, Test, Test

Testing is a key component of every successful Confluence migration and consolidation. There are a few areas you should review in your test instance (you do have a test instance right?)  prior to performing your production migration:

Content Formatting

The version of Confluence and Space Theme you choose can sometimes alter the formatting of content when you change instances. Carefully review and compare different page types to ensure that they render correctly and pay special attention to any pages that utilize Space or Global Templates and Blueprints. If you have Space Blueprints in your source instance, make sure they are migrated along with your content to your target instance.

Add-on Functionality

Add-ons can differ between versions and platforms so make sure that you review the usage of add-ons that may be incompatible and consider altering the content in your Source instance prior to migration or consolidation. Also note that add-on data is not often migrated when exporting content from Confluence. Consult your add-on’s documentation and contact the vendor for special assistance.

Space Permissions and Page Restrictions

We discussed earlier that users and content permissions will not be migrated using the Space Export method. Ensure that users and groups exist in the target instance prior to importing your Space and the Space Permissions after import. Page Restrictions will automatically be applied once the groups are in the target instance.

Application Links and Integration Points

Remember to migrate any associated Jira projects prior to migrating Confluence. Test your Jira macro links in the source instance to ensure that they are pointing to the correct Confluence instance. If you’re migrating a complete instance from one platform to another, make sure you update the application links between all of your Atlassian applications. Don’t forget to update any 3rd-party integrations you may have in place and notify any teams who may be accessing content or data through the Confluence REST API that the URL will be changing.

Successful Migration

Needs change over time, and migration and consolidation of Confluence instances can become a stressful endeavor. By following these tips you’ll have some tools to ensure success and keep your teams, users and customers happy. Visit Atlassian Cloud Migration's page here.

Topics: atlassian confluence migrations tips cloud
5 min read

Q/A: Best Atlassian Deployment Options for Your ROI

By Kristopher Hall on Feb 1, 2017 11:00:00 AM

In two recent studies*, 86% of IT organizations are concerned about delivering value to their organization and 80% of an IT department's budget is used in Keeping the Lights On (KTLO). As such, IT organizations are focusing more on the right ways to keep their applications happy and healthy. One of the most important decisions an IT organization can face is how to host their Atlassian applications. Depending on resources, experience, and budget, the best choice may not be obvious at first glance. There are pros and cons of each hosting method. The question to ask is where do you find the most value when considering each option? Maybe the IT organization is new (or the company is new) and is looking for a hosting option that will take little-to-nothing to spin up and maintain. In this case, Atlassian Cloud may be the perfect fit. But what if you have a large employee headcount and access to experienced IT resources and increased funding? Maybe it makes sense to host internally to maintain complete control or, for a more hands off approach, off-loading the maintenance and performance responsibilities to someone else. That's where Praecipio Consulting can assist by offering Cumulus, our Managed Hosting platform. As Atlassian Platinum Solution Partners, we take on the responsibility of maintaining your system and are on call for your Atlassian needs. Where do you find the most value in your particular case?

What is the best return on investment for hosting?

The answer is: it depends.

 

1. What are the hosting methods and what are the pros and cons of each?

 

Atlassian Cloud

Pros:
  • You let Atlassian manage your system as SaaS (Software as a Service).
  • No upfront hardware costs.
Cons:
  • No access to database or operating system.
  • Some features that are present in Atlassian server products may not be available in Atlassian Cloud.


Internally Hosted (Server)

Pros:
  • Full range-of-motion on the entire application and operating system. You are the admin.
  • Personally dive into the application and get to know its inner workings.
Cons:
  • Whether you’re building on top of a virtualized or physical system, you’re going to run into hardware costs and the maintenance fees that hardware brings with it.
  • Time away from your team to keep that system up, running, and configuration changes when needed.
  • Performance tuning can be a daunting task.

Praecipio Consulting Managed Hosting

Pros:
  • More customization than Atlassian Cloud allows.
  • Atlassian Platinum Solution Partners manage your instance and performance tune for you.
Cons:
  • Some features will be present to Cloud first before they are released to Server.
  • No control over file or database structure.

2. What does it take to migrate to a different hosting method?

Each hosted method is little different to migrate to. If you’re migrating to cloud, it’s preferred to migrate via export (if it’s not a huge instance). If you’re migrating to a server you could migrate with the above method or you can take a backup of your database and move over your data (attachments, logos, etc) to the new server. Praecipio can help you out if you’re looking for a seamless transition.

3. What kind of database should I use?

Although you can use MSSQL or MySQL, it's PostgresSQL that Atlassian deems as its preferred database. PostgreSQL also allows for an easy move to datacenter Atlassian products as PostgreSQL is able to be turned into a database cluster, a functionality that MySQL is not capable of. You can make a MSSQL cluster too, but it comes with high licensing costs.

4. What is the trickiest migration Praecipio Consulting has taken on? What made it tricky?

We had a client that needed to migrate various applications. During this migration they needed to conform to a new username and email standard associated with the parent company. What made this tricky was you couldn't manually change this easily since there were thousands of users; you'd waste a lot of man hours and downtime making a change like that. The change had to be automated to modify each user in each application with various different places in the databases being updated with the new user values. This was to ensure that you kept all the users historical data intact and the user could come back into work after the migration, use his new account to log in like nothing happened.

5. What is the cloud user license limit?

Atlassian Cloud's user limit is 2000 for licenses. If you have a 2000 plus user count your options could be multiple Atlassian Cloud accounts or the Atlassian Server products that you'd manage internally or through managed hosting.

6. What is the storage limitation on cloud?

Atlassian Cloud has another limitation that you should be aware of. Cloud has a storage limitation. If you have a user count below 500 users you're looking at a overall storage limit (across all applications on your account) of 25GB. If you're over the 500 user count, you've expanded that limit to 100GB.

7. Between Jira and Confluence, which is more difficult to migrate from Server to Cloud? 

When performing a straight migration, Jira and Confluence are just about on equal footing on complexity to move to Cloud. Now, if you are merging two applications, that is a different story. Jira is a lot more complex to merge than Confluence due to the amount of variables that Jira has to have in place, like workflows, issue types, fields, notifications, etc. The list is long and you have to make sure the structure is there before you can merge your data. Additionally, merging data must be done from server to server. So if your end goal is to be in the Cloud, you have to merge all your instances to a single server and migrate that up to the Cloud.

8. Why should I consider Data Center if I don't have a performance problem?

One of the main reasons to consider Data Center is uptime. Data Center has multiple application nodes that you connect to through a proxy. If a node goes down due to a hardware issue, guess what? The proxy connects you to the next available node so that you don't even realize there has been an outage. To take complete advantage of the high availability perks of Data Center, you would also incorporate a database cluster. The same rule as before comes into play. If you lose a database server in the cluster, you're still up and running. You could even lose database servers and applications nodes at the same time and still have your environment up and all users working. Granted, there are at least one application node and database node up at the same time.

9. When doing a migration or merge - do you recommend having a staging environment to cutover from (as opposed to going straight from production to production)?

Usually it's not that necessary to have a staging environment to cutover from. Actually it's preferred to do the entire migration while the current production instance is off so that no one can update it to avoid anything becoming out of sync. What should be done is preform the entire migration/merge in a test environment and list out the steps that a needed to perform that migration. As long as any extensive configuration changes are not being made those steps are going to pan out the same no matter what data is actually included into the application.

10. How difficult is it to change the OS? For example, Windows to Linux?

Surprisingly, it is not as difficult as you might think. Most of the time it acts as any other migration. The thing that will usually cause problems is if you have something tied into you Atlassian application that is dependent on Windows or Linux to run correctly, a plugin for instance. The application itself can be installed and the data moved over without much of a headache.

 

*Source: HDI, “Service Management, Not Just for IT Anymore”, 2014
*Source: Gartner, “Eight of Ten Dollars Enterprises Spend on IT is “Dead Money”, 2015

Topics: atlassian blog managed-services migrations cloud data-center hosting

Summit Expedia Co-Presentation

By Christopher Pepe on Nov 11, 2014 11:00:00 AM

Discover how making the move from Perforce to Git at Expedia lead to standing room-only training sessions abundant with high fives. The move to Git improved Expedia's software development with faster development cycles, deeper integrations, increased transparency, and a more unified development platform. 

 

Topics: atlassian atlassian-summit best-practices bitbucket migrations perforce git
7 min read

Migrating SVN to Git: How Atlassian Made the Switch - the Human Side

By Praecipio Consulting on May 16, 2013 11:00:00 AM

The following content was taken from Atlassian.com

This is the third blog post of a three part series where we focus on migrating the Jira code base from Subversion to Git. We wanted to share Atlassian’s migrating experience to those of you who are contemplating moving a large project to Git – without sacrificing active development. In our first post we discussed why we decided to make the switch to Git. In our second post we dove in the technical details of switching from Subversion to Git. 

Migration – The Human Side

So you might know that you can run a pretty slick migration from the technical side, minimize commit downtime and ensure high availability of your supporting infrastructure. But are your developers ready for the change?

The opinions of Jira developers on the migrations varied from, “Git is the most wonderful thing to ever happen to Jira,” to, “I know Git’s better than SVN but I need training,” to, “Just show me how to do what I currently do in SVN in Git”. It’s critical to address the needs of developers across this spectrum.

The VCS you use (along with some other core things like programming language, IDE, frameworks and libraries) is one of your core tools and one of the key areas where you develop skills. Your VCS is the vehicle for technical communication and collaboration. You need to ensure that all developers are fully on board to maximize their own potential. If a developer has any uncertainty or hangups about the tools they use – particularly their VCS - their work can be severely impeded. Atlassian prides itself on openness – people are encouraged to speak up and risk falling flat on their face rather than not speak up at all – but there are all types of companies where we can envisage people hiding, not speaking up about issues if they’re not comfortable.

Also, developers worth their salt feel a connection to the code they write and their infrastructure. The most productive developers feel an ownership of their environment. If you are going to change that environment, like their VCS tool, it needs to be a change that they own and embrace.

1. Your team will need training

Assuming that everyone in your organization can learn Git on-the-fly after the migration is finished is a recipe for failure. Git is fundamentally different to SVN. Being aware of this, making your developers aware of this, and preparing them for Git is critical in making the migration a success.

The first thing we did to get our developers ready was to run a couple of Git training sessions. For example, we started out with, “How to do what you do in SVN, in Git.” This included Git commands for things like committing and demonstrating what tools are available (developers at Atlassian use their IDE, SourceTree, gitg, and the command line to work with Git). More importantly, it focused on explaining the key differences between SVN and Git. What does it mean to have a local repository that’s a clone of the remote repository? What is a working copy? What is the staging area? Finally, a step-by-step guide to cloning the Git repository and getting started fast was introduced and published on our extranet.

Further, Charles Miller (our Confluence Architect) ran a seminar that was a real deep dive into how Git works internally – what data structures it uses internally, and how actual operations like committing work get done. This was optional for all developers, but some people learn by deep investigation which helps onboarding. Also, the more you delve, the more you discover that Git is a wonderfully elegant architecture internally which is valuable for any computer scientist to learn.

We developed these training sessions internally, however there are a number of external companies that run Git training if that is your preference.

2. Your team wants to know how the migration is proceeding

While we were running the migration, we kept the team up-to-date on the migration status via email and HipChat, our real-time group chat offering. Every time we reached a milestone, we let the team know. Every time we changed infrastructure, we let the team know – partly as a warning in case things break, but also to keep them updated on how things were progressing. It’s a satisfying feeling when you say to a team member, “Hey, you know that code review you just created, you actually created it off the Git repository,” especially if you can pull it off without anything failing during the change. This regular communication, from within the team, was huge in making each developer feel like they were up to date and owning the change. The worst outcome is if the team feels like this change is forced from outside, or if the tools they use every day are changing under their feet without them knowing.

3. Your team will need “Git champions”

Let me say this once again: Git is different to SVN and it can take a while for people to adapt. No matter how much you prepare, how much you educate – developers will run into issues when they start actually using it. Left unattended, these issues will reduce productivity and can spiral into hostility to change.

We marked a couple of developers who had Git experience as ‘Git champions’ after the move. Any time people had issues, or didn’t understand things, or just wanted to know, “What did I just do?” or “How did it work?”, they could pull in a Git champion to help them. This was critical to making the change as seamless as possible.

In practice, we found the major difficulty people encountered was not the differences between commands, but the differences in the conceptual model of working copy, local repository and remote repository. Developers had internalized the SVN model. I would say it took 2-6 weeks for each developer to reach the same familiarity with Git.

4. Don’t change your workflows too much too quickly

There are a number of really advanced Git workflows out there that allow you to put the “D” in DVCS. Branches, feature branches, forks and pull requests are just the start. If you switch to these advanced workflows at the same time as you migrate, you are either Albert Einstein leading a team of Nobel laureates, or you are setting yourself up for a fall. We took the principle of “success through stability” into our workflows as well. We started off with exactly the same workflow we used in SVN:

  • one or two stable branches for bug fixes; and
  • a master branch for new development work

As I mentioned above, our SVN workflow for getting bug fixes from stable to trunk was to manually patch each commit. We kept this workflow when first migrating to Git – each bugfix commit is manually cherry-picked into master. Why would we do this? Git is designed for merging – wasn’t it part of the reason we migrated? To maintain stability, we felt that the change to Git itself was big enough for developers to take on and that changing workflow would only complicate things.

5. Make small, iterative workflow changes

We made our first workflow change about two months after the migration – no more cherry picking. Stable branch merged to master with each commit.

Again, we invested in communicating this change to the team – the motivation why, and a series of steps for how to do it. We re-awoke the Git champions to assist people anytime they had a difficulty. It proved to be a smooth, easy transition. Making small, understandable, iterative changes is what made each change a success.

The Current State of Play – Distributed VCS, Decentralized Development

Once we had settled into a merging workflow, we started embracing the distributed workflows that Git enables.

I mentioned at the start of the article that one of our major products, Jira, now releases to our hosted platform every two weeks. We tend to run with separate teams in separate branches; this enables frequent releases by decoupling separate teams’ work from each other:

  • On the day-to-day level, one team’s changes do not affect other teams. Did Team A break the build? That’s not a problem.  Their changes are isolated to their own team – they only broke their own build and no other team’s development speed is affected.
  • On the two-weekly release level, one team not making the cut does not affect the release. If Team B did not get all their stories over the line, they do not merge back at the end of their iteration. The release can go ahead with everyone except Team B’s stories.

This does introduce challenges of its own. Merging multiple sets of changes at the end of an iteration runs the risk of integration conflicts that can cause bugs. In practice, this is mitigated by the fact that individual teams tend to be working on separate areas of the code base. However, if a team or teams are working on areas that are likely to conflict with other teams, they tend to work directly on the master branch. The teams that are running on individual branches pull regularly from master to get these changes regularly and catch the conflicts before they become critical. Thus far, keeping the lines of communication open has prevented these sorts of conflicts from becoming problematic.

Another complicating factor is geography. Jira’s main development is done in Sydney and Gdansk; but on any one day we might get commits from Atlassian teams in San Francisco, Boulder, or Amsterdam. Teams in different cities tend to run on different branches allowing us to get over the communication gap. To facilitate communicating the kind of potential conflicts I mentioned above, we use HipChat (our group chat product) for 1-1 and group announcements and communication; this works extremely well with our distributed team members. The real-time chat rooms kept conversations persistent so when someone logged on from a different time zone, they could check the status of the conversation and get quickly up to speed. Developers were pinged when they were mentioned in a room so they could respond to someone’s query without having to read through the whole conversation.

A quick note on branch strategies: some people advocate a ‘branch-per-feature’ workflow, where each individual story is developed on a feature branch. This is a great workflow if it fits your project. Some products at Atlassian use this. In Jira, our CI overhead is very high. Running what we would consider ‘adequate’ CI on every story that gets developed is not within the bounds of reality for us. Branch per team, however, is working out well.

Success

The migration turned out to be a great success. No developers’ time was lost in limbo where they could not commit. CI ran continually, and we maintained the ability to do a 5.0 release throughout the entire migration. Post migration, we hit each change successfully and today, developers are embracing the power that DVCS gives them. The proof of this is in the complete change in our release cadence. There is no way we could have shifted from a 90-day to 14-day release cycle without DVCS.

This is probably the fifth time I have mentioned this but I cannot stress enough the importance of communication to the rest of your development team. During the migration, do not be afraid of giving it a higher importance than the actual technical migration tasks. It gets the developers to own the change. For those reticent to change, communication decreases worry and helps developers love Git.

Topics: atlassian blog migrations svn git
6 min read

From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development

By Praecipio Consulting on Feb 15, 2013 11:00:00 AM

The following content was taken from Atlassian.com  

In this the first of a three part blog series which focuses on migrating the Jira code base from Subversion to Git. We wanted to share Atlassian’s migrating experience to those of you who are contemplating moving a large project to Git – without sacrificing active development. In our first post we discuss why we decided to make the switch to Git. In our second post we dive in the technical details of switching from Subversion to Git. In our third, and final post we will discuss how we managed the “human” angle to migrating.

Atlassian has been extremely excited about DVCS for a number of years and has invested heavily in DVCS. Atlassian has acquired Bitbucket – a cloud DVCS repository host, developed Stash – a behind the firewall Git repository manager and added DVCS support to FishEye, Atlassian’s code browsing and search tool. They have also added a myriad of DVCS connectors to Jira.

Along with Atlassian we believe DVCS is a great leap forward in software development. As part of this, Atlassian migrated the codebases for their own products and libraries from centralized version control systems (generally SVN) to DVCS. Some of these have been big migrations!

In this three part blog series we will  focus on the biggest migration Atlassian has done – migrating the 11-year-old Jira codebase from SVN to Git. What obstacles did they encounter? What lessons did they learn? And most importantly, how did they do it without sacrificing active development on Jira? We hope that sharing this experience helps anyone approaching a similar migration.

We’ll focus on Git, because Jira moved to Git, but everything in this series applies equally to Mercurial. At Atlassian, they use both.

Why DVCS?

Migrating a big code base is not without cost. The first thing you will need to answer – both for yourself, your bosses, and the people who work for you – is what will DVCS bring us, and why is it worth the cost of migrating?

We have used SVN successfully on many projects.  So has Atlassian.  And I am sure many people reading this article have also used SVN successfully. Since there is always a cost to migration, you may be inclined to ask, “If Subversion has met my version control needs for many years, why should I change?” To me, that is the wrong question. The real question is, “How can DVCS make what we do today even better?”

Git is known for several things.  For a developer working with code, it’s faster.   It allows for advanced workflows like feature branching, forks and pull requests – in theory, these workflows are all possible with SVN, however the difficulty of merging in SVN compared to Git makes them untenable.  But for anyone moving from SVN, the main benefit of Git is that because of its lightweight branching and easy merging, Git allows you to do your default SVN workflow better than SVN.

What do we mean by this? Let’s talk about how we actually develop and release software. Most of us work in a world where we have at least one released version of our software in the wild, which we call a “stable” branch. We maintain and contribute bug fixes to a stable branch while developing new features on a “development” branch (which is called trunk/master/default depending on which VCS you use).

When we commit bug fixes to stable, we need to get them into master too. SVN merge is known to be a pain and works solely on revision history – not actual content.  As a result, a lot of people avoid it, or they do it infrequently and not as part of their day-to-day workflow. How many projects have you worked on where stable and development branches have started to diverge, or diverged so significantly that the effort to bring them back together is a real project cost? Many have certainly been in projects where this has happened, and when we speak to other developers it’s a frequent occurrence with SVN. There are some strategies to deal with it.  For example, with Atlassian’s issues and tracking software, Jira, they ignored merging and required developers to make each commit individually to each stable and development branch, relying on QA to make sure that it happened correctly.

Git allows you to remove this pain. Git makes merging so easy that merging the entire stable branch into the development branch on each commit is a reality; it’s now Atlassian’s default workflow. So even if you don’t want to use feature branches or forks or pull requests immediately, Git provides advantages from day one.

And when Atlassian was ready, they were in a position to take advantage of the advanced workflows that Git allows. Before the switch to DVCS, Atlassian’s major products targeted 90-day release cycles. These 90-day releases went to two platforms: downloadable products for clients to install on their own servers; and a release to Atlassian’s  hosted cloud platform (Atlassian OnDemand) for which clients pay a monthly fee. Using branches as a core part of development workflow has allowed Atlassian to shorten this to the point where they now release major products to the cloud every 2 weeks.

The Switch

Jira is a decent size code base to move – 11 year’s worth of history, 47,228 commits across approximately 21,000 files. Atlassian averages about 30 different committers over a two-week period. More than that, the VCS is a real work-horse for a project like Jira. Builds, code reviews, scripts for releasing both product distributions and source… all these things have a rich tapestry of dependencies on the source code management system.

Their main goal in the migration was to minimize interruption to developers. This is about more than just the ability to commit code; it is about the infrastructure surrounding software development.

Atlassian has 3.5 years of history in Jira’s code review system.

Jira has a lot of CI. Atlassian runs approximately 60 build plans over different configurations and branches.

They have some other dependencies too – Jira has a somewhat complex release process that involves pulling together code from multiple sources. Atlassian also releases their source code to customers, which involves a different set of build scripts.

There is a tradeoff here between how fast you can migrate and how stably you can do it – Atlassian’s guiding principle was to optimize for stability over speed. If you set a deadline for your migration and it slips, what’s the worst that happens? Developers have to commit code to SVN for another week or so. Not the end of the world. It’s far worse if the migration interrupts developers’ ability to work and meet their own deadlines.

In the end, the migration took 14 days in total, with only a total of two hours where developers were unable to commit code. Atlassian were nearing the end of the development cycle for their latest release, Jira 5, and at no point were they unable to cut a release candidate.

Preparation

When preparing the migration, there are a couple of things to be aware of.

First, it will take time. The actual git-svn clone, which takes all of the commits in the SVN repository and replicates them in Git, took three days for Atlassian.

Second, you should prepare and think of all the dependencies your infrastructure has on your VCS. And know that if your infrastructure is sufficiently complex (like Atlassian’s), there will be things you never dreamed of and only discover when they break. So don’t beat yourself up when you encounter a dragon. Just slay it, and continue on your quest.

A migration like this is not something you can do overnight, or even over a weekend. It needs to be managed for a sustained period of time.

Migration – The Technical Side

Stably migrating is daunting but it is not brain surgery; there is a process Atlassian has employed to make it manageable. In part 2 of Atlassian’s Switch to Git series we walk through, step-by-step, the technical details on migrating from Subversion to Git.

Topics: atlassian blog management migrations svn technology git incident-management information

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us