CCMA read-only after export
Platform Notice: Cloud and Data Center - This article applies equally to both cloud and data center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
Confluence Cloud Migration Assistant can move spaces individually from a Server to a Cloud instance. Some customers do this individually for testing purposes, or to move teams from Server to Cloud in phases. Frequently at the end of the testing phase, customers opt to do a full switch-over and migrate all their spaces/users from Server to Cloud over a weekend. This leaves the administrator wanting to lock the entire server instance for edits all at once.
The problem that arises is, that the customers want to leave their local instances online in case they (administrators and end users) need to verify particular pages have been migrated correctly. The administrators also want to give their users a softer landing for old links (a read-only page with an announcement banner telling them to go to Cloud) instead of a 404.
Fixes we currently provide
Method | Environment | Notes |
|---|---|---|
Maintenance Mode | Data Center | Puts the entire instance into a read-only state |
Modify space permissions | Server, Data Center | Very time consuming depending on the number of spaces |
Shut down the instance | Server, Data Center | Prevents edits while the instance is shut down. Doesn’t solve for redirecting users to Cloud or for data validation. |
Workarounds that customers are currently using
Method | What this solves | Implementation notes |
|---|---|---|
Announcement banner | Redirecting users to Cloud | Admins use a variety of crude to elegant popups via custom HTML in the header * *while the migration documents do link to this documentation, they don’t provide sample HTML/messaging to provide a better-than-crude experience |
Reverse proxy redirect | Redirecting users to Cloud | Varies heavily based on the customer’s server environment. The simplest method is a 301 redirect for all URLs at the Server address to the new Cloud address. This method doesn’t get users to the specific page they were clicking a link for (since the URL schemes vary between Server and Cloud). |
Reverse proxy permission lock | Preventing users from editing during migration | The administrator simply changes the proxy port for Confluence instance and puts a maintenance message on the regular Confluence proxy port. Permissions aren’t modified on the Server instance but end-users can’t access the site during migration. Very quick and simple to implement if the administrator is experienced with their reverse proxy. |
Expired license permission lock | Preventing users from editing during/after migration | If users have access to a Server license that expired before the current version they’re on is released (example: they have been our customer for 3 years, are on a recent release of Confluence, and can get the license from their previous renewal on my.atlassian.com), they can apply this to the instance and it will revert to a “no-edits” state due to the license being invalid for that Server version. |
Was this helpful?