Mi postfix/dovecot szerver cserét és postfix/courier->postfix/dovecot átállást (FreeBSD, Linux különböző kombinációkban) csináltunk párat az elmúlt években (volt FreeBSD postfix/courier POP3->Zentyal 6.0 átállás is, ahol az új szerver AD-ként is funkcionált). Annyiban lehet releváns a tapasztalatom, hogy ha az Exchange IMAP-on kiszolgál, akkor eléggé hasonló a migrációs lehetőség, mint Linux/BSD alapról.
Mi mindig úgy csináltuk, hogy az új szerver felállítása és tesztelése után megkapta a bejövő levél forgalmat, és a felhasználók webmail-en elérhették azonnal az új leveleket. A régi szerver onnantól read-only volt akár webmail akár desktop kliens irányából.
A meglévő leveleket attól függően kezeltük, hogy
- ha addig POP3 volt és a desktopon gyűlt minden, akkor az IMAP fiókot felvettük a kliensbe, és bemásoltuk a leveleket, majd töröltük az eredeti POP3 verziót,
- ha IMAP volt, akkor imapsync-kel közvetlen a szerverek között ment a másolás, és "egyszer csak" látta a webmail-en a felhasználó az összes levelét (ebben az a jó, hogy a látott, timestamp, stb. IMAP flag-ek megmaradnak).
Mindkettő időigényes, ha a felhasználók GB-os vagy akár több 10 GB-os levelezést halmoztak fel (mert ugye az e-mail a dokumentumtár/iktatás is egyben, és hátha egyszer kell még az a spam-nak tűnő levél vagy az az akciós újság ami 1 hétig érvényes...).
A klienseket pedig a postafiók migráció közben vagy után állítottuk át az új szerverre (ha pl. imapsync megy, akkor közben gond nélkül lehet az érintett klienseken a fiókot cserélni a várakozási időben).
Kliens cserénél arra figyelj, hogy a legtöbb ember nem épít címjegyzéket (lokálisat sem, nemhogy közöset), hanem a levelező kliens automatikus kiegészítés szolgáltatására alapoz. Új kliens esetén, címjegyzék hiányában (0 tételt migráltál) egy e-mail sem lesz meg. Aztán mehet a magyarázkodás, hogy nem te migráltál rosszul, hanem a felhasználó használta eddig is rosszul a klienst. Utána meg az Outlook automata javítás gyorsár állmány->Thunderbird address book konverzió gúglizás (van ilyen egyébként :-)...
A másik, hogy aki Outlook-hoz szokott, az mindenre köpköd, mert máshogy néz ki. Akkor is, ha életében csak az új levél gombot használta, semmi mást.
Emiatt előre meg kell állapodni, milyen kliens legyen, és ragaszkodj hozzá, hogy egyforma legyen minden gépen, ne választhasson a felhasználó. Volt olyan cégünk 120 fiókkal, ahol a helyi IT azt mondta, hogy a szokások felmérése után abban maradtak a vezetéssel, hogy csak webmail lesz, megfelelő plugin-ekkel, és desktop kliens semmiféle senkinél. Volt hiszti, de megszokták, és azóta az IT-nek sokkal kevesebb a gondja ilyen téren. Máshol mi álltunk át TB-re, mert ősrégi Outlook-ok voltak (amit sóherségből nem akartak frissebbre cserélni), amik folyton belefordultak a PST 2 GB-os limitbe (a felhasználót meg nem érdekelte, hogyan lehetne ezt elkerülni).
Mi jellemzően "hosszú hétvégésen" (pénteken munkaidő végétől vasárnap estig) vállalunk ilyesmit, ami a cégek túlnyomó részénél nem munkaidő, így nem hiányzik a levelezés annyira. Ezen felül mindig állítunk be backup MX-et az egész művelet előtt, hogy ha bármi félre megy a szerver-váltás során, levelek ne vesszenek el. A backup MX-et aztán van aki megtartja szolgáltatásként, van aki nem kéri tovább.
Én nem javaslom a postafiókonkénti átállást plusz proxy-val meg kétfelé irányított egyetlen tartománnyal, irtózat macera lenne ennyi fióknál (is meg kevésnél is). Ha többen csináljátok, egyeztetni kell ki hol tart, ha meg egyedül csinálod, sose fogy el. Tényleg úgy lehet a legmagasabb a rendelkezésre állás, de meg kell fontolni, ér-e annyit. Ezt pedig úgy lehet, hogy ezt a verziót úgy kell beárazni, hogy ha ezt választják, akkor tényleg nektek is megérje, ne csak az ügyfélnek.
A cégnek meg kell értenie, hogy ez egy nagy munka és sok idő. Nem szabad azt engedni, hogy az ügyfél diktáljon minden paramétert, mert abból úgy is teljesíthetetlen dolog jön ki és csak a rossz szájíz marad a végén (legyen ingyen az sw, munkadíj minimális, 0 perc kiesés, senkit ne zavarj a munkában, de délután/hétvégén nem tudunk beengedni, stb.). Ha árérzékeny, akkor nem tudsz kellő számú embert bevonni az egy napon belüli migrációhoz, ha meg nincs elég embered, akkor túl szűk a határidő.
Azt is meg kell érteni, hogy a munkadíj komoly egy ilyen manővernél. Max. a licenc költség spórolható meg, de attól még a feladat komoly, ami nem olcsó. Sokan azt is hiszik, hogy az "ingyenes" szoftvert ingyenesen (de legalábbis sokkal-sokkal olcsóbban) is telepíti/üzemeli be a hozzá értő szakember - pedig ezt nem szabad, a tudás az igazi érték. Nem véletlen, hogy a felhős szolgáltatók azzal érvelnek (jogosan), hogy oké, hogy ingyen van a szoftver, de mibe kerül a szakember, aki telepíti és üzemelteti.
A legtöbben ragaszkodnak hozzá, hogy nem lehet szolgáltatás kiesés, de valójában az üzletmenet elbírna akár napokat is, csak a felhasználók túlgondolják/túlértékelik. A másik, amit meg kell érteniük az elején, hogy az e-mail nem egy garantált szolgáltatás, így "akárhol" is elakadhat a levél attól függetlenül, hogy épp migráció van vagy normál működés. Sokan azt hiszik, az e-mail egy azonnali és garantált szolgáltatás, csupán arra alapozva, hogy a legtöbb esetben nagyjából azonnal megkapják, amit a másik fél küld, és azt hiszik emiatt, hogy ez az alap, ami nem ilyen, az hibásan működik.