Migrer les emails entre hébergeurs : dossiers et doublons

Migrer les emails vers un autre hébergeur paraît simple jusqu'à ce qu'une boîte soit copiée deux fois ou que l'historique des envois semble disparaître. La messagerie n'est pas un ensemble de fichiers : dossiers et identités doivent être compris.

Vous copiez des données IMAP actives entre deux serveurs ayant des règles de dossiers et de UID différentes. Une mauvaise hypothèse peut laisser des dossiers apparemment vides, des conversations en double ou la correspondance répartie entre les systèmes.

Prévoyez une migration progressive, une correspondance explicite des dossiers et des vérifications après bascule. Pour planifier le choix des fournisseurs, les coûts et le contrôle des comptes, consultez la messagerie professionnelle. Ici, nous traitons la migration elle-même.

Vers TrekMail, commencez par la présentation de la migration IMAP, puis les instructions Gmail ou cPanel selon la source. Le texte décrit une migration sur serveur dans les plans payants à partir de $3.50 par mois, Nano gratuit sans carte bancaire et un essai de 14 jours pour les plans payants. Vérifiez fonctions, disponibilité et conditions actuelles.

Que transfère une migration entre hébergeurs ?

Un outil IMAP accède à l'ancienne boîte, lit dossiers et messages, puis les copie dans la nouvelle. Il ne normalise pas automatiquement les noms, ne supprime pas tous les doublons de la source et ne coordonne pas le DNS sauf si le processus prévoit ces tâches.

C'est une copie entre deux systèmes. La source peut rester intacte, tandis que la destination reçoit les messages, la structure et les indicateurs compatibles, comme lu ou non lu, lorsque la source les fournit. Contacts, calendriers et règles ne font pas partie de cette copie IMAP. Vérifiez le périmètre de l'outil et les différences d'identification.

La RFC 3501 décrit UID et UIDVALIDITY par dossier IMAP. Ils identifient les messages dans ce dossier et la génération du dossier caractérisée par UIDVALIDITY, pas globalement entre serveurs. Un outil utilisant cet état peut perdre sa correspondance avec les copies antérieures si cette génération change.

Une première passe correcte ne garantit donc pas l'absence de doublons à la seconde. « Terminé » dans le tableau de bord ne remplace pas la vérification des données.

Pourquoi des doublons apparaissent

La perte de correspondance est une cause possible : UIDVALIDITY modifié, dossiers recréés ou libellés Gmail traités comme dossiers indépendants. Selon la méthode de comparaison, des messages déjà copiés peuvent être importés de nouveau.

UIDVALIDITY et état de synchronisation

Certains outils gardent des correspondances UID par dossier; d'autres utilisent des en-têtes ou d'autres critères. Une réindexation ne change pas forcément les UID. Recréer un dossier ou perdre l'état peut toutefois modifier la comparaison. Vérifiez le mécanisme avant de relancer.

La RFC 3501 lie stabilité UID et UIDVALIDITY. Si cette génération change, les anciens UID ne désignent plus fiablement les messages actuels du dossier. Une nouvelle passe pourrait recopier des milliers de messages sans autre comparaison fiable.

Exemple : 38,000 messages sont copiés depuis la boîte de réception. Après expiration d'un délai, le travail est relancé, mais un dossier a été reconstruit pendant la nuit. Sans correspondance fiable ni détection des copies existantes, l'outil pourrait ajouter 38,000 messages supplémentaires.

Les libellés Gmail

Gmail ne fonctionne pas exactement comme un serveur traditionnel à dossiers. Un message peut avoir plusieurs libellés; les archives figurent dans Tous les messages. Archiver retire de la boîte de réception sans retirer de cette collection.

Importer [Gmail]/All Mail avec les dossiers de libellés peut représenter le même message plusieurs fois à destination. Ces copies peuvent être souhaitées pour préserver la présentation des dossiers. Définissez comment préserver les messages uniques, représenter les libellés et prévoir l'espace nécessaire.

Le guide d'importation depuis Gmail aide à préparer l'accès. L'importateur TrekMail utilise des identifiants IMAP directs. Les mots de passe d'application dépendent de la validation en deux étapes et des politiques du compte. S'ils sont indisponibles, envisagez une autre méthode autorisée ou un autre outil compatible OAuth, sans présumer un support interactif de l'importateur.

Cet exemple n'est pas sûr pour tous les cas : exclure Tous les messages peut omettre des archives sans autre libellé. Prévoyez comment copier tous les messages archivés, protégez les identifiants et vérifiez chiffrement et certificats des connexions :

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

La simulation ne copie pas de messages et ne teste pas un transfert complet. Message-ID peut manquer, se répéter ou être peu fiable : il ne suffit pas toujours à éviter les doublons. Évitez les vrais secrets dans l'historique du shell ou la liste des processus et faites une copie pilote avec vérification du contenu. Le guide imapsync détaille les options.

Pourquoi certains dossiers n'apparaissent pas

Un dossier peut arriver dans une autre hiérarchie, avec un nom spécial différent ou un préfixe mal affiché. La copie peut aussi avoir échoué : vérifiez le serveur avant de conclure à un simple problème visuel.

Espaces de noms et séparateurs

Les serveurs utilisent des séparateurs et espaces de noms différents, tels que INBOX.Sent, Inbox/Sent Items ou un préfixe imposé INBOX..

Sans correspondance vérifiée, Project.Alpha peut devenir un sous-dossier de Project. Un dossier spécial peut apparaître comme personnalisé; le client mobile peut alors s'abonner au mauvais dossier ou le masquer.

