Joomla → WordPress : chronique d’une migration propre (et sans perdre une seule URL)

Il y a des projets où tu sais exactement comment ça va se passer.

Et il y a les migrations.

Les migrations, c’est ce moment où tu prends un site “qui marche” (comprendre : personne n’y touche, donc personne ne le casse) et où tu annonces calmement :

“Bon. On va le refaire ailleurs. Et ensuite on va appuyer sur un bouton, et tout le monde devra faire comme si de rien n’était.”

Spoiler : ce n’est jamais exactement comme si de rien n’était.
Mais ça peut être propre, maîtrisé, réversible… bref : fait comme un pro de l’intégration logicielle.

Et c’est précisément l’histoire du jour : comment j’ai migré un site web associatif de Joomla vers WordPress, avec une contrainte importante :

côté “users” : lecture seule (on consulte, on lit, on télécharge, point)
côté admin : on veut quelque chose de plus simple à maintenir, plus standard, plus “intégrable”
et côté réalité : pas de budget démesuré, pas de serveur dédié, et pas le droit de tout casser un samedi soir

Je vous raconte.

1) Le décor : un site associatif, une vieille stack, et le fameux “ça marche”

Le site tournait depuis un moment sous Joomla.

Et il faisait son job :

pages d’infos
actualités
documents
quelques rubriques
une structure connue des habitués

Bref : pas un produit SaaS à 200 microservices. Un site utile, vivant, “patrimoine” même.

Mais voilà ce que j’ai appris (à mes dépens) avec le temps :

Un site web n’est pas “en production” parce qu’il fonctionne aujourd’hui.
Il est “en production” parce qu’il continuera à fonctionner demain.

Et “demain”, ça veut dire :

mises à jour de sécurité
versions PHP qui montent (et qui cassent les vieilles extensions)
plugins/modules abandonnés
hébergeur qui évolue
admins bénévoles qui changent
documentation qui se perd

Donc on avait deux options :

bricoler encore un peu Joomla et “espérer”
migrer vers un environnement plus facile à maintenir, plus courant, plus outillé

On a choisi la voie 2.

Et comme je suis (un peu) obsessionnel sur la rigueur : je n’ai pas fait une “refonte”.
J’ai fait une migration.

Nuance capitale.

2) Ma méthode d’intégrateur : isoler, reproduire, transformer, valider, basculer, éteindre

Avant de parler technique, parlons posture.

Quand tu fais de l’intégration logicielle, tu apprends à aimer :

les environnements séparés
les étapes réversibles
les bascules propres
la traçabilité
les tests “bêtes et méchants”
les plans de retour arrière

Donc j’ai posé le plan sur la table, en langage simple :

Créer un nouvel environnement, à côté de l’ancien (pas à la place).
Installer un WordPress vide, propre, dans un répertoire dédié et une base dédiée.
Migrer la donnée (et seulement la donnée utile), via export/import + script SQL.
Tester comme si j’étais mon pire utilisateur.
Basculer les redirections pour que l’URL publique pointe sur la nouvelle version.
Éteindre l’ancienne instance proprement, en gardant un plan d’archivage.

Ça ressemble à un pipeline de déploiement ?
Normal. C’est le même état d’esprit.

3) Étape 1 — Créer un répertoire pour le nouvel environnement (et respirer)

Premier réflexe de survie : ne pas toucher à l’existant.

Je sais que c’est tentant :

“On va mettre WordPress à la racine et on remplacera Joomla.”
“On fera ça vite.”
“C’est juste un site associatif.”

Oui. Et c’est exactement comme ça qu’on se retrouve à 23h48 avec :

un site en erreur 500,
des bénévoles qui refreshent frénétiquement,
et un cerveau qui passe en mode “pourquoi j’ai accepté”.

Donc j’ai créé un répertoire dédié (une sorte de staging sur le même hébergement) :

l’ancien site restait en place
le nouveau vivait à côté
je pouvais travailler, importer, casser, recommencer
sans impacter les visiteurs

C’est la base : isoler pour sécuriser.

Et accessoirement, ça donne un luxe rare : le droit d’être imparfait pendant la construction.

4) Étape 2 — Installer un WordPress vide + une base vide (le plaisir du “propre”)

Une fois le répertoire prêt : installation de WordPress.

Mais attention, pas “installer WordPress” façon clic-clic et on verra après.
Plutôt “installer WordPress comme une future prod”.

Donc :

WordPress vide (aucun contenu bidon à garder)
base de données vide dédiée
configuration claire
et surtout : pas de mélange avec l’existant

