Key Challenges & Context: Legacy Infrastructure, Massive Content Volume, and Plugin Debt
Our client is one of Switzerland’s largest municipal administrations, serving over 200,000 residents and coordinating services across dozens of departments, from urban planning and public works to social services and cultural affairs. Confluence had become the backbone of their internal knowledge management, supporting thousands of users across the organization, but their Confluence environment was showing its age.
Running on Confluence Server v6.7.2, the platform was several major versions behind, carrying years of accumulated content, outdated plugins, and user management debt. Before any Cloud migration could even begin, a mandatory intermediate upgrade and database migration were required just to reach a version compatible with Atlassian’s Cloud Migration Assistant.
Our client needed to modernize its collaboration infrastructure without disrupting the daily operations of a large public administration, and they needed to do it before Atlassian’s end-of-support timeline made the decision for them.
The Approach: Upgrade, Clean, and Migrate in Controlled Batches
Our client needed a migration path that accounted for the scale of their environment, the constraints of a public institution, and the technical debt accumulated over years of organic growth.
We designed a solution focused on reducing risk at every stage, from the mandatory pre-migration upgrade through to the final Cloud cutover.
Phase 1: Mandatory Upgrade and Database Modernization
The first step was non-negotiable. Confluence v6.7.2 could not be migrated directly to Cloud. We performed a mandatory Confluence upgrade through intermediate versions, including the associated database migration required to reach compatibility with Atlassian’s Cloud Migration Assistant (CCMA).
This phase alone would have been a project for many organizations. For an environment of this scale (569 spaces and 416,000 pages across all versions) the upgrade required careful planning to avoid data loss or corruption during the database schema changes.
Phase 2: Environment Cleanup and Validation
Before migrating a single page to Cloud, we conducted a thorough cleanup of the existing environment. This phase addressed three categories of technical debt:
1. Content sprawl and unused spaces
With 569 spaces accumulated over years of use, a significant portion was inactive, duplicated, or orphaned. We identified and cleaned unused spaces to reduce the migration scope to what actually mattered. Migrating dead content would have inflated licensing costs and cluttered the new Cloud environment from day one.
2. Plugin audit and removal of non-migrable apps
The Data Center environment relied on many outdated or unsupported plugins. For each one, we determined the migration path:
- Apps with Cloud equivalents and automated data migration: flagged for standard migration
- Apps with Cloud equivalents but no data migration path: flagged for reconfiguration post-migration
- Apps with no Cloud equivalent at all: flagged for functional replacement or decommissioning
Several plugins had no direct migration path. We worked with our client’s teams to identify alternative solutions or native Cloud capabilities that could replace the lost functionality.
3. User account validation
Thousands of users existed in the system, including duplicates, inactive accounts, and invalid identities that would block Cloud identity requirements. Atlassian Cloud enforces strict identity management through Atlassian Guard (formerly Atlassian Access), requiring each user to have a valid, unique email-based Atlassian account.
We validated user accounts, merged duplicates, deactivated invalid entries, and prepared the identity landscape for SSO and SCIM provisioning in Cloud.
Phase 3: Controlled Batch Migration
With the environment cleaned and validated, we prepared the migration plan using Atlassian’s Cloud Migration Assistant and executed it in controlled batches.
Rather than attempting a single big-bang migration of 416,000 pages, we divided the migration into waves:
- Structured checklists for each batch, ensuring nothing was missed
- Runbooks documenting the exact steps, rollback procedures, and validation criteria for each wave
- Multiple test migrations before each production batch, validating content integrity, permissions, and space configurations
- UAT cycles with key stakeholders from each department to confirm their content had migrated correctly
This batched approach, supported directly by Atlassian’s migration tooling and our team’s experience with large-scale migrations, reduced risk significantly. If an issue was detected in one batch, it could be resolved before affecting subsequent waves.
Benefits: A Modern, Secure, and Scalable Knowledge Platform
In just two months, our client transformed a legacy Confluence Server environment into a modern Cloud platform, eliminating years of technical debt and positioning the organization for long-term scalability.
Elimination of Server Maintenance and Security Risks
- No more manual upgrades. Atlassian Cloud delivers automatic updates, ensuring the platform is always on the latest version with the latest security patches.
- No more database maintenance. The infrastructure burden shifts entirely to Atlassian.
- Reduced security exposure. Cloud benefits from Atlassian’s enterprise-grade security infrastructure, SOC 2 Type II and ISO 27001 certified.
For a public administration managing sensitive citizen-related documentation, removing the risk of running an outdated, unpatched server was a significant governance improvement.
Flexible Licensing and Improved Authentication
- Atlassian Guard (SSO, SCIM) now manages authentication centrally, replacing the fragmented identity management of the Server environment
- User provisioning and deprovisioning are automated through our client’s identity provider, reducing administrative overhead and improving security posture
- Licensing tiers in Cloud offer more flexibility to scale users up or down as departmental needs evolve
Simplified Operations and Enhanced Integration
- Better scalability. Adding new spaces, users, or departments no longer requires infrastructure planning.
- Enhanced integration with Jira Cloud. Teams using both Confluence and Jira now benefit from native Cloud integrations (linked issues, Jira macros, automation triggers) that were limited or unavailable on Server v6.7.2.
- Access to modern Atlassian Cloud capabilities. Including Confluence whiteboards, databases, smart links, and AI-powered features that only exist in Cloud.
Lessons Learned and Recommendations
Our client’s migration demonstrates that even the most complex Confluence environments (legacy versions, massive content volumes, plugin debt) can be migrated successfully when the approach is structured and phased.
What made the difference:
- Treating the pre-migration upgrade as a distinct project phase rather than a footnote. The jump from v6.7.2 required careful database work that, if rushed, could have corrupted years of institutional knowledge.
- Investing in cleanup before migration, not after. Cleaning 569 spaces and thousands of user accounts before migration meant the Cloud environment started clean. No inherited debt, no inflated licensing costs.
- Batched migration with test cycles. For 416,000 pages, a big-bang approach would have been reckless. Controlled batches with UAT gave stakeholders confidence and caught issues early.
- Direct collaboration with Atlassian. The migration was supported by Atlassian’s tooling and guidance, leveraging the Cloud Migration Assistant and structured checklists designed for enterprise-scale moves.
What organizations in similar situations should consider:
- Start the plugin audit early. Apps with no Cloud equivalent require time to evaluate alternatives, and sometimes require process changes that stakeholders need to accept.
- Plan for identity management upfront. Cloud’s strict identity requirements (unique emails, Atlassian accounts) will surface every piece of user management debt accumulated over the years. Address it before migration, not during.
- Don’t underestimate content volume. 416,000 pages is not just a data transfer challenge. It’s a validation challenge. Every space needs someone to confirm the migration was successful.
- Factor in the end-of-support timeline. Server is already end-of-life. Data Center support ends in March 2029. The longer you wait, the more versions you’ll need to jump through, and the more technical debt accumulates.
Are You Facing a Similar Migration Challenge?
Legacy Atlassian environments don’t become unmanageable overnight. They accumulate complexity gradually, one plugin, one space, one workaround at a time, until the gap between where you are and where you need to be feels insurmountable.
This case shows that with the right assessment, cleanup strategy, and phased execution, even a 416,000-page Confluence Server environment running a version from 2018 can reach Cloud in two months.
The starting point is always the same: understanding the real complexity of your environment before committing to a timeline.
