Le prix par utilisateur double, l'éditeur change ses conditions, ou un audit demande où sont hébergées les données. On regarde alors comment partir, et c'est plus compliqué que prévu.

Sortir d'un SaaS n'est pas un projet technique en premier lieu. C'est un projet de cartographie. La méthode suit, puis des cas concrets.

La méthode en 5 étapes

1. Inventorier ce qui vit vraiment dans l'outil

Données (tickets, contacts, documents), mais aussi automatisations, formulaires, droits, intégrations, rapports que quelqu'un consulte chaque lundi. Ce sont souvent ces éléments cachés qui bloquent la migration, plus que les données elles-mêmes.

2. Tester l'export avant de décider quoi que ce soit

Lancez un export complet, aujourd'hui, et regardez ce qui manque : historique, commentaires, pièces jointes, liens entre objets, auteurs et dates d'origine. Un export CSV « complet » perd presque toujours les relations entre les objets.

3. Choisir la destination selon vos contraintes

Autre SaaS, outil open source auto-hébergé, ERP, ou développement sur mesure. L'essentiel est que les comptes et les clés soient à votre nom.

4. Migrer en parallèle, pas en une nuit

Import de test, comparaison, correction des écarts, puis bascule un week-end ou à une date calme. L'ancien outil reste accessible en lecture seule quelques semaines.

5. Documenter la sortie

Ce qui a été migré, ce qui a été abandonné volontairement, où sont les sauvegardes.

Cas 1 : sortir de Jira

Situation type : une équipe de 30 à 80 personnes paie des licences pour des usages réduits à du suivi de tickets basique, avec quelques workflows personnalisés.

Ce qu'on peut exporter :

• Les tickets en CSV ou JSON, avec leurs champs principaux
• Une sauvegarde complète de l'instance cloud via l'outil de sauvegarde de l'éditeur
• Les pièces jointes, via la sauvegarde ou par script via l'API

Ce qui pose problème :

• Les workflows et leurs règles ne sont pas portables : il faut les redécrire
• Les liens entre tickets (parent, dépendance, doublon) se perdent facilement en CSV
• Les commentaires et l'historique des changements demandent de passer par l'API
• Les automatisations et les tableaux de bord sont à reconstruire

Où migrer : selon le besoin, un outil open source comme Redmine, OpenProject ou Plane, ou le module projet/helpdesk d'un ERP si les tickets sont liés à la facturation. Pour une équipe technique, un suivi dans le dépôt de code (GitLab, Gitea) peut suffire.

Piège fréquent : vouloir tout reproduire à l'identique. Souvent, un tiers des champs et des workflows ne servait plus. La migration est l'occasion de simplifier.

Cas 2 : sortir d'un CRM SaaS (HubSpot, Pipedrive, etc.)

Situation type : le coût grimpe avec le nombre de contacts et de fonctionnalités, et les données clients vivent chez un tiers.

Ce qu'on peut exporter : contacts, entreprises, opportunités et notes, généralement en CSV.

Ce qui pose problème :

• Les associations entre contacts, entreprises et opportunités demandent un mapping soigné
• L'historique d'emails et d'activités est souvent partiel dans les exports standards
• Les séquences de relance et les automatisations marketing sont à refaire
• Les identifiants d'origine doivent être conservés pour rapprocher les données après coup

Où migrer : le CRM d'Odoo si l'entreprise veut relier prospection, devis, facturation et stock au même endroit. C'est un cas fréquent quand le CRM seul coûte déjà presque autant qu'un ERP complet.

Piège fréquent : oublier les formulaires du site et les intégrations qui alimentaient l'ancien CRM. Le jour de la bascule, les nouveaux contacts partent dans le vide.

Cas 3 : sortir de Notion, Airtable ou d'un outil « no-code »

Situation type : ce qui a commencé comme une base de suivi est devenu un outil critique, avec des dizaines de tables, des formules et des automatisations.

Ce qu'on peut exporter : Notion en Markdown et CSV, Airtable en CSV par table.

Ce qui pose problème :

• Les relations entre tables et les champs calculés ne passent pas dans un CSV
• Les vues, filtres et permissions disparaissent
• Les automatisations sont propres à la plateforme

Où migrer : une petite application sur mesure ou un module ERP, avec une vraie base de données derrière. C'est souvent le cas où le sur-mesure est le plus rentable : l'outil est déjà un logiciel métier qui ne dit pas son nom.

Piège fréquent : sous-estimer la logique cachée dans les formules. Il faut la lire, la comprendre et la réécrire, pas seulement copier les données.

Cas 4 : récupérer des comptes détenus par un prestataire

Ce n'est pas un SaaS à quitter, mais un cas très proche : le site, le cloud ou l'outil a été mis en place par une agence ou un freelance, sous ses propres comptes. Le jour où la relation s'arrête, vous n'avez plus la main.

À faire :

• Identifier tous les comptes concernés (hébergeur, nom de domaine, cloud, messagerie, outils tiers)
• Demander le transfert de propriété, ou recréer les comptes à votre nom et migrer
• Changer tous les mots de passe, clés d'API et secrets une fois la reprise faite
• Vérifier que la facturation est bien à votre nom

Règle simple pour l'avenir : les comptes sont créés au nom du client dès le départ. Le prestataire reçoit des accès limités et révocables.

