Migrating from Confluence Data Center to Confluence Cloud can feel overwhelming, especially if you’re worried about feature differences, pricing changes, missing apps, or how your teams will find and trust content afterward. In this guide, you’ll learn what truly changes when moving to Confluence Cloud—from key differences and pricing to app impact and readiness checks—and how to avoid the common surprises that trip up first-time migrations.
What does it really mean to migrate to Confluence Cloud?
Migrating to Confluence Cloud simply means shifting from a self-managed, on-prem/Data Center environment to Atlassian’s fully hosted platform. With Atlassian Data Center approaching end-of-life milestones, many organizations are moving now – either to avoid rising infrastructure costs or to access Cloud-only features.
But migration isn’t just a technical event. It’s also an experience shift. Teams often discover that the real challenge isn’t “moving pages,” but ensuring people can still find, trust, and use what they find after migration.
Confluence Cloud vs. Confluence Data Center: What Are the Differences?
Hosting & Responsibility Model
With Confluence Data Center, you’re responsible for hosting, hardware, upgrades, security patches, and scaling. IT teams maintain everything: from load balancers to database clusters.
In Confluence Cloud, Atlassian manages the entire infrastructure. You no longer worry about servers, performance tuning, or patching. This usually lowers overhead, especially for teams previously juggling complex DC deployments.
Feature Differences
Cloud isn’t a carbon copy of Data Center. Some DC features don’t exist on Cloud, and Cloud offers capabilities you won’t find on your servers.
Here’s a high-level comparison:
| Area | Confluence Cloud | Confluence Data Center |
|---|---|---|
| Hosting | Managed by Atlassian | Self-managed |
| Updates | Continuous | Version-based |
| Automation | Built-in | Limited / App-based |
| Company Hub concept | Available via Home, spaces, apps | No native “hub” |
| Custom CSS | No | Yes |
| AI-enhanced search | Available | Not available |
| Apps | Different ecosystem | Larger legacy app base |
What to watch out for? Many DC customers expect Cloud to give them the same deep customization freedom-CSS overrides, nested macros (supported in DC), custom plugins, and UI-level control.
Cloud prioritizes consistency, security, and reliability across all customers, which limits the level of UI and layout customization that was possible in Data Center.
It’s also important to note: even when a Confluence Data Center app does exist in Cloud, this doesn’t always mean its data, macros, or historical configurations migrate automatically. In many cases, apps require manual reconfiguration after migration, and some historical data or macro behavior may be limited or unavailable. This is why app testing and validation in a Cloud sandbox is critical before committing to production migration.
Release Cadence & Innovation
Cloud products evolve continuously. Improvements and new features are rolled out incrementally—often weekly—and are applied automatically in the background. In many cases, no administrative action is required. However, administrators may occasionally need to review new settings, update governance rules, or communicate UI changes to users.
In contrast, Data Center follows a version-based release model. New features and fixes are bundled into major or minor releases that require planning, testing, and manual upgrades, which can significantly slow down innovation.
As a result, Cloud customers generally benefit from:
- Faster feature rollouts
- Earlier access to new capabilities
- Continuous innovation, including AI-powered enhancements such as natural-language search and smarter automation
At the same time, Atlassian recognizes that not all organizations want immediate exposure to every change. On Cloud Premium and Enterprise plans, customers can activate Release Tracks, which allow them to control when new features become visible to users. This provides additional time to:
- Review upcoming changes
- Prepare internal documentation or training materials
- Communicate proactively with users before features are enabled
Release Tracks help larger or more regulated organizations balance the speed of cloud innovation with the need for change management and user readiness—an option that is not available in the traditional Data Center release model.
Customization & Extensibility
Your developers may feel the shift away from direct system access and custom Java plugins toward Cloud’s controlled, API-based extensibility most.
Cloud removes:
- Direct DB access
- Custom Java plugins
- CSS/HTML UI overrides
- File-system level scripts
Cloud adds:
- Atlassian Forge (safer, API-based app framework)
- Declarative app models
- Lower security risk
If your DC environment relies heavily on custom interfaces, branded intranet-style experiences, or UI scripts, you’ll want to evaluate alternatives early. Get in touch with our Custom Development team to find the best option for you.
Performance & Scalability Considerations
On DC, performance depends heavily on hardware tuning.
On Cloud:
- Atlassian handles scaling
- You get regional data residency available in 11 different regions
- Latency is generally consistent
- Global collaboration becomes easier
Large datasets may require cleanup before migration so cloud search and indexing remain reliable.
Security, Compliance & Data Residency
Cloud includes enterprise-grade security certifications: SOC2, ISO 27001, GDPR alignment, and more, outlined on Atlassian’s Trust Center.
You can choose where data is stored (EU, US, Australia, etc.) and use Atlassian Access to enforce SSO, SCIM, and enhanced audit logs.
Admin & Governance Differences
Cloud simplifies much of the administration:
- Centralized user management
- Atlassian Access for identity governance
- Robust audit logs (especially in Premium)
Admins often appreciate that governance becomes more predictable, though some enterprise teams miss the absolute control DC allowed.
UI and Content Experience Differences
Cloud introduces:
- A modern page editor
- More consistent navigation
- Space-level analytics, along with the Content Manager to help space admins easily track, review, and maintain content
- A native “home” entry point
- New content types such as folders, databases, and whiteboards
- Smart Links that turn pasted URLs into rich, interactive previews
- A broader and more powerful macro set, including cloud-native macros
- Deeper, more seamless integration with Jira, enabling better linking between work and documentation
This is often where expectations around customization clash with Cloud realities.
Organizations coming from Confluence Data Center frequently rely on custom user macros or heavily tailored page layouts to support their knowledge hubs and intranet use cases. In Confluence Cloud, these server-side customizations are not available out of the box and need to be recreated as Cloud-ready solutions, typically using Forge apps.
If your instance includes custom user macros, these can be rebuilt as Forge apps in Cloud. Our custom development services can handle this transition, allowing teams to focus on content migration and adoption instead of technical reimplementation.
Similarly, if your Confluence Data Center UI was heavily modified using theming or intranet apps such as Linchpin or Communardo’s Enterprise Theme for Confluence, Mantra provides a Cloud-native alternative. Mantra enables custom navigation and theming to recreate a familiar intranet experience while aligning with your corporate identity.
Pricing: Data Center vs. Confluence Cloud
High-Level Pricing Comparison
Cloud pricing is subscription-based, whereas Data Center requires large annual renewals plus infrastructure investments.
Both Cloud and DC offer tiered pricing per user. See Atlassian’s breakdown here.
Total Cost of Ownership (TCO) Considerations
Cloud eliminates costs related to:
- Servers
- OS licensing
- Database maintenance
- Network, load balancing, VPN
- Manual upgrades
Most teams find Cloud is cheaper long-term, even if subscription prices feel high at first.
Atlassian Data Center End of Life & Cost Implications
As Atlassian Data Center products move toward end-of-life stages, renewal costs rise and support is gradually reduced. End of life doesn’t mean systems stop working overnight, but it does introduce real operational risks: fewer security and bug-fix updates, limited vendor support, slower issue resolution, and growing compliance and audit challenges over time.
Delaying migration means:
- Higher renewal fees
- Paying for infrastructure you will eventually abandon
- Increased security, compliance, and operational risk
- Losing access to Cloud-only features and innovations
Apps: Confluence Data Center vs. Cloud
What happens to your existing apps?
This is often one of the most overlooked migration challenges. Many Confluence Data Center apps do not have a 1:1 Cloud equivalent. Even when a Cloud version exists, features may differ, or the app may behave differently than teams expect.
There are, however, best-case scenarios. Some widely used apps—such as draw.io or Aura—offer well-supported Cloud versions with dedicated migration paths, allowing diagrams, formatting, and macros to move over with minimal effort. These apps demonstrate how smooth an app migration can look when Cloud parity and tooling are in place.
For many other apps, migration is less straightforward. Data, macros, or historical configurations often do not migrate automatically, and Cloud apps typically require manual reconfiguration after content has been moved. In some cases, historical data or specific macro behaviors may be limited or unavailable in Cloud.
This is why even technically successful migrations can still feel disappointing: pages may migrate cleanly, but workflows tied to apps often break or need to be redesigned.
How to check compatibility?
A beginner-friendly approach:
- Export your DC app list (In the Confluence Migration Assistant this is normally automatically indicated)
- Search each app on Atlassian Marketplace
- Check whether a Cloud version exists
- Review differences in functionality
- Test in a Cloud sandbox
If an app is missing, choose one:
- Plan A: Replace with an alternative Cloud app
- Plan B: Redesign the process
Seibert apps that help with common Cloud friction
Many teams migrating from DC worry about losing structure or brand consistency. These apps help:
- If teams miss DC-style structured, branded pages/hubs → Mantra (page builder).
- If pages become hard to scan after migration → Aura Formatting (page structure components).
- If you need a more “site-like” navigation across spaces → Navigation Menus
- If you rely on diagrams → draw.io for Jira and Confluence
These solve the common “Cloud looks plain” or “We need theming” concerns.
Handling app gaps during migration
Start by creating an app readiness list with four clear categories: must-haves, nice-to-haves, replaceable, and no-longer-needed. For each must-have app, document the exact features or workflows it supports—not just the app name—so Cloud alternatives can be evaluated accurately.
This assessment should explicitly include custom-developed scripts, user macros, or internally built apps. In many cases, these custom solutions are no longer required because Cloud-native Confluence features already cover the use case, or because a Marketplace app provides equivalent functionality with less maintenance effort.
For apps and custom solutions without direct Cloud parity, decide early whether to:
- Replace them with a Cloud-native alternative
- Redesign or simplify the workflow using built-in Cloud features
- Rebuild the functionality as a Forge app
- Retire the app entirely if it no longer provides sufficient value
When rebuilding is necessary, investing in Forge training or leveraging Seibert’s custom development services can significantly reduce risk and implementation time.
Review vendor roadmaps to understand which features are planned versus unavailable, and validate critical apps in a Cloud sandbox. During testing, focus on macro behavior, data migration completeness, permissions, and user experience—not just whether an app installs successfully.
Early testing reduces post-migration surprises and helps teams adapt workflows before go-live, rather than reacting once users are already impacted.
Cloud Readiness – A Checklist That Reflects the Real Risks
The most successful migrations aren’t the fastest – they’re the ones that plan for the “experience layer.”
Here’s a simple, honest readiness checklist:
| Area | Green (Ready) | Yellow (Needs clarity) | Red (High risk) |
| Hub/navigation plan | Cloud navigation & hub approach defined (e.g., Company Hub or equivalent structure) | Draft concept, ownership, or scope unclear | No plan for central navigation or hub experience |
| Findability | Clean labels, titles, and search behavior reviewed | Known duplicates or inconsistent naming | Search distrust / content hard to find |
| Automation | Cloud automation use cases identified and mapped | Potential use cases identified, not validated | No plan to use Cloud automation capabilities |
| Governance | Cloud groups, permissions, and ownership defined | Partially defined or inconsistently applied | No Cloud permission or ownership model |
| Apps | Cloud app assessment | Known parity gaps or replacements needed | App status unknown or unvalidated in Cloud |
Common Confluence Cloud migration pitfalls
- Macros don’t make the trip: deprecated, unknown, or unsupported
- Missing files or broken attachments
- Broken links to Jira
- Users not trained on new Cloud features and differences
- Apps work differently or don’t exist in Cloud
Key Benefits of Confluence Cloud
Cloud brings real advantages, especially when paired with thoughtful structure:
- Rapid innovation and continuous improvement
- Lower total operating cost
- Improved search relevance (and AI-assisted discovery)
- Built-in automation for notifications and workflows
- Better collaboration UX and analytics
These benefits shine brightest when organizations rethink their navigation and content strategy, not just copy DC structures.
How a Confluence Cloud Migration Typically Works (In Practice)
A Confluence Cloud migration isn’t a single “copy and paste” event. Most organizations migrate using Atlassian’s Cloud Migration Assistant (CMA), which guides admins through assessing, testing, and executing the move.
Migrations can be done:
- All at once, moving the entire Confluence instance
- Space by space, which is common for large or regulated organizations that want phased validation
In general, the following migrate automatically:
- Pages and page history
- Attachments and comments
- Spaces, users, and basic permissions
However, several areas typically require manual review or validation, including:
- Marketplace apps and their data
- Macros that behave differently in Cloud
- Permissions, especially group-based access
- Links, templates, and automations
For this reason, most teams run at least one test migration in a sandbox to validate content accuracy, app behavior, and user access before migrating production data. Successful migrations focus not just on data transfer, but on ensuring users can still find, trust, and work with content once they’re in Cloud.
Confluence Cloud Migration: How-To in a Few Easy Steps
Step 1: Assess and Plan
Inventory all apps, review existing processes and use cases, align key stakeholders, and define a realistic migration timeline based on complexity.
Step 2: Prepare Your Instance
Clean up outdated or duplicate pages, confirm app parity, review permissions, and configure any required integrations such as Teams or Slack.
Step 3: Test and Validate
Use Atlassian’s Cloud Migration Assistant in a sandbox to test data accuracy, app behavior, and user access.
Step 4: Execute the Migration
Schedule the migration during a low-activity period and communicate clearly with all users.
Step 5: Post-Migration Optimization
Verify content, permissions, and space structures; update links and ensure search works properly.
Step 6: Continuous Improvement
Monitor Cloud updates regularly, adjust governance, and refine content as your teams grow.
FAQs
Is Confluence Cloud more expensive than Data Center?
Confluence Cloud is usually not more expensive than Data Center. Even if subscription pricing seems higher at first glance, Cloud removes infrastructure, maintenance, upgrade, and hosting costs. Most organizations find Cloud cheaper over 2-3 years once Total Cost of Ownership (TCO) includes not just license fees, but also infrastructure, hosting, upgrades, maintenance effort, security patching, and the internal operational time required to run Data Center.
Will my current Confluence apps work in Cloud?
Some will, some won’t. Even when an app exists on both Confluence Data Center and Cloud, the feature set and migration behavior can differ, so each app must be evaluated individually.
There are best-case examples. Apps like draw.io and Aura provide straightforward migration paths, allowing diagrams, formatting, and macros to migrate cleanly so teams can continue using the apps in largely the same way, regardless of hosting model.
Other apps follow a partially manual migration approach. For example, migrating from Blueprint Creator to Properties supports some content and configuration, but not all historical data or behaviors, requiring post-migration validation and adjustments.
Because of these differences, always review each app on the Atlassian Marketplace, consult the migration documentation, and validate behavior in a Cloud sandbox before migrating production content.
How long does a Confluence Cloud migration take?
Small teams may finish in days; large, regulated organizations often need 2-6 months. The timeline depends heavily on app parity, content cleanup, and how much redesign you do for navigation, hubs, and automation.
A Final Thought: Migration Is a Fresh Start, Not Just a Move
Most organizations treat Confluence Cloud migration as a technical transfer, but it’s closer to a renovation. You’re rebuilding a knowledge space that employees will rely on every day. With the right structure, apps, and governance, Cloud can feel cleaner, faster, and easier to use than any Data Center setup.
And if parts of that renovation involve custom apps, scripts, or workflows that don’t make the jump to Cloud on their own, our Custom Development team can help recreate or modernize them using Cloud-native technologies—so you keep what works, without holding on to what doesn’t.