Migrer de Kajabi vers GoHighLevel sans couper les accès

Ce qui se transfère, ce qui se reconstruit

Les contacts, tags et produits s’exportent. Les pages Kajabi, les automations visuelles et les certificats ne se collent pas. Il faut reconstruire les parcours dans GHL, pas espérer un import magique.

Les accès élèves sont le point sensible. On crée l’espace membres GHL, on mappe les offres, on teste un compte élève réel, puis seulement on bascule le domaine. L’ancien espace reste lisible le temps de la bascule.

Commence par une carte : une ligne par offre, avec le prix, le type de paiement, le nombre d’élèves actifs et le domaine qui porte l’espace. Les tags Kajabi sont souvent trop larges pour devenir des étapes de pipeline. On les traduit en champs : offre achetée, date d’accès, statut de paiement. Le guide espace membres dit ce que le portail GHL sait faire, et ce qu’il ne remplace pas.

Le domaine ne bouge qu’en dernier. Baisse le TTL DNS avant le jour J, prépare la redirection, et garde Kajabi ouvert en lecture. Les élèves qui ont un favori ou un mail ancien doivent encore trouver une porte. Prévenir la liste avant ce test, c’est leur envoyer vers une page qui n’ouvre pas le bon module.

Paiements et abonnements en cours

Les abonnements Stripe déjà en cours ne doivent pas être recréés à la main. On identifie ce qui est porté par Kajabi Payments et ce qui est déjà sur Stripe. Recréer un checkout sans couper l’ancien produit des doublons de facturation.

La règle ProMarket : aucun email de bascule aux élèves avant qu’un compte test ait ouvert un module, reçu un drip et pu se reconnecter.

Fais deux colonnes : paiements qui restent chez le prestataire actuel, et paiements que tu recrées. Un abonnement Stripe déjà vivant se relie, il ne se ressaisit pas. Un paiement Kajabi qui n’a pas d’équivalent Stripe se traite à part, avec une date de fin claire, sinon tu factures deux fois la même personne. Le checkout neuf n’est branché qu’une fois cette liste écrite.

Le compte test n’est pas un aperçu admin. C’est un élève fictif qui paie une offre de test, reçoit le mail d’accès, ouvre un module, voit le drip suivant, se déconnecte et se reconnecte. S’il échoue, on ne touche pas au domaine. Cette séquence est la même que dans la méthode, que le catalogue vienne de Kajabi ou d’un autre outil.

Ordre des 14 jours

Jours 1-2 : inventaire offres, tags, domaines, DNS email. Jours 3-6 : pipelines, champs, espace membres, import contacts. Jours 7-10 : workflows de relance et d’onboarding, SPF/DKIM/DMARC. Jours 11-14 : paiement, pages de vente, redirection, hypercare.

Le calendrier tient si le catalogue fait moins de dix offres. Au-delà, on phase par produit, pas par outil.

L’email se prépare pendant la reconstruction, pas le matin de la bascule. SPF, DKIM et DMARC se posent sur le domaine d’envoi, puis on n’écrit d’abord qu’aux acheteurs récents. Le détail est dans le guide délivrabilité. Importer toute la base Kajabi et annoncer la migration le soir même, c’est le plus sûr moyen de finir en spam.

Quatorze jours, c’est le cas simple : un espace, une liste, un checkout. Dix offres, des cohortes et des abonnements mêlés demandent une phase par produit. L’ancien outil reste la référence jusqu’à ce que le produit suivant soit testé. Le parcours complet, au-delà de Kajabi, est sur la page Migration vers GoHighLevel.

Questions fréquentes