Pour cartographier tous vos comptes (domaine, cloud, paiements, code) en 30 minutes, voir l'audit de propriété des comptes.

Combien de temps ça prend ?

Cela dépend surtout de la quantité de logique métier, pas du volume de données. À titre indicatif :

• Un outil simple avec peu d'automatisations : quelques jours à deux semaines
• Un outil bien installé avec workflows et intégrations : un à deux mois
• Un système critique et très personnalisé : à découper en phases

Checklist avant de signer le préavis

• J'ai fait un export complet de test et je l'ai ouvert
• Je sais ce qui n'est pas exportable et ce que j'en fais
• J'ai listé les intégrations et automatisations
• La destination est sous mes comptes et mes clés
• L'ancien outil reste en lecture seule pendant la transition
• Une personne est responsable de valider la migration côté métier

À retenir

La sortie d'un SaaS se prépare avant d'en avoir besoin. Même si vous ne comptez pas partir, faire un export de test une fois par an et vérifier que vous êtes propriétaire de vos comptes évite beaucoup de mauvaises surprises.

Per-seat pricing doubles, the vendor changes terms, or an audit asks where the data lives. Teams then look at leaving, and it is harder than expected.

Leaving a SaaS is not a technical project first. It is a mapping project. The method follows, then concrete cases.

The method in 5 steps

1. Inventory what actually lives in the tool

Data (tickets, contacts, documents), but also automations, forms, permissions, integrations, and the Monday reports someone still opens. Hidden pieces block migrations more often than raw rows.

2. Test the export before deciding anything

Run a full export today and inspect gaps: history, comments, attachments, object links, authors, and original dates. A “complete” CSV almost always drops relationships.

3. Choose the destination from your constraints

Another SaaS, self-hosted open source, an ERP, or custom software. The non-negotiable: accounts and keys are in your name.

4. Migrate in parallel, not overnight

Test import, compare, fix gaps, then cut over on a quiet weekend. Keep the old tool read-only for a few weeks.

5. Document the exit

What moved, what you deliberately dropped, and where backups live.

Case 1: leaving Jira

Typical situation: a 30 to 80 person team pays for licenses while usage shrank to basic ticketing plus a few custom workflows.

What you can export:

• Tickets as CSV or JSON with main fields
• A full cloud backup via the vendor backup tool
• Attachments via backup or API scripts

What hurts:

• Workflows are not portable: you rewrite them
• Ticket links (parent, blocks, duplicate) drop easily in CSV
• Comments and change history need the API for a clean keep
• Automations and dashboards must be rebuilt

Where to go: open source such as Redmine, OpenProject, or Plane. An ERP project/helpdesk module if tickets tie to billing. Or issue tracking in the code host (GitLab, Gitea) for engineering teams.

Common trap: cloning everything 1:1. Often a third of fields and workflows were already unused. Migration is a chance to simplify.

Case 2: leaving a SaaS CRM (HubSpot, Pipedrive, etc.)

Typical situation: cost scales with contacts and features, and customer data sits with a third party.

What you can export: contacts, companies, deals, and notes, usually CSV.

What hurts:

• Associations need careful mapping
• Email and activity history is often partial in standard exports
• Sequences and marketing automations must be rebuilt
• Original IDs must be kept or later joins fail

Where to go: Odoo CRM when sales, quotes, invoicing, and stock should share one system. Common when CRM alone already costs nearly a full ERP.

Common trap: forgetting website forms and integrations that fed the old CRM. On cutover day, new leads go nowhere.

Case 3: leaving Notion, Airtable, or “no-code”

Typical situation: a tracking base became critical: dozens of tables, formulas, and automations.

What you can export: Notion Markdown/CSV. Airtable CSV per table.

What hurts:

• Relations and computed fields do not survive CSV
• Views, filters, and permissions disappear
• Automations are platform-specific

Where to go: a small custom app or ERP module on a real database. Custom work is often cheapest here: the tool is already business software that never said its name.

Common trap: underestimating formula logic. Read it, understand it, rewrite it. Do not only copy cells.

Case 4: reclaiming accounts held by a vendor

Not a SaaS exit, but close: the site, cloud, or tool was set up under an agency or freelancer account. When the relationship ends, you lose the keys.

Do this:

• List every account (hosting, domain, cloud, mail, third-party tools)
• Request ownership transfer, or recreate under your name and migrate
• Rotate passwords, API keys, and secrets after takeover
• Confirm billing is in your name

Rule going forward: accounts are created for the customer from day one. The vendor gets limited, revocable access.

To map every account (domain, cloud, payments, code) in 30 minutes, see the account ownership audit.

How long does it take?

Business logic matters more than data volume. Rough ranges:

• Simple tool, few automations: days to two weeks
• Established tool with workflows and integrations: one to two months
• Critical, heavily customized system: phase it

Checklist before you give notice

• I ran a full test export and opened it
• I know what is not exportable and what I will do about it
• I listed integrations and automations
• The destination is under my accounts and keys
• The old tool stays read-only during transition
• Someone on the business side owns migration sign-off

In short

Prepare a SaaS exit before you need one. Even if you are not leaving, a yearly test export and proof you own your accounts prevent expensive surprises.