Atlassian, the company that produces the popular software Confluence, is discontinuing Confluence Server, the self-hosted, non-cloud-based alternative to Confluence Cloud, Atlassian’s SaaS Confluence product.
On February 2nd, 2021, Atlassian officially stopped offering licenses for Confluence Server. On February 2nd, 2024, Atlassian stated they will end support for all server products, meaning support and bug fixes will no longer be available for any server products, including Confluence Server. Atlassian is making this switch to bring their customers greater flexibility, security, and customizability with their Confluence instances.
To support customers making the switch to Confluence Cloud, Atlassian has promised to provide “three years of support and maintenance for your server products”, although as the great David Bowie once told us, “ch-ch-changes” to this policy are possible.
For anyone still using Confluence Server after February 2024, there will be no support team available and no updates, bug fixes, or further improvements to the product. Therefore, most Confluence Server customers will need to transition to Atlassian’s SaaS-based solution, Confluence Cloud.
Migrating from Confluence Server to Confluence Cloud isn’t difficult, but it can be a lengthy process with many things to consider depending on your data security, data recovery planning, and compliance needs. The most important point to remember in this migration is that you are now more responsible for protecting your data than you were before, and must plan ahead to prevent unforeseen risk and loss once you’re fully onboarded to Confluence Cloud.
Are you also migrating from Jira Server to Jira Cloud? We’ve got a handy guide for that too.
Your new data security responsibilities on Confluence Cloud
When transitioning from a server-based product to a cloud-based product, it’s essential to understand how user responsibility shifts. Atlassian, like most SaaS products, follows the Shared Responsibility Model for cloud data.
Popularized by AWS, the Shared Responsibility Model delegates who is responsible for what when data is created, stored, and used in the cloud. Under this model, users and platforms share the responsibility for data security and continuity, including backups.
Platform providers like Atlassian are responsible for securing and backing up all of the data on their cloud products. If their data centers were struck by a meteorite tomorrow, Atlassian is responsible for platform-wide recovery. They could restore their customer’s data with little interruption.
However, if the problem was more localized (e.g., it only affected your account), Atlassian is not responsible for any data loss, corruption, or downtime. SaaS platforms back up all of the data from all of their accounts all at once; trying to find and restore the data that only pertains to your individual instance would be like searching for a needle in a field of haystacks. Atlassian’s backups simply aren’t set up for individual account-level data recovery.
Confluence Cloud’s terms of service clearly state these limitations. Atlassian’s terms include the statement: “WE ARE NOT RESPONSIBLE FOR ANY OF YOUR DATA LOST, ALTERED, INTERCEPTED OR STORED ACROSS SUCH NETWORKS. Furthermore, Atlassian clarifies that “WE WILL NOT BE LIABLE FOR DELAYS, INTERRUPTIONS, SERVICE FAILURES OR OTHER PROBLEMS INHERENT IN USE OF THE INTERNET AND ELECTRONIC COMMUNICATIONS.”
This means that if your Confluence Cloud data were to be corrupted, deleted, or compromised, Atlassian won’t be able to help you restore it.
And these types of account-level data disasters are more common than you’d think. Despite the popularity of news stories about AI, hackers, and malware, the most common cause of data loss is you. 90% of data loss incidents are due to “the human factor”; simply put, people make mistakes. Poorly configured third-party apps, malicious employees, and malware can also corrupt or delete your Confluence Cloud data. Furthermore, although system-wide outages are rare, they can happen. Atlassian is a leading company with a good reputation for security, but still experienced downtime in April of 2022.
With a Shared Responsibility Model, your obligations increase enormously. Your old backup and recovery methods, whether they were scripts or bulk exports you saved to a safe secondary location, will stop working. Even if you update them, backing up and restoring to any cloud product comes with restrictions.
Aren’t Confluence Cloud’s backups good enough?
Anyone with any experience in IT knows that backups are a good idea. With Confluence Server, it was simple to download data and securely store it in external storage, a desktop, or a hard drive. Confluence administrators could confidently point to the server room where backups were stored.
With Confluence Cloud (and most cloud-based products), backing up and restoring data is a little bit more complicated. Simply downloading data in JSON or CSV format doesn’t capture all of the data items and dependencies, for example, which pages belong to which spaces. Plus, a sea of JSON soup isn’t exactly helpful during a data emergency when critical information needs to be restored ASAP.
Atlassian’s CLI offers limited backup and recovery options for Confluence. Other backup options include a custom script or a dedicated backup and recovery solution like Rewind Backups for Confluence.
Data risk and loss through apps and permissions
Your Confluence Server instance likely relies on third-party plug-ins and custom software, which also carry new obligations in your Confluence Cloud future.
When migrating to Cloud, you need to ensure that they will migrate too (or you have a replacement app to fulfill that function). Luckily, Atlassian provides a checklist for app migration too.
It’s also best practice to review the security implications of the integrations and plug-ins you’ll be using in Confluence Cloud. Ensure they meet your internal security requirements, don’t ask for permissions they don’t need, and have support available to assist in case they don’t work as expected. Test out these apps and plug-ins on a test system before going live.
Data leakage occurs when sensitive data is unintentionally exposed or available to unauthorized parties or the public. A data leak and a data breach aren’t synonymous – breaches are intentional external intrusions (or attempts), where a leak is the result of employee negligence. Confusingly, sometimes data leaks can result in a data breach.
Data leakage in Confluence is possible without a good understanding of how permissions work, but there are best practices to protect your organization’s data, including limiting administrative permissions, limiting public view sites, and investing in data loss prevention policies for Confluence data.
How migration strategies impact your data security and recovery
Like your Confluence pages themselves, each migration is unique. Your chosen migration strategy will depend on your organization’s size, security requirements, and the level of customization you’ve implemented.
Whichever strategy you decide on, you will need to simultaneously build new processes—both human and technical—to handle backing up and recovering your Confluence Cloud data. This could be as simple (aka fragile) as downloading a .zip bundle of JSON/CSV to copy-paste somewhere else, a custom script that leverages the limited Atlassian CLI, or Rewind.
Please note that with all of these strategies, a test run or “dry run” is recommended—not just of the migration of your data itself, but also your new recovery plan. We’ll discuss the benefits of testing more below, but as all experienced IT pros know, there’s always “just one more thing”, and it’s typically better to find out about potential issues before your entire data set could be affected.
Optimize and shift
Optimize and shift is essentially what it sounds like: the first phase is to optimize your instance by removing inactive users and non-essential data, then perform a shift to your new cloud instance with a single downtime window.
Use the optimize and shift strategy when:
- You want to move to the cloud in a single migration window, with a single window of downtime.
- You have the time and resources to clean up your server (or can afford a consultancy or partner to help you).
- Your Confluence apps are available for Cloud, and have migration paths.
- You have robust backups of your on-prem data, just in case the optimization step doesn’t go to plan.
Pros:
- Everything is migrated at once, and you only migrate what you need.
- Reduced migration timeline and downtime
Cons:
- All users must be onboarded simultaneously.
- Requires a significant amount of downtime to shift.
- Requires extra work to determine which data and/or users should be migrated, and which should not.
Lift and shift
The lift and shift strategy is essentially the same as “optimize and shift”, but without the optimization step. In this method, you take all of your data — product data, users, and apps — and migrate it to Cloud in a single downtime window.
Use the lift and shift strategy when:
- You need to migrate your instance – fast.
- You don’t need or want to spend resources cleaning up your instance before migrating.
- Your Confluence apps are available in Cloud and offer migration paths.
- You’ve planned on robust backup/snapshot capabilities with a platform like Rewind for Confluence.
Pros:
- Everything is migrated at once.
- Shorter overall migration timeline.
Cons:
- Like “Optimize and shift”, all users have to be onboarded at the same time.
- There can be a long period of downtime, depending on the size of your data.
- You may migrate data that isn’t needed, increasing costs.
- Post-migration clean-up may be required to remove unneeded data.
Start fresh
The start fresh migration strategy is self-explanatory: you simply start fresh with a brand new Cloud instance. This strategy is ideal if you don’t need access to your legacy Server data.
Use the start fresh strategy when:
- You no longer need access to your Server data.
- You need to move to Cloud quickly.
- You’re spinning up a new team and want to rethink your cloud footprint.
- Your on-prem Confluence server has become untidy and you view the migration as an opportunity to clean and organize your content.
- You don’t want to worry about how a new cloud-informed data security/recovery plan works with all your existing data.
Pros:
- No or limited migration downtime.
- Server data can be archived with an active license.
- Good opportunity to clean up and review content.
Cons:
- Users won’t have access to old spaces/pages/data.
- Any data you need to move over needs to be reviewed and possibly manually migrated.
- Could be more labor intensive in the long term.
Phased migration
Phased migration involves migrating your data in two to four stages (or phases), rather than all at once. The phased migration strategy is the most complicated, and comes with the most risk. However, it’s ideal for teams with complex or large data shapes.
Use the phased migration strategy when:
- Some critical apps are not yet available for Cloud.
- You cannot migrate in a single migration window due to a very complex/large data shape with long downtime or internal business drivers.
Pros:
- User onboarding and management can be phased.
- Reduced single downtime.
- Allows for clean-up, optimization, and feedback as you progress through the phases of migration.
Cons:
- Longer overall migration timeline, potentially increasing cost.
- Increased complexity of multiple migrations requires more expertise and planning.
- Temporary hybrid models can be difficult for cross-team collaboration.
Realistic migration timelines and impacts on data security
Migrations from Server to Cloud can vary in how long they take to complete, but it’s a good rule of thumb to leave yourself some extra time. For reference, here is are some estimated timelines from Atlassian on how long you can expect your migration to take:
- Up to 1,000 users: ~3 months
- 1,000 to 5,000 users: ~6 months
- 5,000+ users: ~9 months+
As you can see, migration isn’t a quick process. It’s essential to plan ahead to ensure you can complete your migration before Confluence Server is discontinued in February 2024.
To get a better idea of what processes you should plan for, Atlassian offers a Confluence pre-migration checklist. You should really read the entire thing, but we’ll summarize some key steps for you here, with one essential addition to the planning phase:
- Assess: First, evaluate the benefits and drawbacks of migration and determine if it’s the right choice for your organization. If your Confluence Server instance is no longer actively used, you may consider switching to a different internal knowledge base, but if your organization will continue to need access to Confluence, you’ll want to switch before February of 2024, or risk the lack of security updates and support.
- Plan: In the planning phase, you need to determine your migration strategy. Outline your plan of attack, including necessary steps, key stakeholders, and potential timelines.
- Backup: Ensure you have a backup of your current data before moving ahead, and begin scoping the new technical requirements of how you’ll continue your backup/snapshot strategy under the new Shared Responsibility Model.
- Prep: It’s time to prep your team responsible for this migration: are they aligned? Are they prepared to carry out the plan effectively? Do they have the necessary access to Confluence Server, Confluence Cloud, and unzipped Confluence space exports? Atlassian also notes that you’ll need to upgrade Confluence Cloud Migration Assistant to 3.3.7 or higher. You’ll also need to address all duplicate user names and email addresses, as the Migration Assistant will flag duplicates and won’t allow the migration to run until all users have unique usernames.
- Test: No good plan survives first contact with the enemy, so it’s best to test your migration strategy before committing to the final push. This will help your team evaluate their procedures for data transfer and how the migration strategy you chose is working. Your test will also give you a good idea of how long your full migration will take, allowing you to better plan and prepare for downtime.
- Migrate: You’ve planned, prepped, and tested: now it’s time to migrate. Be sure to warn your wider organization that they may experience some downtime as the migration process completes.
- Launch: Now that you’ve successfully migrated to Confluence Cloud, it’s time to help your users adapt and learn the new environment. You’ll also need to decommission your Confluence Server instance.
Those are the rough steps involved with migration, but again, every Confluence instance is different and its migration will be unique. Utilize Atlassian’s extensive Migration Resource Centre to determine the best strategy for your Confluence migration.
It’s also a good idea to have a backup plan: if something goes wrong during migration, a clean and up to date copy of your data will help you recover. A backup and recovery app like Rewind Backups for Confluence can take an extra backup snapshot of your entire instance whenever you’d like, as well as restore data if any unexpected issues arise.
Wrapping up
With Confluence Server moving to end of life, you’ll need a backup solution for Confluence Cloud. Rewind is purpose-built to ensure data security and availability in Confluence, including during delicate situations such as migrations. The bulk export feature adds just another layer of security by allowing you to easily download your backups for your third, extra, just-in-case backup snapshot.
How many Confluence users are in your organization?
While “migration” brings to mind images of long, arduous journeys, the shift from Confluence Server to Confluence Cloud doesn’t have to be painful. With some planning and prep your organization will be in the clouds in no time.
James Ciesielski">
