☠Saaspocalypse
← Jira · Issue Tracking
Plan de migration

Migrer hors de Jira — phase par phase.

Les migrations Jira tournent autour de trois choses : extraire via l'API REST Cloud (qui pagine différemment pour les issues que pour la plupart des ressources), rebâtir fidèlement la jungle workflows + schemes en state machines, et traduire les saved JQL et la facture Marketplace en fonctions natives. Les clés d'issue (PROJ-1234) sont préservées partout pour que les liens externes, les messages de commit et les références dans les PR continuent de résoudre.

12-16 weeks de bout en boutForfaitParallel run avant basculeLe code est à vous

Les phases, taillées pour Jira

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

  1. Workflow + scheme audit

    2-3 weeks

    Every Jira instance has accumulated a forest of workflows, screen schemes, permission schemes, notification schemes and field configurations. We inventory ruthlessly — most teams collapse 30+ workflows into 5-6 once duplicates and unused ones are removed.

    ✓Export every workflow definition + transition rule via the REST API
    ✓List every screen scheme, permission scheme, notification scheme, field configuration scheme
    ✓Inventory active Marketplace apps and what each one actually does (most teams have 3-6 they pay for; 1-2 are doing real work)
    ✓Catalogue saved JQL filters — these become saved views in the new product
    ✓Identify the integrations (GitHub, GitLab, Slack, OpsGenie, Statuspage) that need to keep working through migration
    Ce que vous repartez avec

    A Workflow + Scheme Inventory + a Marketplace-app shortlist (rebuild / replace / drop).

  2. Schema + issue-key strategy

    1 week

    Issues become a properly-typed table with the issue key (PROJ-1234) preserved everywhere. Custom fields stop being string blobs. Workflows become state machines defined in TypeScript and reviewed in PRs.

    ✓Design `issues` table with `jira_key` column (indexed) + native columns for the top 20 fields
    ✓Custom fields get sensible types (Date, Money, Decimal, Enum) instead of cf[10042] strings
    ✓Workflow definitions as TypeScript state machines (transitions, validators, post-functions)
    ✓Permission scheme → 4-6 named roles in code
    ✓Plan a JQL-equivalent query layer in Postgres (most JQL clauses are 1:1 to SQL with the right indexes)
    Ce que vous repartez avec

    Schema migrations + workflow state machines in TypeScript + the issue-key preservation strategy.

  3. Extract via REST API

    1-2 weeks

    Jira Cloud's REST API paginates issues via `?startAt` + `maxResults` (default 50, max 100). The search endpoint is where you'll spend most of the extract budget — chunk by project + by date range to stay under the rate limits.

    ✓Authenticate via OAuth 2.0 (3LO) or API token with HTTP Basic
    ✓Iterate `/rest/api/3/search` per project with JQL `project = X ORDER BY created`
    ✓Pull each issue's comments, worklogs, changelog, attachments separately (the search response is shallow)
    ✓Extract sprints + versions + components per project
    ✓Pull users, groups, project roles and permissions for the RBAC mapping
    ✓Save the raw JSON — it's useful evidence during reconciliation
    Ce que vous repartez avec

    A re-runnable extract pipeline + a reconciliation report comparing issue counts per project.

  4. Build + weekly demos

    5-8 weeks

    Issues, boards, JQL-equivalent search, automation rules and dashboards rendered server-side. Time-tracking and roadmaps stop being paid Marketplace apps and become first-class columns.

    ✓Issues list + Kanban + sprint views — virtualised grid for the 50k-issue case
    ✓JQL-equivalent search via Postgres full-text + structured filters; saved filters become URL state
    ✓Automation rules as TypeScript functions with a real audit trail (the Jira automation rule cap stops being a thing)
    ✓Time-tracking as a column on the issue table (no Tempo / Clockwork app needed)
    ✓Roadmap / Gantt as a derived view over due dates + dependencies (no Advanced Roadmaps subscription)
    ✓Dashboards rendered server-side from real SQL
    Ce que vous repartez avec

    A working tracker on staging that your engineering team uses for one full sprint.

  5. Parallel run + reconciliation

    2-3 weeks

    Both systems live for two-three weeks. Issues created in Jira sync nightly into the new product; webhooks from GitHub / GitLab / Slack fire into both during the ramp.

    ✓Daily incremental sync from Jira via the `updated >= -1d` JQL filter
    ✓Bridge integrations (GitHub commit messages, Slack notifications) to both systems
    ✓Daily reconciliation: open vs done counts per project, comment-count drift, attachment integrity
    ✓Train engineers in two 45-minute sessions, recorded for the rest
    ✓Pin the issue-key strategy in commit messages — `PROJ-1234` still resolves on both sides
    Ce que vous repartez avec

    A reconciliation dashboard + a green sprint demo from the new product.

  6. Cutover + Jira read-only

    1 day + 90-day fallback

    Jira goes read-only on a Tuesday morning, GitHub / Slack integrations point only at the new product, Atlassian Marketplace apps get cancelled the same week.

    ✓Cut SSO + bookmark redirects to the new tracker
    ✓Lock Jira to read-only (revoke project-admin and edit permissions)
    ✓Cancel Atlassian Marketplace apps in writing — the bill drops the same month
    ✓Hold a 90-day Jira read-only window for compliance / regret / audit
    ✓Cancel the Atlassian Cloud subscription auto-renewal
    Ce que vous repartez avec

    Cutover Runbook + cancelled Marketplace subscriptions + a quiet inbox where the renewal email used to land.

Les API Jira 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.

Search issues (REST API v3)
GET /rest/api/3/search?jql={jql}&startAt={n}&maxResults=100
The primary extract endpoint — paginate issues per project ordered by created date
Get issue with expansions
GET /rest/api/3/issue/{issueKeyOrId}?expand=changelog,renderedFields
Pull the full issue including changelog (history of every field change) and rendered body
Get issue comments
GET /rest/api/3/issue/{issueKeyOrId}/comment
Paginate every comment per issue (search response is shallow)
Get workflows
GET /rest/api/3/workflow/search
Extract every workflow definition + transition rules for the state-machine rebuild
Get projects
GET /rest/api/3/project/search
List projects, project keys, project leads, default assignees
Get users + groups
GET /rest/api/3/users/search
Pull users + group memberships for the RBAC mapping
Get sprints (Agile API)
GET /rest/agile/1.0/board/{boardId}/sprint
Sprint history per board for the velocity + burn-down rebuild
OAuth 2.0 (3LO)
POST https://auth.atlassian.com/oauth/token
Three-legged OAuth for the extract tooling (or HTTP Basic with an API token for unattended)

Les pièges propres à Jira

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.

  • ·Atlassian Marketplace apps — replaced by first-class features or dropped
  • ·Jira Service Management — separate scoping conversation (it's a different product, not in Jira Software scope)
  • ·Bitbucket repos — keep them where they are or migrate to GitHub separately
  • ·Confluence — paired separately (it's its own SaaS to kill, see /confluence/migration)
  • ·Atlassian Intelligence / AI add-ons — replaced with Claude/GPT against your own data
  • ·Advanced Roadmaps as a separate product — folded into the new tracker as a view over due dates + dependencies

Cadrer une migration Jira.

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 Jira

Un jour ouvré. NDA + DPA sur demande.