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.

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.

Our partners at Puppet and Splunk recently released the State of DevOps Report 2018 which mirrors many of the same observations that we see when working with our customers. DevOps isn't a sprint, it's a journey, depending on the organization's size, that can take organizations months or years to master. Instead of focusing on statistics like in prior years, this year's report introduces the five stages of a successful DevOps evolution and identifies and describes the practices successful, mature organizations have implemented during their journeys. The report has something to offer to organizations no matter where they are in their process. Even if your organization has employed DevOps for some time, you may be missing a critical component of your implementation.

Five stages in a DevOps evolution

The major takeaway from this year's report is that while there is no single path to a DevOps transformation, there are five foundational practices and five distinct stages of a successful DevOps evolution. Each stage is comprised of a set of practices broken down between "defining practices" and "contributors to success" which are identified and described for each stage of the process in the image below.

(State of DevOps Report 2018)

As organizations evolve from stage to stage, they refine and expand on the practices they implemented in prior stages. The report dives deep into the identification and makeup of each practice and describes how establishing practices identified as contributors to success in earlier stages such as "test infrastructure changes before deploying to production" in Stage 1 become mission critical defining or associated practices in later stages. DevOps is not a sprint, but a marathon, and requires organizations to have effectively executed each stage before advancing to the next one. Quite often we see that even the foundational practices such as monitoring, testing, and configuration management described in Stage 0 are missing from our customer's toolchains.

DevOps starts with a ripple

We frequently hear stories from our customers about how they began using Atlassian tools. These stores often begin with when a single team purchased a Cloud account or installed Jira onto a server sitting under someone's desk. Usage evolves and expands over time and eventually, the whole organization is reliant on the application for mission-critical operations. The report found that the DevOps evolution begins in much the same way: starting with a single team who defines their own practices for DevOps and shares them with other teams within the organization.

Where do I start?

The State of DevOps Report 2018 recommends starting with production by choosing an application with an, especially painful deployment process. We often describe DevOps as breaking down the wall between Development and Operations and deployments are where frictions between the two often occur. By automating deployments teams can improve collaboration and communication while reducing the friction caused when things go wrong. 

Since 2010 (before DevOps was called 'DevOps), Praecipio Consulting has been fortunate to work with customers at all stages of the DevOps evolution and guide them in using Jira, Confluence, Bitbucket, Bamboo, and other tools like Puppet, Splunk, New Relic, xMatters, qTest, and AWS as part of their technology standard. 

To learn more about how Praecipio Consulting can assist you with your DevOps journey, be sure to register for our upcoming webinar "DevOps: An Interpersonal Approach" on October 10!