Et là, coup de chance (ou plutôt : bon choix d’offre) : notre hébergeur proposait plusieurs bases dans le pack.

Ce détail change tout.

Parce que séparer les bases, c’est :

éviter les collisions
faciliter les exports
rendre le rollback possible
garder l’ancien monde intact

Dans ma tête, c’était simple :

Joomla a sa base, WordPress a la sienne.
On ne mélange pas. On migre.

Et cette séparation, c’est le genre de truc qui ne se “voit” pas…
… mais qui te sauve quand ça chauffe.

5) Étape 3 — La migration de la base : export/import + script SQL (là où tout se joue)

C’est ici que la migration devient intéressante.

Parce qu’entre Joomla et WordPress, tu n’as pas juste “des articles” :

tu as des structures différentes
des champs différents
des formats différents
des relations différentes

Donc la stratégie que j’ai appliquée est très “intégration” :

a) Export : récupérer la source de vérité

D’abord, j’ai exporté la base Joomla.

Pas pour “la mettre telle quelle” dans WordPress.
Juste pour extraire la donnée.

C’est un point que je martèle souvent :

Une base exportée, ce n’est pas une base migrée.
C’est une matière première.

b) Transformation : le script SQL comme traducteur

Ensuite, j’ai écrit un script SQL de transformation.

Un vrai traducteur.

L’objectif :

prendre les tables Joomla (contenus, catégories, parfois médias, etc.)
produire des inserts compatibles WordPress (posts, metadata, taxonomies…)
nettoyer au passage ce qui devait l’être (HTML, encodages, liens internes, statuts)

Ce moment-là, c’est un mélange de :

précision
pragmatisme
et petites sueurs froides quand tu réalises qu’un détail peut dupliquer 600 lignes

Mais c’est aussi le moment le plus satisfaisant, parce que tu reprends le contrôle :

tu sais ce que tu importes
tu sais comment c’est mappé
tu sais ce qui est exclu (et pourquoi)

c) Import : injecter dans une base WordPress propre

Une fois le script prêt :

import dans la base WordPress vide
vérification du volume (nombre de pages, d’articles, de catégories)
contrôle de cohérence (dates, titres, permaliens, statuts)

Et là, je me suis fait le premier petit plaisir :

ouvrir le WordPress, voir apparaître les contenus… sans avoir touché au Joomla.

C’est bête, mais ça fait du bien.

Parce que ça valide un principe : l’ancien monde peut rester vivant jusqu’au dernier moment.

6) Étape 4 — Les tests (ou : comment devenir ton utilisateur le plus pénible)

À ce stade, tu as un WordPress qui ressemble à quelque chose.

C’est précisément le moment où ton cerveau veut te dire :

“Ça a l’air bon. On bascule ?”

Non.

C’est le moment où tu testes. Vraiment.

Mes tests “terrain”, version association

Je me suis mis dans la peau du visiteur :

Est-ce que j’arrive sur la bonne page d’accueil ?
Est-ce que je retrouve les rubriques “naturelles” ?
Est-ce que les articles sont lisibles (mise en page, retours à la ligne, listes) ?
Est-ce que les images apparaissent ?
Est-ce que les documents se téléchargent ?
Est-ce que la recherche (si elle existe) ne renvoie pas n’importe quoi ?
Est-ce que les liens internes pointent au bon endroit ?

Puis je me suis mis dans la peau de l’admin bénévole :

Est-ce que c’est simple ?
Est-ce que je comprends où modifier ?
Est-ce que je peux publier sans peur de casser le menu ?
Est-ce que je peux gérer sans être “dev” ?

Et enfin, test essentiel vu la contrainte :

Lecture seule côté users : verrouiller ce qui doit l’être

Lecture seule, ça veut dire :

pas de compte “public” inutile
pas d’inscription ouverte
pas d’espace d’édition accessible
commentaires désactivés si ce n’est pas un besoin
surface d’attaque réduite

En gros : un site de consultation, pas un réseau social.

C’est fou comme cette contrainte simplifie aussi l’exploitation :

moins d’interactions
moins de support
moins de risques

Et plus de sérénité.

7) Étape 5 — Les redirections : le moment où l’URL devient sacrée

S’il y a un endroit où je deviens psychorigide, c’est ici.

Parce que les URL, ce n’est pas “du technique”.

C’est :

des habitudes
des liens partagés
des bookmarks
du référencement
des QR codes imprimés sur des flyers (oui, ça arrive)
et parfois des emails vieux de 6 ans qui renvoient encore vers la bonne page

