migrations des serveurs non-DC, et migrations
des stations de travail.

En principe, la migration des serveurs
en arrière-plan peut s’effectuer
avec moins de contraintes de temps
que pour les comptes utilisateur.
Egalement, la migration des serveurs
DC et non-DC peut s’effectuer en parallèle.
Mais, bien entendu, la migration
des DC doit se faire selon un calendrier
en harmonie avec la migration
des serveurs non-DC et avec celle des
comptes utilisateur parce que les DC
jouent un rôle dans l’authentification
des comptes machine et utilisateur. La
migration des stations de travail peut
se faire en parallèle avec toutes les
autres migrations. Il semble judicieux
de faire la migration des serveurs pendant
la nuit durant la semaine en laissant
la migration lourde des comptes
au week-end.

Nous donnons quelques directives
pour chacune des quatre actions dans
les sections qui suivent. Soulignons
d’emblée que c’est les migrations des
comptes utilisateur que la population
utilisatrice percevra comme l’élément
de migration le plus perturbant.

Avant de commencer l’une quelconque
des phases, documentez entièrement
le processus de migration et
testez-le dans le lab plusieurs fois, en
améliorant la documentation et votre
processus au fur et à  mesure. Restaurez
les sauvegardes des serveurs réels
que vous allez migrer, dans votre environnement
lab, qui devrait ressembler
le plus possible à  l’environnement réel.
Si vous n’avez pas d’environnement
lab, créez-en un. Poussez la répétition
au point d’entrer réellement dans les
salles où les serveurs sont en action ;
de nombreux projets ont échoué parce
que la clé d’un rack crucial n’était pas
disponible au bon moment. Le temps
de préparation sera largement compensé
par moins de surprises désagréables
pendant la migration réelle.

En même temps que vous vous entraînez
à  la migration, il faut y préparer
les utilisateurs. Comme nous l’avons
dit au début de l’article, la fusion de
domaines perturbe les utilisateurs sans
afficher beaucoup d’avantages visibles.
Il faut donc expliquer les raisons du
changement – c’est-à -dire, vendre le
projet. Utilisez les canaux de communication
dont vous disposez, sans vous
cantonner à  des messages e-mail globaux.
Ecrivez un article dans le magazine
d’entreprise. Si le projet est suffisamment
vaste, donnez-lui une
marque, un nom, un site intranet, voire
un logo. Les utilisateurs seront mieux
disposés s’ils savent de quoi il retourne.