One of the most consequential and underestimated decisions in a Confluence or Jira Data Center → Cloud migration has nothing to do with tooling, APIs, or migration paths.
It’s a philosophical question that every organization eventually faces:
Do we bring everything with us, or do we use Cloud as a reset?
At small scale, this question feels academic. At enterprise scale, hundreds of thousands or millions of pages and issues, it becomes a defining factor in cost, usability, security, and long‑term success. Below is a grounded look at the three approaches most teams consider, and why none of them fully solves the problem on its own.
| Approach | Strengths | Tradeoffs |
| Lift & Shift Everything | No perceived data loss, single system of record, minimal upfront decisions | High cost at scale, security/compliance risk, noisy search & AI, permanent clutter |
| Start Fresh | Clean Cloud instance, lower cost footprint, intentional architecture | Loss of historical context, system‑hopping, shadow re‑creation of content |
| Hybrid | Balanced risk, reduced Cloud bloat | Heavy human effort, subjective decisions, long timelines, migration fatigue |
tl;dr Migration strategy matters but governance matters more. Without classification and retention from day one, your Atlassian Cloud will inherit the same sprawl, risk, and (possibly even higher) cost as Data Center, just faster.
Let's dig in
⚠️ This approach is usually driven by caution ⚠️. The thinking goes something like: we might need it someday, and deciding what to cut is risky. In a Data Center world, that instinct was often rewarded. Storage felt cheap, security felt contained, and the cost of keeping things around was mostly invisible.
In Cloud, the math changes.
Bringing everything over preserves continuity and avoids difficult conversations. Teams feel safe knowing no knowledge was lost, and users don’t have to context‑switch between systems. But in practice, this strategy quietly compounds problems. Every outdated page, duplicated space, and long‑forgotten Jira issue now contributes to higher storage costs, noisier search results, degraded AI relevance, challenging site performance, and increased compliance exposure.
Result: What used to be benign clutter becomes operational drag, and in some cases, real risk.
The opposite extreme treats Cloud as a clean slate. Instead of migrating history, teams rebuild only what they believe they need going forward. Information architecture is redesigned. Templates are modernized. Ownership models are clarified.
On paper, this is incredibly attractive. Cloud stays lean. Costs are controlled. Governance is simpler.
In practice, this approach often underestimates how deeply historical knowledge is woven into day‑to‑day work. Users inevitably need context from old decisions, past incidents, or legacy documentation. When that information lives only in a retired Data Center instance, people are forced to pivot between systems, or worse, recreate content manually in Cloud without structure or standards.
Result: A slow re‑accumulation of mess, just in a different form.
Most organizations land here by default.
The idea is reasonable: migrate high‑value content, archive or retire the rest. In theory, this strikes the perfect balance between continuity and cleanliness.
In reality, hybrid migrations are the hardest to execute well.
Someone has to decide what actually matters. At scale, ownership is unclear, context is missing, and content value is subjective. The pages that look unused are often the ones people scramble for during audits, incidents, or onboarding. Teams spend months debating edge cases, reviewing content manually, and burning energy on decisions that don’t age well.
Result: Hybrid isn’t wrong, it’s just human‑intensive, fragile, and difficult to sustain.
If you’re going to take the hybrid approach, it needs structure. Without a clear playbook, teams either over‑migrate out of fear or stall indefinitely trying to evaluate everything.
A workable hybrid strategy usually unfolds in layers, not one giant decision.
Start with content that is unquestionably critical to operating the business. This typically includes high‑value Jira projects and Confluence spaces tied to core functions. Think active product and engineering projects, legal documentation, HR and recruiting workflows, finance and operations, security and compliance materials. These areas tend to have clear ownership, ongoing usage, and real downside if context is lost.
From there, apply a time‑based safety net. A common and effective heuristic is to bring over any content that has been meaningfully updated within the last year or two. Recency isn’t a perfect proxy for value, but at scale it’s one of the best signals available and it dramatically reduces debate while still preserving living knowledge.
Finally, create a clear escalation path for exceptions. No filter will catch everything. Teams should have an easy way to flag additional pages, spaces, or Jira projects that fall outside the default rules but are still important. This shifts decision‑making closer to the people who actually need the content, without requiring them to manually sift through everything up front.
Crucially, this model assumes you do not shut off Data Center immediately. Keeping the DC instance running in a read‑only state for a quarter or two is often the difference between confidence and chaos. Read‑only access allows teams to notice what’s missing during real work, rather than guessing during migration planning. When gaps surface, they can be flagged and pulled into Cloud deliberately instead of reactively.
The goal isn’t to get the migration "perfect" on day one. It’s to make sure what matters most is available immediately, while giving the organization a controlled way to discover and justify what else truly needs to come along.
No migration strategy, lift-and-shift, fresh start, or hybrid, solves this problem on its own. The most important decision, regardless of which path you choose, is whether Cloud is treated as a passive destination or an actively governed system from day one.
Without governance, every strategy eventually collapses into the same outcome: unchecked growth, unclear ownership, rising risk, and another painful cleanup cycle a few years down the line.
Operating in Atlassian Cloud intentionally means rejecting the idea that migration is the finish line. Instead, governance must be part of the starting conditions. That includes:
Clear content classification (what type of information is this?)
Explicit retention expectations (how long should it live?)
Ownership signals (who is accountable?)
Automated lifecycle enforcement, not manual heroics
This is where tools like Content Retention Manager become foundational. Not as a post-migration cleanup utility, but as infrastructure that ensures new Cloud instances never drift into the same “keep everything forever” posture that Data Center quietly enabled.
When classification and retention are in place from day one, migration choices become safer, AI stays high-signal, compliance posture improves, and Cloud remains clean by default, regardless of how much data you bring over.
Darin - Opus Guard
Head of Product - Opus Guard
Opus Guard
San Francisco Bay Area, CA, USA
1 comment