Short answer: Most teams overestimate the difficulty of leaving Confluence and underestimate the discipline required to do it well. The actual hard part isn't moving the content — it's deciding what NOT to move. This is the playbook.

It applies whether you're moving to Stride, Notion, Slab, GitBook, or a self-hosted alternative. We use Stride as the running example because that's what we ship.

The 30-day shape

Days 1-7: Audit. Decide what stays in Confluence, what migrates, what gets archived, what dies.
Days 8-15: Migrate the critical 20% to the new tool.
Days 16-23: Make the new tool canonical. Confluence becomes read-only.
Days 24-30: Decommission what wasn't migrated. Retrospective.

If your audit finds 5,000 Confluence pages, this timeline still works — you'll just migrate fewer of them. Most teams find that ~80% of their Confluence content is read by nobody and shouldn't move.

Days 1-7: audit

What you're inventorying

Three categories:

Living docs. Pages updated in the last 90 days with multiple authors. These are doing real work — process docs, runbooks, onboarding, decision logs. Migrate.

Reference docs. Pages last updated 6-36 months ago that still get read (check Confluence analytics — most install Analytics for Confluence by default). These might migrate, or might stay in Confluence as an archive. Decide page-by-page.

Dead docs. Pages last updated 2+ years ago, near-zero views, often duplicated by newer pages. These don't migrate. Archive the Confluence space and move on.

The honest distribution for most teams: 5% living, 15% reference, 80% dead. The dead category isn't a moral failure; it's the natural lifecycle of internal documentation.

Per-living-doc decision

For each living doc, decide:

Migrate as-is. Doc is canonical, structure works, lift-and-shift makes sense.
Migrate with restructure. Doc has good content but poor structure (10-screen wall of headings); split into smaller pages during migration.
Migrate as part of a hub. Doc belongs in a topical cluster (sprint planning runbooks, security runbooks, onboarding sequence). Group during migration, not after.
Don't migrate; rewrite. Doc is stale, outdated, or anchored to old terminology. Faster to rewrite than to migrate then fix.

The temptation is to migrate everything because "we might need it later." Resist. Every doc you migrate is a doc you commit to maintaining in the new tool. Smaller migration = healthier system.

Days 8-15: migrate the critical 20%

Choosing the parallel project

Pick the team or topic with the most painful Confluence experience today. Common picks:

Engineering onboarding. New-hire docs that haven't been updated since the last major refactor — migration forces an update.
Incident runbooks. Time-critical content; finding the right runbook in Confluence's search is slow.
PRDs / specs / ADRs. Cross-functional content that engineering wants out of Confluence (Confluence is a poor fit for technical artifacts).

Don't migrate everything at once. One team, one workflow, one week.

The migration script

For each doc:

Export from Confluence. Markdown export (Confluence native or via Scroll Exporter add-on) is the cleanest format. HTML export is acceptable but requires more cleanup.
Strip Confluence-specific markup. Macros, panel boxes, info macros — most don't have equivalents in the target tool. Replace with the closest semantic equivalent (callouts, code blocks, table markdown).
Update cross-references. Confluence internal links (/wiki/spaces/SPACE/pages/123456) need to be rewritten to target-tool URLs. Most teams use a sed-script for batch replacement; the URLs are mechanical.
Re-anchor in the target structure. Each migrated doc gets a parent (team / topic / hub). Don't dump everything at the root.
Notify the team. New URL added to Slack pinned messages, doc-finder runbooks updated.

Stride-specific notes

Stride doesn't try to be a wiki replacement. The model is: long-form documentation lives in Stride if it's directly tied to a delivery artifact (PRD → epic, ADR → architecture decision, runbook → process node). Free-form team docs and HR/legal docs typically stay in a separate doc tool (Notion, GitBook, Slab) or get archived.

If you're moving FROM Confluence and your Confluence is mostly delivery-tied content (PRDs, ADRs, runbooks), Stride consolidates. If your Confluence is mostly free-form team wiki content, you want a Notion-style tool, not Stride.

Days 16-23: cutover

On day 16, every Confluence Space that had migrated content gets one of three statuses:

Read-only. Permissions reduced to view-only across the org. New edits go to the new tool. This is the dominant status for the first month — gives people a chance to find anything that didn't migrate.

Archived. Permissions reduced to view-only for admins only. Used for spaces that were mostly dead-doc territory. Hidden from default search.

Deleted. Only for spaces explicitly identified as having zero living content + 6+ months no views. Most teams don't delete in this phase; they archive and revisit at day 60.

The cutover communication template:

Today, [team/topic] documentation moves to [new tool]. Confluence is now read-only for [list of spaces].

Where to find things:

[list of common workflows with new URLs]

What didn't migrate: [honest list]. If you find something missing that you need, ping #migration-help and we'll add it.

Why we're doing this: [one-sentence reason]. The migration finished today; the rest of the month is about getting comfortable.

The "what didn't migrate" honesty matters. People will find things missing. If you preemptively name what didn't migrate, the surprise is smaller.

Days 24-30: decommission

Checklist

Reduce Confluence seat count to read-only tier (Atlassian often supports this directly; check current pricing).
Export all migrated spaces via Atlassian's bulk export. Archive to S3 with 7-year retention.
Update every internal Slack channel description, Slack pinned messages, onboarding docs, and email signature templates to reference the new tool.
Audit any integrations (Jira ↔ Confluence cross-references, Slack notifications, search integrations). Migrate or disable.
Tell finance to terminate any Confluence add-ons on the next renewal.

Retrospective questions

Three:

1. What surprised us? Usually: "more dead content than expected" and "the migration was easier than feared but the editorial decisions were harder than expected." Document for the next cleanup.

2. What broke? Be specific. "We didn't migrate the partner-API runbook and discovered it on day 19" matters; "people complained for the first three days" doesn't.

3. What's the 90-day cost delta? Don't compute at day 30 (still paying both bills). Set a calendar reminder for day 90 to do the real math.

When this playbook doesn't fit

Two patterns:

1. Your Confluence is mostly compliance documentation. SOX, GxP, FDA, GDPR-mandated docs with audit trails Confluence captures and the target tool doesn't. Migration risk-reward is bad. Stay on Confluence for compliance content; move other content selectively.

2. You can't get exec sponsorship for the cutover. "Read-only Confluence on day 16" requires permission. Without it, the migration degrades into "running both forever." Don't start.

For everyone else: the 30-day window works. The hardest part isn't the new tool — it's the discipline of not letting Confluence stay write-capable past day 16, and the discipline of deciding what to leave behind.

If you're considering Notion as the Confluence-replacement, this is the procurement-stage comparison with Stride.

See Stride vs Notion

How to migrate from Confluence to a structured doc tool