Миграция
Миграция без прекъсване означава, че всяко съобщение, изпратено до Вашия домейн, пристига в пощенска кутия и че всеки служител може да пише на своите кореспонденти в деня на превключването. Тя не означава, че историята, мобилните устройства и навиците се променят без никакво действие.
Две платформи работят паралелно.
Класическата дупка идва от MX запис, превключен, докато едно копие е непълно, или от копирна машина, сайт или CRM, които все още изпращат със стария идентификатор.
MX е DNS запис: той указва на изпращащите сървъри къде да доставят пощата за Вашия домейн. Смяната на имейл услугата е преди всичко смяна на този адрес за доставка. Останалото (акаунти, история, устройства) се подготвя около нея.
Протоколът SMTP понася добре кратките инциденти. Изпращащ сървър, който получи временна грешка, задържа съобщението в опашката и опитва отново по-късно. Временно недостъпен сървър следователно не води до загуба на поща. Окончателна грешка (непозната пощенска кутия, отхвърлено съобщение) обаче връща съобщението на подателя му и това съобщение никога няма да пристигне от само себе си. Основният риск при превключването не е сривът, а новата платформа, която отхвърля получател, защото даден псевдоним или списък не е бил създаден отново.
TTL (време на живот) определя колко дълго един DNS резолвер може да пази отговор в паметта си. През този период част от подателите все още доставят към старата платформа. Това е нормално и именно затова старата трябва да остане способна да получава по време на прехода.
Две седмици преди това. Опис на пощенските кутии, псевдонимите, списъците, споделените кутии и всички приложения, които изпращат имейли. Намаляване на DNS TTL на MX записа до кратка стойност (често 300 секунди), за да може промяната в деня на превключването да се разпространи бързо. Създаване на целевите акаунти. Първо копие на историята.
TTL се намалява рано, защото резолвер, който е прочел старата стойност, я пази до изтичането ѝ: краткият TTL влиза в сила едва след като старият кеш изтече. Първото копие пък е най-дългото; ранното му стартиране дава време да се открият проблемните пощенски кутии.
Няколко дни преди това. Проверка на извадка: брой съобщения, папки или етикети, срещи, контакти. Коригиране на метода, ако извадката не мине. Подготовка на инструкциите за мобилни устройства и Outlook. Тестово изпращане от целевата платформа към Gmail и Outlook.com, като SPF, DKIM и DMARC вече са валидни за новата платформа. Тези записи могат да бъдат публикувани преди MX.
Конкретно: един-единствен SPF запис, който разрешава и двете платформи по време на прехода (два отделни SPF записа водят до неуспешна проверка), DKIM ключ на новата платформа, публикуван под собствен селектор до стария, и преразгледана DMARC политика. DMARC изисква съобщението да е удостоверено чрез SPF или DKIM от името на домейна на подателя; ако политиката Ви е строга, а целевата платформа все още не е разрешена, кореспондентите Ви ще отхвърлят съобщенията Ви.
В навечерието. Втори проход: копира се само това, което е пристигнало след първото копие. Замразяват се промените в псевдонимите и списъците.
В деня на превключването. Превключване на MX. Незабавна външна проверка: имейл, изпратен от външна лична пощенска кутия, трябва да пристигне в новата платформа в рамките на TTL. Наблюдение на опашката. Преконфигуриране на изпращащите приложения. Определена вътрешна линия за поддръжка с правото да върне MX обратно, ако критичен поток се провали.
Едновременно с това променете и записа autodiscover, ако съществува: именно към него се обръща Outlook, за да намери своя сървър. Премахнете също вторичните MX записи, които все още биха сочили към старата платформа: подател, който не успее да достигне основния MX, опитва следващите.
Следващите дни. Старата платформа в режим само за четене. Докладване на несъответствия (липсваща папка, споделена кутия). Трети, целенасочен проход при нужда. След това спиране на изпращането от старата платформа, за да не отговаря служител от две места.
Тази последна стъпка има техническа причина. Старата платформа продължава да се смята за отговорна за Вашия домейн: съобщение, изпратено от нея до колега, се доставя локално там, без да се проверява MX. Колегата никога няма да го види в новата си пощенска кутия.
| Риск | Какво се случва | Мярка |
|---|---|---|
| MX е превключен твърде рано | Новата поща пристига, историята липсва | Превключване след проверка на извадката и втори проход |
| Забравен псевдоним или списък | Целевата платформа окончателно отхвърля тези съобщения | Опис, замразяване на псевдонимите в навечерието, тест на колективните адреси |
| Непълни SPF, DKIM или DMARC | Съобщенията Ви се отхвърлят или попадат в нежелана поща при кореспондентите | Публикуване преди деня на превключването, проверка с реално съобщение |
| Приложение, което изпраща със стария акаунт | Фактури, известия или сканирания вече не се изпращат | Списък на приложенията, нов SMTP сървър, конфигуриран в деня на превключването |
| Изпращането от старата платформа е останало отворено | Вътрешни съобщения остават в старата система | Спиране на изпращането веднага след валидиране на извадката |
| Неподготвено връщане назад | MX се връща обратно, но съобщенията, получени междувременно, остават в целевата платформа | Писмен план, включващ прехвърлянето на тези съобщения |
Да вземем за илюстрация кантора с 40 души. Тя избира да превключи в четвъртък в края на деня, а не в петък: на следващия ден екипът е на място, за да обработи несъответствията, а вътрешната линия за поддръжка разполага с цял работен ден. Копирната машина на рецепцията, която сканира към имейл, се преконфигурира още същата вечер. Ако за две споделени кутии бъде докладвана липсваща папка, целенасочен проход ги допълва. В този сценарий нито едно съобщение не се губи, но няколко служители трябва да настроят отново акаунта си на телефона: това е видимата част, която трябва да бъде обявена.
Те сменят сървъра в Outlook или на мобилното устройство. Първото зареждане на голяма пощенска кутия отнема време. Съобщенията, които вече са в кеша на телефона, може да се дублират, ако профилът не бъде създаден наново по правилния начин. Предвидете процедурата „изтриване на акаунта и създаването му наново“ вместо импровизирана смяна на сървъра.
Причината е същата и за Outlook: профилът пази локален кеш, свързан със стария сървър. Новият профил започва от чисто състояние; старият, променен профил смесва двата свята. На мобилните устройства използваният протокол (Exchange ActiveSync или IMAP според целевата платформа) понякога се сменя заедно с платформата, което е още една причина акаунтът да се създаде наново.
Правилата от страна на сървъра, централизираните подписи и правата за делегиране се настройват отново. Обявете го. Това не е прекъсване на пощата. Това е административна работа.
Това препращане изисква изрична настройка: старата платформа, която все още смята, че хоства пощенските кутии, трябва да бъде конфигурирана да препредава към новата, вместо да доставя локално. В противен случай същата работа се извършва от целенасочен допълващ проход.
Особеностите на всяка изходна точка са описани в миграция от Microsoft 365 и миграция от Google Workspace.
Колкото е нужно, за да се провери, че вече никой поток не използва старата и че докладваните несъответствия са отстранени. Това зависи от броя на пощенските кутии, от изпращащите приложения и от темпото на преконфигуриране на работните станции. Твърде ранното затваряне пречи на корекциите; твърде късното оставя служители да работят в две системи.
Не, ако е подготвена. През времето на TTL част от подателите все още доставят към старата платформа, а останалите към новата. И двете получават, а следващият проход обединява двете. Пощата се губи само ако бъде отхвърлена, откъдето идва и значението на псевдонимите и списъците.
По принцип не: адресите не се променят. Уведомете обаче партньорите, които филтрират строго съобщенията Ви или са Ви задали специално правило, както и тези, които обменят с Вас криптирана поща, ако ключовете се променят.
Да, като се възстанови старият MX, при условие че старата платформа все още е активна. Съобщенията, получени междувременно от новата, трябва тогава да бъдат копирани обратно или да останат достъпни. Планът за връщане назад определя кой решава, за колко време и как се прехвърлят тези съобщения.
Попитайте оператора на услугата какво гарантира: пристигането на съобщенията, прехвърлянето на историята или и двете. Това са различни ангажименти. Поискайте също писмен план за връщане назад, с лицето, което има право да го задейства.
Гаранцията за пристигането на съобщенията се отнася до деня на превключването и следващите дни. Гаранцията за историята се отнася до копирането и неговата проверка. Един доставчик може да изпълни едната без другата; офертата трябва да посочва коя поема и как се проверява тя.
В Klytic съветите и препоръките за подготовка на миграцията на имейл услугата са безплатни и нито един имейл не се губи. Миграцията, извършена от Klytic, се изготвя по оферта. Абонаментите са на страницата Цени и се фактурират отделно. Подробности за разходните пера има в колко струва миграция от Microsoft 365, а контролният списък е в чеклиста. За сравнение на целевите платформи вижте избор на европейска имейл услуга.
Тази страница описва метод. Реалният ход зависи от Вашите потоци, обеми и от платформата, която напускате.
Проверено през октомври 2026 г.
Безплатна консултация, без нито един загубен имейл. Миграция, извършена от Klytic, се оферира след инвентаризация.
Приветствена оферта
Пробна оферта без ангажимент. Консултант ще Ви се обади, за да разбере нуждите Ви и да подготви Вашето пространство в Klytic.
