☠Saaspocalypse
← Confluence · Wiki & Docs
Plan de migration

Migrer hors de Confluence — phase par phase.

Les migrations Confluence se jouent sur trois spécificités : le format de stockage est du XHTML avec une forêt de macros `ac:` qui ne traduisent pas proprement en Markdown, les restrictions de page héritent via la hiérarchie d'espace d'une manière non-obvious, et le contenu passe sur MDX-on-disk + un vrai index de recherche (Typesense ou Postgres tsvector) qui remonte enfin des résultats pertinents — la complainte la plus fréquente sur Confluence.

10-14 weeks de bout en boutForfaitParallel run avant basculeLe code est à vous

Les phases, taillées pour Confluence

Chaque phase ci-dessous, c'est la version spécifique Confluence de notre démarche standard. Même structure à chaque mission, des détails par SaaS.

  1. Spaces + restriction audit

    1-2 weeks

    We inventory every space, every restricted page, every Marketplace macro in active use, and the URL hierarchy that external systems (engineering docs links, customer-facing help articles) depend on.

    ✓List every space, its admin, and the number of pages + total view count over 90 days
    ✓Identify spaces that haven't been viewed in 90 days — most large Confluences have 30-40% archive candidates
    ✓Audit page restrictions (view + edit) and surface the inheritance model
    ✓Catalogue Marketplace macros in use (Drawio, Scroll, Refined, etc.) — each needs a replacement strategy
    ✓Map URLs to preserve: page IDs, slugs, /wiki/spaces/{KEY}/pages/{ID}/{slug} structure
    Ce que vous repartez avec

    A Space Inventory + restriction map + macro replacement plan + the URL preservation list.

  2. Content model + storage strategy

    1 week

    Pages become MDX files in a Postgres-backed CMS, with version history preserved. The `ac:` storage format gets converted to MDX with our own components replacing the most-used macros (Drawio → mermaid + image, panel → callout component, etc.).

    ✓Design `pages` table (parent_id, space_id, slug, mdx_source, version, restricted_to)
    ✓Design `page_versions` table to preserve history
    ✓Preserve Confluence `page_id` as a column for backwards-compatible URLs
    ✓Map the macro inventory: Drawio → mermaid + S3 image, Scroll → version-controlled MDX branches, Refined → first-class theming, info/note/warning panels → our own callout component
    ✓Plan search: Typesense (or Postgres tsvector) over MDX + metadata + a 1-hour reindex
    Ce que vous repartez avec

    Schema migrations + an MDX component library + a documented macro replacement table.

  3. Extract via Confluence REST API

    2 weeks

    Confluence Cloud's REST API exposes pages, spaces, comments, attachments and permissions. The wrinkle is that the storage format is XHTML with `ac:` macro tags — converting to MDX is the bulk of the engineering work.

    ✓Authenticate via OAuth 2.0 (3LO) or API token with HTTP Basic
    ✓Paginate `/wiki/api/v2/pages` per space (the v2 API is cleaner than v1)
    ✓For each page, GET the storage-format body (XHTML with `ac:` macros)
    ✓Extract attachments, comments, labels and version history per page
    ✓Extract space permissions + page restrictions separately
    ✓Run the XHTML → MDX converter (the hard part — start with the 10 most common macros, iterate)
    Ce que vous repartez avec

    A re-runnable extract pipeline + an MDX corpus + a macro-conversion report showing coverage.

  4. Build + weekly demos

    4-6 weeks

    A Next.js wiki that's faster than Confluence on every dimension that matters: search returns in 80ms, page loads in 200ms, edits commit to git, and restrictions are typed permissions.

    ✓Build the wiki: MDX rendering with the macro-replacement components
    ✓Full-text search via Typesense or Postgres tsvector — relevance ordering, instant suggestions
    ✓Page editor with live MDX preview (authors edit Markdown, designers own CSS)
    ✓Permission model: 4-5 named roles + space-level + page-level restrictions (rows in a typed table)
    ✓Whiteboards / Databases replaced with first-class features or dropped (most teams don't need them)
    Ce que vous repartez avec

    A working wiki on staging with the full content corpus, used by your team for one week as the primary documentation source.

  5. Parallel run + URL preservation

    2 weeks

    Both Confluence and the new wiki live for two weeks. Search points at the new wiki; the old Confluence is editable for a final corrections window. URL redirects from the legacy `/wiki/spaces/{KEY}/pages/{ID}` get tested exhaustively.

    ✓Nightly delta extract: pages updated in Confluence sync into the new wiki
    ✓Set up 301 redirects from every legacy Confluence URL to the new path
    ✓Train authors on the new editor in two 45-minute sessions, recorded
    ✓Disable new-page creation in Confluence (existing edits still allowed)
    ✓Verify the redirect map preserves every external link from engineering docs, runbooks, customer help
    Ce que vous repartez avec

    A reconciliation report on page counts per space + a verified 301 redirect map covering 100% of indexed URLs.

  6. Cutover + Confluence read-only

    1 day + 90-day fallback

    DNS for the wiki subdomain flips to the new product, Confluence goes fully read-only, Marketplace apps get cancelled, the Atlassian Cloud bill drops by the Confluence portion.

    ✓Cut SSO + DNS to the new wiki
    ✓Lock Confluence to read-only (revoke edit permissions space-wide)
    ✓Cancel Marketplace apps (Drawio, Scroll, Refined, etc.) in writing
    ✓Hold a 90-day Confluence read-only window for compliance / regret
    ✓Cancel Confluence Cloud subscription auto-renewal
    Ce que vous repartez avec

    Cutover Runbook + cancelled Marketplace subscriptions + a reduced Atlassian bill the same month.

Les API Confluence qu'on tape vraiment

Les endpoints concrets qu'on utilise pour extraire vos données pendant la phase de parallel run. Les scripts d'extraction restent — ils resservent à chaque renouvellement.

List pages (REST API v2)
GET /wiki/api/v2/pages?limit=250
Paginate every page — v2 is cleaner than v1 and returns more per call
Get page body in storage format
GET /wiki/api/v2/pages/{id}?body-format=storage
Pull the XHTML body with `ac:` macros — the input to the MDX converter
Get page versions
GET /wiki/api/v2/pages/{id}/versions
Preserve version history per page
List spaces
GET /wiki/api/v2/spaces
Enumerate every space + space key (URL component)
Get attachments per page
GET /wiki/api/v2/pages/{id}/attachments
Pull file metadata + download URLs for S3 import
Get comments per page
GET /wiki/api/v2/pages/{id}/footer-comments
Preserve in-line and footer comments (page review history)
Get labels
GET /wiki/api/v2/pages/{id}/labels
Migrate page labels (used for filtering + saved searches)
Get space permissions
GET /wiki/rest/api/space/{spaceKey}/permission
Extract who-can-do-what at the space level for the RBAC mapping

Les pièges propres à Confluence

Ce qu'on a appris à la dure (ou ce que la doc minimise). On les met sur la table dès le kick-off, comme ça personne n'est surpris en semaine 6.

Ce qui reste en place

Une migration marche quand elle est cadrée honnêtement. Voilà ce qu'on ne touche pas — par choix.

  • ·Whiteboards and Databases — replaced with native equivalents or dropped
  • ·Atlassian Marketplace macros — replaced with first-class MDX components or dropped
  • ·Atlassian Intelligence / AI add-ons — replaced with Claude/GPT against your own corpus
  • ·Confluence Mobile app — the new wiki is mobile-responsive; no native app
  • ·Jira — paired separately (see /jira/migration)
  • ·Trello — separate scoping conversation

Cadrer une migration Confluence.

Dites-nous votre nombre de licences, la date de fin de contrat et les intégrations que vous ne pouvez pas perdre. On revient sous un jour ouvré avec un cadrage forfaitaire et un calendrier calé sur votre renouvellement.

Cadrer une migration Confluence

Un jour ouvré. NDA + DPA sur demande.