Tweet
Bonjour,
Je suis heureux que vous ayez réussi à effectuer la migration, ce n'est pas evident de comprendre la source du problème.
J'indique ci-dessous ma propre expérience...
En général, je recommande de travailler en local avec différentes versions de PHP et de bases de données.
Personnellement, j'utilise Laragon dans une version personnalisée, bien que je prévoie de passer à Docker à l'avenir. Cette approche me permet de maintenir une configuration efficace et à jour.
Il m'arrive également de réaliser des migrations en ligne sur demande des clients, ce qui est rapide sur les serveurs LiteSpeed que j'administre et le client peut tester la nouvelle version.
Pour la méthodologie de restauration du serveur local vers le site en prod, comme j'ai déjà fait une sauvegarde récente de l'ancien site en prod, je supprime le site intégralement et remplace par une page d'attente html (indiquant que le site est en maintenance). Je modifie la version de php et je créé la nouvelle base au besoin (suivant les versions de mysql). Je vérifie que la base soit correctement créé et accessible depuis phpmyadmin et depuis le site via petit script PHP écrit vite fait que je supprime après avoir réussi le test.
Une fois les prérequis respectés et identiques au serveur local, je procède à la restauration via kickstart.php et je supprime la page HTML de maintenance. Je vérifie ensuite le bon fonctionnement du site en testant diverses fonctionnalités telles que la navigation, l'envoi de mails, etc. Je veille également à conserver le travail SEO précédent en mettant en place les redirections nécessaires. (soit dans le htaccess, soit dans le composant de redirection).
Après la migration, je supprime toutes les traces des fichiers de migration et je vérifie les paramètres de sauvegarde du nouveau site. Si nécessaire, je procède ensuite à une optimisation et à une sécurisation avancée, avec surveillance (monitoring) si demandé par le client.
Il est essentiel de disposer d'une copie fonctionnelle de l'ancien site en cas de problème avec l'hébergement qui ne respecte pas les prérequis. Travailler en local permet de rapidement détecter et corriger d'éventuelles erreurs dans les archives. En général, je réalise la restauration en dehors des heures ouvrées pour limiter les connexions et je vérifie la connexion à la base, bien que ce soit optionnel car kickstart.php le fait également.
Bien que la migration puisse parfois être complexe, il est important de ne pas remettre en cause le CMS. Cette expérience offre également l'occasion de revoir les choix d'hébergement et de corriger d'éventuelles erreurs avant de repartir sur plusieurs années avec une nouvelle version. Restons optimistes et voyons cela comme une opportunité d'évolution et d'amélioration continue.
Je suis heureux que vous ayez réussi à effectuer la migration, ce n'est pas evident de comprendre la source du problème.
J'indique ci-dessous ma propre expérience...
En général, je recommande de travailler en local avec différentes versions de PHP et de bases de données.
Personnellement, j'utilise Laragon dans une version personnalisée, bien que je prévoie de passer à Docker à l'avenir. Cette approche me permet de maintenir une configuration efficace et à jour.
Il m'arrive également de réaliser des migrations en ligne sur demande des clients, ce qui est rapide sur les serveurs LiteSpeed que j'administre et le client peut tester la nouvelle version.
Pour la méthodologie de restauration du serveur local vers le site en prod, comme j'ai déjà fait une sauvegarde récente de l'ancien site en prod, je supprime le site intégralement et remplace par une page d'attente html (indiquant que le site est en maintenance). Je modifie la version de php et je créé la nouvelle base au besoin (suivant les versions de mysql). Je vérifie que la base soit correctement créé et accessible depuis phpmyadmin et depuis le site via petit script PHP écrit vite fait que je supprime après avoir réussi le test.
Code PHP:
<?php
$servername = "localhost";
$username = "your_username";
$password = "your_password";
$dbname = "your_database_name";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
echo "Connected successfully";
?>
Une fois les prérequis respectés et identiques au serveur local, je procède à la restauration via kickstart.php et je supprime la page HTML de maintenance. Je vérifie ensuite le bon fonctionnement du site en testant diverses fonctionnalités telles que la navigation, l'envoi de mails, etc. Je veille également à conserver le travail SEO précédent en mettant en place les redirections nécessaires. (soit dans le htaccess, soit dans le composant de redirection).
Après la migration, je supprime toutes les traces des fichiers de migration et je vérifie les paramètres de sauvegarde du nouveau site. Si nécessaire, je procède ensuite à une optimisation et à une sécurisation avancée, avec surveillance (monitoring) si demandé par le client.
Il est essentiel de disposer d'une copie fonctionnelle de l'ancien site en cas de problème avec l'hébergement qui ne respecte pas les prérequis. Travailler en local permet de rapidement détecter et corriger d'éventuelles erreurs dans les archives. En général, je réalise la restauration en dehors des heures ouvrées pour limiter les connexions et je vérifie la connexion à la base, bien que ce soit optionnel car kickstart.php le fait également.
Bien que la migration puisse parfois être complexe, il est important de ne pas remettre en cause le CMS. Cette expérience offre également l'occasion de revoir les choix d'hébergement et de corriger d'éventuelles erreurs avant de repartir sur plusieurs années avec une nouvelle version. Restons optimistes et voyons cela comme une opportunité d'évolution et d'amélioration continue.
Commentaire