☠Saaspocalypse
← Salesforce · CRM
Plan de migration

Migrer hors de Salesforce — phase par phase.

Les migrations Salesforce se jouent sur deux détails techniques : Bulk API 2.0 pour l'extraction, et une stratégie volontaire pour les identifiants à 18 caractères sur lesquels pointent toutes vos intégrations historiques. On les conserve en colonne sur le nouveau schéma — rapports, webhooks et recherches sauvegardées continuent de résoudre.

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

Les phases, taillées pour Salesforce

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

  1. Audit & cadrage fonctionnel

    1 à 2 semaines

    On cartographie les 10 à 20 % de Salesforce que votre équipe utilise vraiment — chaque objet, chaque workflow actif, chaque rapport que votre CRO ouvre. Les 80 % que personne ne touche deviennent l'argument économies.

    ✓On shadow sales, ops et leadership sur des tâches réelles
    ✓On tire un rapport d'usage 90 jours via Salesforce Optimizer (logins + fonctions touchées)
    ✓On inventorie objets custom, champs, règles de validation, triggers Apex, Flows
    ✓On identifie les intégrations et webhooks entrants à préserver
    ✓On mappe le qui-voit-quoi (Sharing Rules + Profiles + Permission Sets) sur un modèle RBAC réaliste
    Ce que vous repartez avec

    Un audit de périmètre nommant chaque objet qui reste, chaque workflow qui saute, et un mapping Sharing Rules → rôles.

  2. Schéma & stratégie d'IDs

    1 semaine

    On modélise vos données sur Postgres en préservant les IDs Salesforce à 18 caractères en colonne sur chaque enregistrement, pour que les liens historiques et les systèmes externes continuent de résoudre. Les champs custom prennent des types corrects au lieu de strings partout.

    ✓Conception du schéma Postgres (tables nommées, vrais types, vraies clés étrangères)
    ✓Ajout d'une colonne `salesforce_id` sur chaque table migrée (indexée)
    ✓Documentation du mapping des picklists (API names vs labels via Schema.PicklistEntry)
    ✓RBAC : 3 à 4 rôles nommés en code, en remplacement de la stack Sharing Rules + Profiles + Permission Sets
    ✓ADR + DPA signés
    Ce que vous repartez avec

    Un ADR signé, des migrations de schéma versionnées dans git, et une stratégie de préservation d'IDs documentée.

  3. Extraction via Bulk API 2.0

    1 à 2 semaines

    On tire chaque enregistrement qui compte via Bulk API 2.0 — chunké, asynchrone, reprenable. Les enregistrements soft-deleted dans la fenêtre Recycle Bin de 15 jours passent par une passe séparée.

    ✓Auth OAuth 2.0 (client-credentials ou JWT bearer pour le non-interactif)
    ✓Soumission de jobs Bulk API 2.0 par objet, polling jusqu'à complétion, téléchargement des CSV
    ✓Extraction des données Einstein Activity Capture séparément (elles vivent sur AWS, hors Salesforce core)
    ✓Backfill des relations objets custom via REST Composite
    ✓Extraction des métadonnées (custom fields, picklists, validation rules) via la Tooling API
    Ce que vous repartez avec

    Un script d'extraction rejouable + un rapport de réconciliation comparant les comptages aux dashboards Salesforce.

  4. Build avec démos hebdo

    5 à 8 semaines

    Du logiciel qui tourne chaque vendredi. Vos commerciaux se connectent au staging dès la semaine 2, l'utilisent sur des deals réels dès la semaine 4. À la bascule, ils auront plus utilisé le nouveau produit que Salesforce.

    ✓Construction des vues leads, opportunités et comptes — les 8 à 10 champs que votre équipe remplit vraiment, point
    ✓Pipeline en Kanban, transitions de stade en simples boutons (pas de labyrinthe de validation rules)
    ✓Journalisation d'activité intégrée aux vues (pas de bascule d'onglet, pas de recherche d'enregistrement)
    ✓Sync email via Gmail / Microsoft Graph (remplace Salesforce Inbox)
    ✓Dashboards server-rendered depuis du vrai SQL — pas de plafond 2 000 lignes, pas de cache périmé
    Ce que vous repartez avec

    Une application de qualité production sur votre propre infrastructure, avec votre organisation comme propriétaire GitHub.

  5. Parallel run + réconciliation

    2 à 3 semaines

    Les deux systèmes tournent. Votre équipe travaille sur le nouveau produit ; Salesforce reste en lecture seule comme filet. Des rapports de réconciliation nuit comparent les totaux et signalent la dérive.

    ✓Sync incrémentale quotidienne depuis Salesforce vers le nouveau système (watermark last-modified)
    ✓Réconciliation nuit : comptages, somme-de-£-par-stade, won-lost-par-rep
    ✓Formation des commerciaux en deux sessions de 60 minutes, enregistrées
    ✓Réorientation des webhooks entrants (Stripe, Calendly, etc.) un par un, avec un kill switch
    ✓Vérification que chaque intégration externe résout contre le `salesforce_id` préservé
    Ce que vous repartez avec

    Un dashboard de réconciliation à zéro drift sur sept jours consécutifs + une validation signée par la direction commerciale.

  6. Bascule + Salesforce en lecture seule

    1 journée + filet de 90 jours

    Le mardi matin, DNS et SSO basculent. On reste en war-room avec votre lead ops. Salesforce passe en lecture seule pour 90 jours comme filet de sécurité ; l'auto-renouvellement est annulé le jour même.

    ✓Smoke tests sur chaque workflow critique avant la bascule
    ✓Bascule du SSO vers la nouvelle app ; redirection des bookmarks via un proxy d'une ligne
    ✓Verrouillage de Salesforce en lecture seule (révocation des profils en écriture)
    ✓Annulation du renouvellement automatique Salesforce, par écrit
    ✓Fenêtre lecture seule de 90 jours pour conformité / litige / regret
    Ce que vous repartez avec

    Un runbook de bascule + un rapport Jour 1 + une boîte de réception calme là où atterrissait l'email de renouvellement.

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

