Lewis Lovelock is the IT Operations Manager at Clearvision, responsible for IT externally for customers and internally, which includes overseeing the Atlassian Stack in-house. He recorded a live webinar based on our migration from Confluence Server to Cloud, which we’ve turned into a blog post.

Deciding to migrate from Confluence Server to Cloud

If you keep up with technology trends, you’ll know that Atlassian Cloud has been around for a while and has grown in popularity, with 95% of new customers choosing it over other options.

Being aligned with Atlassian for as far back as the first YouTube video was published, we knew Cloud was the best decision when Atlassian announced the end of life of its Server products in October 2020.

We’d hosted the Atlassian Stack internally for around 12 years, and Confluence was selected as the first tool to move because it’s the simplest system of the bunch, and we wanted to adopt an attitude of quickest wins first. The plan was to learn from this migration and to improve when moving the rest of the Stack.

As a leading Atlassian Partner actively helping customers migrate, we also wanted to practice what we’ve been preaching. So here are the top 5 dos and don’ts based on what we learned.

Top 5 dos and don’ts when migrating from Atlassian Server to Atlassian Cloud

1. Don’t slack on communication

It was important for us to make sure that everybody affected by the migration was aligned, so we gave them a chance to share their opinions. To do this, we communicated the plan and defined key dates, sharing who would be involved, the expectations, and information on how to voice opinions or ask questions. We did this via announcements on Confluence in the form of a banner, blog posts, town hall updates, and printed notices in communal areas within the office.

We recommend doing this as early buy-in is vital to the success of the project post-migration.

2. Garden before you start

Gardening refers to the general housekeeping of applications. If you use Confluence, you’ll know it consists of pages and spaces. We assigned ‘gardeners’ to spaces to perform this task, asking them to decide on what they needed to keep and what they didn’t. This isn’t the easiest decision for users as it can be hard to let go of certain items, which is why it’s important to remind them of the gains.

3. Archive systems

If you’re wondering what happened to the old data that was no longer needed following the gardening task, it was archived. Early on, we decided to archive Confluence Server, leaving it in read-only mode as we knew certain data may be needed again in the future.

While we migrated all relevant spaces using the Confluence Cloud Migration Assistant, we informed users that the old system wasn’t going away forever. This made them feel more comfortable considering there was 12 years’ worth of content on the platform.

Following the migration, we locked Confluence Server down and considered it ‘non-production’ meaning we didn’t have to align it to production SLAs and turned off its fail-over infrastructure, saving us money in Amazon Web Services (AWS) charges.

We then conducted a dummy migration, created new user accounts, and configured the Confluence Cloud system ready for production.

4. Testing

Testing goes beyond ensuring a page has been migrated successfully as it applies to the functioning of the platform.

There are notable differences between Confluence Server and Cloud, despite the similarities, one of which being macros. It’s important to make sure that you test the new system, especially for macros, as they are heavily focused on the end-user experience.

When we migrated certain pages to Cloud, we experienced issues with the expand macro in that the embedded expand macro in some pages failed to work even though the macro exists in Cloud. The problem was that the Server expand macro and the Cloud expand macro did not translate in the migration. There were fixes for this, but we allowed the end-users to resolve it, which worked well given the early buy-in as a result of communication. Another factor to watch out for is page order and hierarchy as we faced challenges where certain pages forgot their parent page.

5. Cool-off period

Be prepared for pushback and questions before and after the migration. While we covered the importance of alignment in the company, you have to understand that it won’t have reached everybody. There will always be questions, which is great because it shows interest.

It may also be helpful to ask staff questions to ensure alignment. Here are a couple of examples from our communication:

• Do you understand why we had to change from the old Confluence?

• Do you find the blog notifications in the Slack channel helpful? (We use Slack at Clearvision and have found it easier to receive company-wide notifications this way).

Following the migration, we held an ‘ask me anything’ session to get company-wide feedback. We recommend doing this as it provides a platform for users to be heard and for them to get immediate help on issues like broken macros. It’s important to note that we recorded and posted the session internally for anyone unavailable to attend the live session.

We also created how-to videos and guides which we shared with end-users in related Jira tickets when they came through to the IT team.

In total, it took around four months to perform the migration, which included 33 global spaces, amounting to nearly 200,000 pages!

Remember to get early buy-in, complete gardening, create an archive system so that the old system can be referred back to as and when needed, test the new system, and keep an eye out for macros and page hierarchy within a space. Finally, be prepared for pushback and questions.

To watch the full webinar, click here.