Les dossiers des messages envoyés

Un serveur utilise Sent, un autre Sent Items, un autre Sent Messages. Vérifiez les noms et attributs d'usage spécial de la destination, ainsi que le client.

Si le dossier source arrive comme dossier personnalisé sans correspondance avec les envois, le dossier par défaut peut sembler vide alors que l'historique existe ailleurs. Confirmez que les messages ont effectivement été copiés.

Pour un hébergement partagé, consultez la migration depuis cPanel ou d'autres hébergeurs. Le guide aide à identifier les accès habituels, mais vous devez tester identifiants, permissions et dossiers de votre source.

Plan de migration en 3 phases

Un processus en trois phases peut réduire les risques : préparez l'historique, synchronisez les changements près de la bascule et vérifiez les arrivées sur l'ancien après modification MX. Il ne garantit ni absence d'interruption ni absence de doublons. Adaptez étapes et retour arrière.

1. Synchronisation historique. Copiez d'abord les anciens emails; plus de 30 jours est une fenêtre illustrative. Les utilisateurs peuvent continuer sur la source, avec suivi des changements.
2. Synchronisation différentielle. Lancez une seconde passe pour les nouveaux messages et changements pertinents, y compris déplacements et indicateurs. Couvrez aussi les arrivées tardives avec une date ancienne, pas seulement un filtre des messages récents. Préservez l'état et vérifiez la comparaison avec l'historique copié.
3. Bascule et passes finales. Modifiez MX après tests. Maintenez la réception sur l'ancien tant que caches et nouvelles tentatives peuvent y conduire des messages, même après le TTL, avec les passes complémentaires nécessaires.

Des erreurs DNS peuvent maintenir les arrivées sur l'ancien ou provoquer des rejets. Consultez les enregistrements DNS requis pendant la préparation.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

Ce sont des exemples, pas des valeurs prêtes à publier : vérifiez le tableau de bord de votre compte, préservez les expéditeurs SPF légitimes, vérifiez DKIM aligné et n'appliquez pas la quarantaine sans inventaire ni tests. Après vérification des données et configuration des clients, limitez éventuellement les écritures utilisateurs sur la source pour éviter des envois répartis. Ne coupez pas immédiatement sa réception ni l'accès administratif nécessaire aux deltas et au retour arrière.

Cette méthode aide également les agences avec plusieurs marques. La dispersion opérationnelle dépasse la copie : consultez l'hébergement email multidomaine pour évaluer la centralisation.

Vérifications après migration

Comparez nombres de messages, dates extrêmes et hiérarchies, ainsi que des échantillons de contenu, pièces jointes et indicateurs. Le volume en gigaoctets ne suffit pas : compression, indexation et représentation peuvent varier sans perte.

1. Comparer éléments et périmètre

Avec 4,502 éléments avant bascule, attendez 4,502 dans le dossier correspondant lorsque le périmètre et les exclusions approuvées sont identiques et sans changement récent. L'égalité ne prouve pas l'intégrité : comparez contenu, pièces jointes, dates et indicateurs. Distinguez messages Gmail uniques et copies par libellé.

2. Vérifier les dates extrêmes

Comparez messages les plus anciens et récents dans réception et envois. Une absence demande de revoir filtres, correspondances et passes historiques ou différentielles; la date seule n'identifie pas la passe fautive.

3. Rechercher des dossiers mal associés

Cherchez INBOX.Sent à la racine, des restes [Gmail] ou plusieurs dossiers d'envoi. Ils peuvent révéler une mauvaise correspondance, mais certaines représentations sont intentionnelles.

4. Tester réception et envoi réels

Envoyez depuis une boîte externe, puis répondez depuis la destination. Vérifiez arrivée, authentification et dossier de la réponse. Étendez les tests aux flux importants.

5. Mettre à jour les clients

Une copie correcte peut sembler incomplète si le client utilise l'ancien serveur. Mettez à jour IMAP et SMTP selon la destination et vérifiez dossiers, abonnements et accès utilisateurs.

Copie et remplacement du fournisseur doivent donc être planifiés ensemble. L'alternative à Titan Email traite cette même transition : la copie de la boîte n'est qu'une partie du changement.

Gestion manuelle et migration avec TrekMail

La gestion manuelle peut multiplier les tâches et correspondances particulières. TrekMail décrit migration IMAP sur serveur, stockage mutualisé et tableau de bord des domaines, boîtes et DNS selon le plan. Vérifiez protection contre les doublons et couverture réelle; aucun tableau de bord ne remplace les tests.

Centraliser peut réduire le travail d'une équipe ou agence. Un lieu au lieu de cinq est une illustration, pas un gain garanti. Consultez les tarifs actuels TrekMail; Nano et l'essai de 14 jours des plans payants dépendent des conditions et de la disponibilité en vigueur.

Conclusion

Pour migrer les emails vers un autre hébergeur, préparez une bascule IMAP contrôlée plutôt qu'une copie massive sans vérification. Définissez dossiers et couverture des archives Gmail, testez les transferts, synchronisez les changements et vérifiez données et clients. Retirez les accès anciens au bon moment, en maintenant réception et retour arrière nécessaires, sans promettre absence de perte ou d'interruption.

Pour évaluer TrekMail comme destination, consultez trekmail.net. Comparez hébergement multidomaine, modèle de plateforme, stockage mutualisé et migration IMAP aux fonctions et limites actuelles, sans présumer qu'ajouter un utilisateur n'entraîne jamais de coût supplémentaire.