OAuth 2.0 token
POST /services/oauth2/token
Authenticate the migration tooling (JWT bearer or client_credentials grant)
Bulk API 2.0 — create query job
POST /services/data/v62.0/jobs/query
Kick off async bulk extraction per object (Accounts, Opportunities, Contacts, custom objects)
Bulk API 2.0 — get results
GET /services/data/v62.0/jobs/query/{jobId}/results
Download the CSV chunks once the query job is complete
SOQL query
GET /services/data/v62.0/query/?q={SOQL}
Quick lookups, sample exports, reconciliation totals during parallel run
REST sObject CRUD
GET /services/data/v62.0/sobjects/{SObject}/{id}
Individual record fetches and live syncing during parallel run
Composite tree
POST /services/data/v62.0/composite/tree/{SObject}
Backfill parent/child object graphs (e.g. Opportunity → OpportunityLineItem) in one request
Tooling API metadata
GET /services/data/v62.0/tooling/sobjects/CustomField/{id}
Extract custom field definitions, picklist values, validation rules for the schema mapping
Connect REST API — Chatter feed
GET /services/data/v62.0/chatter/feeds/record/{recordId}/feed-elements
Pull internal Chatter activity if it's in scope (most teams skip this)

Les pièges propres à Salesforce

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.

  • ·Triggers et classes Apex — réécrits en TypeScript avec tests
  • ·Visualforce et Lightning Web Components — UI rebâtie en React
  • ·Salesforce Flow — l'automatisation devient des jobs durables (Inngest / BullMQ) avec retries et vrai audit trail
  • ·Managed packages AppExchange — soit remplacés par du code natif, soit abandonnés s'ils sont du shelfware
  • ·Rapports & dashboards dans Salesforce — rebâtis sur Metabase et le nouveau warehouse Postgres
  • ·Salesforce CPQ / Billing / Field Service — ces produits méritent leur propre cadrage

Cadrer une migration Salesforce.

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 Salesforce

Un jour ouvré. NDA + DPA sur demande.