Donc l’objectif était clair :

Quand on bascule sur WordPress, les gens ne doivent pas avoir à réapprendre le site.

Ce qui implique deux sujets :

a) Pointer vers la nouvelle version

On a modifié les règles de redirection (souvent via configuration serveur / .htaccess selon l’hébergement) pour que :

l’URL publique envoie vers le WordPress
sans exposer le répertoire de staging
et en gardant une structure propre

b) Mapper les anciennes routes Joomla vers les nouvelles routes WordPress

C’est le vrai travail.

Parce que Joomla et WordPress n’ont pas forcément :

les mêmes slugs
la même hiérarchie
les mêmes paramètres d’URL
les mêmes patterns

Donc j’ai traité ça comme un chantier à part :

identifier les URL “les plus importantes”
définir des règles génériques quand c’est possible
ajouter des exceptions quand c’est nécessaire
tester les liens entrants

C’est un peu ingrat, mais c’est ce qui fait la différence entre :

une migration “techniquement réussie”
et une migration “réellement transparente”

Et si vous doutez de l’importance : regardez vos stats 404 après une bascule mal préparée.
C’est un cimetière.

8) Étape 6 — La bascule (le grand switch, version sans drama)

La bascule, c’est le moment où tu changes l’aiguillage, et où le train passe dessus en direct.

Donc je l’ai faite avec trois règles simples :

✅ Règle 1 : avoir un plan de retour arrière

Même si tu ne l’utilises pas, tu dois savoir :

comment remettre l’ancien en ligne
en combien de temps
et avec quelles manipulations minimales

✅ Règle 2 : basculer quand c’est calme

Un site associatif a souvent :

des pics (assemblée, inscriptions, événements)
et des creux (soirées, certains jours)

Bascule = période calme.
C’est juste du bon sens.

✅ Règle 3 : vérifier immédiatement les parcours essentiels

Après bascule, j’ai refait les tests “visiteur” :

home
menu principal
pages clés
téléchargement
et surtout : quelques anciennes URL (celles qu’on sait partagées)

C’est là que tu vois si ta migration est “propre”.

Et si tout va bien, tu ressens ce petit plaisir rare :

“Ok. Les gens ne verront rien. Et c’est exactement le but.”

9) Étape 7 — Extinction de l’ancienne instance (ou : savoir finir un projet)

Beaucoup de migrations échouent à la toute fin.

Parce qu’on bascule, tout marche, et on se dit :

“Bon… on laissera l’ancien au cas où.”

Et six mois plus tard :

l’ancien Joomla est encore accessible
pas mis à jour
oublié
et devient un risque

Donc j’ai fait l’inverse : j’ai éteint proprement.

Ce que ça veut dire, dans un monde raisonnable :

sauvegarde archive (fichiers + base)
accès coupé côté public
suppression / désactivation des points d’entrée inutiles
nettoyage des cron/jobs éventuels
et documentation minimale : “où est l’archive, comment restaurer si besoin”

L’objectif n’est pas d’effacer le passé.

C’est de ne pas garder une vieille prod en zombie.

Ce que cette migration m’a rappelé (et que je garde comme règle)

1) Une migration, ce n’est pas un copier-coller

C’est une traduction : données, structure, usages.

2) L’environnement parallèle est ton meilleur ami

Le répertoire séparé + base séparée, c’est la différence entre maîtrise et panique.

3) Les redirections, c’est la politesse du web

On ne dit pas “tant pis”.
On accompagne.

4) Éteindre fait partie du travail

Sinon tu laisses un risque en cadeau.

Conclusion : la meilleure migration est celle que personne ne remarque

Au final, la réussite se mesure avec un indicateur très simple :

pas de coup de fil
pas de “le site marche plus”
pas de “je ne retrouve plus”
pas de 404 partout
et côté admin : un outil plus clair, plus maintenable, plus “standard”

Et ça, c’est exactement ce que j’aime dans l’approche “intégration logicielle” :

On ne cherche pas l’effet.
On cherche la continuité.

Un site associatif n’a pas besoin d’un show.
Il a besoin d’être fiable, lisible, durable.

Et si au passage on simplifie la vie des bénévoles… alors c’est même plus qu’une migration : c’est un service rendu.

(Bonus) La phrase toute prête à ressortir quand on te dit “on pourrait migrer direct en prod, non ?”

“On migre d’abord à côté. Ensuite on bascule. Comme ça, le seul stress qu’on garde, c’est celui qu’on a choisi.”