Reply to comment

Pour ce qui est du découpage de la migration en une somme d'opérations minimes, j'utilise un "framework" que j'ai fait pour l'occasion assez proche de la batch_api de Drupal 6 (je suis ici sur du Drupal 5).
Le découpage se fait par une réécriture de requêtes SQL qui pose des LIMIT/OFFSET au bon endroit. Le module qui gère le "batch_api" (ou erzatz) se content lui de récupérer une valeur de fin lors lorsqu'une opération de migration se termine (qui se veut être l'endroit où il est rendu) pour relancer la même opération lors de la requête suivante en redonnant cet ID à la même méthode, jusqu'à avoir un retour indiquant qu'il n'y a plus de données à traiter, processus simple et utilisé un peu partout (on voit ça dans des cron parfois).

Après, en interne, les opérations de migration sont plutôt basiques, il s'agit d'une simple migration comme on aurait pu faire avec des scripts SQL; mais avec des scripts PHP qui utilise l'API Drupal.

Je vais pas m'étaler plus, car lorsque j'en aurais fini, je releaserais tout ce code, et essayerais de rédiger de la documentation.

Il faut garder en tête que ce découpage est de loin la partie la plus aisée de la migration de SPIP. Lorsqu'on arrive à essayer d'interprêter correctement la syntaxe SPIP en utilisant les fonctions d'un SPIP bootstrapé dans le Drupal, ça devient plus tordu, car SPIP pose une grosse partie de sa configuration dans des variables globales, ça devient alors dur de savoir exactement ce qu'il faut charger pour ne pas non plus bootstrapper le SPIP complet.
Au final, ça à abouti à l'écriture de requêtes de pre/post traitement des contenus migrés afin de corriger des erreurs d'interprêtation, et finaliser l'import des données.

Bon, j'ai rédigé ça à 1h du mat, donc ça doit paraître un peu flou :) Mais c'est une vraie aventure cette histoire!