Disclaimer: This was originally posted in our Company's Blog. I adapted this article and included even more info for the Community. The German version is accessible here: "Unsere Confluence-Cloud-Migration war ein großer Erfolg" - Wirklich? (viadee.de)
Credits for illustrations used in this article go to vectorjuice at Freepik
We - just like many of our customers - are faced with a lot of Software manufacturers shifting towards Cloud-First strategies. One of them is Atlassian. 250 colleagues are using Confluence, Jira Software and Jira Service Management day in and day out - all still hosted on our servers, up until July 2023, where we made the switch to Confluence Cloud.
With Confluence being the most simple App of the three, we thought best to start with that. “Only” 136 Spaces, 22.550 Views and 2.500 Edits (Stats from Nov 23) and not too much custom configurations should make the transition easy and a good place to start our migration journey.
Today, about a year later, we are looking back at the migration itself, what we learned from it and give you the questions we know you should ask your users, because we did not.
We started to plan the migration in early 2023. After the initial decision for the move towards Cloud and a rough project plan we already had an info session for all colleagues and with it opened up the communication channel to the migration team. We were gonna conduct several test migrations, learning on the way and including several power users in at least the last stages of testing. Some of the technical difficulties we already planned for. Also we were gonna inform our collagues continuosly on our progress and teach them about the changes between Server and Cloud right after the migration.
It turned out, that even though there isn’t that much to configure in Confluence (compared to Jira anyway), Third-Party-Apps, the use of macros (even Atlassian native ones) and page restrictions made it complicated enough. (Fun fact: Even Confluence Admins cannot access pages, when they are restricted so if they are restricted to old users, they are lost in the limbo.)
The Confluence Cloud Migration Assistant (CCMA) was still under development. So much so, that there sometimes were multiple updates in a week and not always for the better. Between our final test and the productive migration, one of said updates (to the CCMA or Confluence itself) brought several minor issues with it, that we first thought were our mistake. It took quite some time figuring out whether those were bugs or features.
Especially after user testing we realised, that there are significant differences between the Server and the Cloud version, specifically in the Editor’s capabilities. The “new Editor” is restrictive when it comes to nesting macros - a feature a lot of our pages were using. The UI and UX for tables is completely changed. The migration team thought not much of it, the users were confused and missed a lot of features. Even though we had an extensive testing catalogue, we hadn’t thought of every possible scenario and constellation. That meant some “intensive care” and lots of communication with the Atlassian Migration support after the actual migration.
The plan was actually good and we stuck to it. On the technical side of things, a lot of trial and error worked out well. We would advise you to keep up with the updates Atlassian is bringing to the Migration Assistants as they make your life easier - they now are in a more stable state and already contain many more features than there were in summer.
Especially informing all colleagues early on and in between helped getting feedback and preparing anyone for the big day. They knew roughly what was going to change and we filled in the details by conducting trainings right after the migration. However, we would rather get them involved much earlier into testing and actually using the new environment. Considering ressources (time, money and such), giving more people early access would have generated more in-depth feedback and cover more test scenarios and use cases. There were plenty of differences that we didn’t cover in our Post-migration-training, because we weren’t properly aware of them.
We thought we knew how our colleagues are using Confluence, because… How many ways could there be? Turned out, people get creative and so they should. Asking them about their use cases and finding out more about how our collagues actually use Confluence would have enabled us to either teach the right functions and features in the training or get us a headstart on what Apps/Add-Ons we may need.
Also, be realistic about the change towards Cloud. There are ups and downs to it. We certainly upsold the whole thing to an extent and might have caused some unrealistic expectations that we now are dealing with. That comes to show in a survey we conducted in November. Only 36% thought that Confluence Cloud brings more value to their work than Confluence Server. For 15% Confluence Cloud wasn’t fullfilling their expectation regarding functionality and performance. On a positive note, over 70% thought otherwise.
Regardless of the survey, we are already picking up the slack - quite literally. We have a Slack-Channel where our colleagues can post any questions regarding Atlassian and where we, the Atlassian Team, post Tips & Tricks, info and news on a regular basis. We try to match the posts with frequently (or recently) asked questions and noticed that a lot of “issues” with the products tend to come from missing knowledge rather than not missing features. We will continue to teach our colleagues on the capabilities and use cases of the tools and start with regular training sessions again shortly.
We are keeping the communication channels open to receive feedback and feature requests so we can improve the Atlassian products beyond what Atlassian brings with their product development anyway. Staying on top of those product changes is just as important, so you are not surprised by major updates (they are usually available to all users right away). At our “ShipIt-Day” (our yearly innovation event) some colleagues will test Apps and more products to see which meet our needs and are worth the extra cost. We hope to inspect diverse use cases and user needs to get a holistic view on what our requirements are.
For our upcoming Jira Migration we will overthink our testing procedures and involve our colleagues even more on the practical side of things. Also, we will the checklist (see below) that includes the questions announced in the into.
There are plenty of Atlassian Solution partnes like ourselves, You can find a Partner close to you in the Partner Directory.
This checklist was created out of the experience migrating Confluence. It can, however, be used for any other Cloud or Function-complete migration. For Atlassian Server-to-Cloud Migrations there are additional ressources available through Atlassian.
Find out how the users in your company are using the product. Think outside the box to find unique and advanced use cases.
Questions to ask your users
What is the one function that you cannot work without?
What is the most complicated thing you ever did with Confluence (or any other product)?
What function do you know of, but never use(d)?
Which function would make your life easier? / Which function are you missing?
Who wants to become an Alpha/Beta/Final Tester for the Migration?
Find out what your most viewed/edited spaces are. Marketplace Apps can help with that.
Keep your users informed at all times
Explain your decision to go into Cloud and if there have been other options explored
Share your timeline and update it regularly
Communicate downtimes early enough so impact on their work is kept at a minimum
Keep a communication channel open for feedback, questions and suggestions
Make it easily accessible
Actively ask for feedback
Give them options to decide on where appropriate
Provide sufficient training
Talk about major differences between Server and Cloud
Use the chance to teach some basics and/or some helpful “advanced” features
Use FAQs oder AMA-Sessions for a low-level format with little time invest needed on all sides
Make sure to always upgrade your Apps, including the Cloud Migration Assistant. Also start with the most recent Confluence version.
Optimise and Clean up what you can and need on the Server/Data Center instance. With access to the Database you will be able to fix more things and much easier than it is in the Cloud.
Old users (if you don’t want to keep the reference)
Private spaces of inactive users
Archived and deletes spaces → Trash
Unused Marketplace Apps
Old content: You’ll need your users' help for that
…
Collect your users' Use Cases and use them as test scenarios
Create a designated space and use that as a Migration Test Space
Copy pages to that space that are special/complicated/use different macros
Use Page Restrictions, Blog pages, tables, attachements and other standard features
Match the space with your test scenarios
Involve your users
People from different (user) groups
Have them collect their own test scenarios
Give them access to your test migrations
Test different technical aspects
User migration and access
Permissions and restrictions
Content migration
Marketplace Apps
You can use free or Trial licenses to conduct multiple test migrations into seperate Cloud sites. If you use sites in different Atlassian Organisations you can test user migrations multiple times as well. Beware: Any migration will trigger Account creation for any email adress that hadn’t had an Atlassian Account until then.
Rebekka Heilmann _viadee_
IT Consultant
viadee Unternehmensberatung AG
Germany
192 accepted answers
1 comment