Як перанесці сайт на новы хостінг без страты даных: поўнае кіраўніцтва па міграцыі

Міграцыя сервера — гэта спланаваны працэс пераносу файлаў сайта, базы даных, паштовых акаўнтаў, DNS-запісаў і налад праграм са старога сервера на новы. Галоўны прынцып пераезду без страты даных — спачатку зрабіць поўны бэкап, падрыхтаваць новы сервер з ідэнтычнымі ці навейшымі версіямі ПЗ, перанесці файлы і базу, пратэставаць сайт праз hosts-файл або часовы URL, змяніць DNS з нізкім TTL і пасля пераключэння праверыць логі, формы, аплатныя шлюзы, дастаўку пошты і SEO-сігналы.

Перанос сервера — гэта не простае капіраванне і ўстаўка. Асабліва для WordPress, WooCommerce, Laravel, уласных PHP-распрацовак, навінавых парталаў з высокай наведвальнасцю ці бізнесаў з карпаратыўнай поштай, памылковая міграцыя можа прывесці да страты замоваў, бітых сімвалаў (замест беларускіх літар — “краказябры”), памылак 500, папярэджанняў SSL, перабояў з поштай і падзення пазіцый у пошукавых сістэмах. Таму план міграцыі павінен уключаць тэхнічны чэк-ліст і сцэнар адкату.

У гэтым кіраўніцтве мы пакрокава разгледзім, як змяніць хостінг ці сервер у адпаведнасці з патрабаваннямі SEO і прадукцыйнасці на 2026 год. Мы закранем розныя сцэнары: перанос праз cPanel, Plesk, VPS, воблачныя серверы і ручную міграцыю, а таксама падзелімся практычнымі парадамі па часе DNS-абнаўлення, аб'ёме бэкапу, сумяшчальнасці баз даных, усталяванні SSL і пост-міграцыйных SEO-праверках.

Калі патрэбны перанос сервера?

Звычайна пераезд на новы сервер выкліканы патрэбай у прадукцыйнасці, бяспецы, зніжэнні выдаткаў ці маштабаванні. Напрыклад, карпаратыўны сайт з 5 000 наведвальнікаў у месяц можа выдатна працаваць на агульным хостінгу, але інтэрнэт-крама з 20 000 наведвальнікаў у дзень можа сутыкнуцца з лімітам CPU, павольнымі запытамі і тайм-аўтамі на старонцы аплаты. У такі момант лепш абраць больш магутны тарыф хостінгу, VPS ці воблачную інфраструктуру.

Вось асноўныя сігналы, якія паказваюць на неабходнасць пераезду:

• Час загрузкі старонкі перавышае 3 секунды, і метрыкі Core Web Vitals пагаршаюцца.
• У панэлі кіравання хостінгам часта дасягаюцца ліміты CPU, RAM, inode ці дыскавай прасторы.
• Неабходнасць пераходу на больш свежыя версіі PHP, MySQL, MariaDB, Node.js ці ionCube.
• Пастаянныя праблемы з абнаўленнем SSL, дастаўкай электроннай пошты ці кіраваннем DNS.
• Недастатковы ўзровень падтрымкі, бэкапавання ці бяспекі ў цяперашняга правайдэра.
• Рэзкі рост трафіку падчас рэкламных кампаній ці сезонных акцый.

Калі ваш сайт расце і набліжаецца да межаў бягучага тарыфу, нашмат бяспечней стварыць кантраляваны план міграцыі, чым рабіць гэта ў апошні момант падчас крызісу. У залежнасці ад вашых патрэб вы можаце параўнаць Пакеты вэб-хостынгу, Серверныя рашэнні VPS ці Карпаратыўны Хостынг, каб правільна абраць інфраструктуру.

Падрыхтоўка да міграцыі: самы крытычны этап

Большасць няўдалых міграцый здараюцца не падчас пераносу, а з-за недахопу падрыхтоўкі. Перад пачаткам пераезду неабходна правесці інвентарызацыю бягучага сайта, дакладна вызначыць, якія даныя будуць пераносіцца і якія сэрвісы найбольш адчувальныя да перабояў.

1. Праведзіце інвентарызацыю сайта

Першы крок — стварыць тэхнічную мапу сайта. Занатаваць CMS ці фрэймворк, версію PHP, тып базы даных, аб'ём дыска, паштовыя акаўнты, заданні cron, DNS-запісы, SSL-сертыфікат, спецыяльныя рэдырэкты і інтэграцыі з іншымі сэрвісамі. Напрыклад, для сайта на WordPress недастаткова проста скапіраваць тэчку wp-content; трэба таксама праверыць правілы .htaccess, налады wp-config.php, прэфіксы табліц базы даных, плагіны кэшавання і медыяфайлы.

Для інтэрнэт-крамы дадаткова трэба вывучыць плацежную сістэму, інтэграцыю дастаўкі, сінхранізацыю складоў, падключэнне ERP, SMTP-сэрвіс і URL-адрасы webhook. Калі пасля пераезду замовы не паступаюць, праблема часцей за ўсё не ў пераносе файлаў, а ў забытым абмежаванні API па IP ці правіле бяспекі, прывязаным да старога сервера.

2. Зрабіце поўны бэкап і праверце яго

Падчас міграцыі проста зрабіць бэкап недастаткова; трэба пераканацца, што яго можна паспяхова аднавіць. Поўны бэкап павінен уключаць:

• Файлы сайта: public_html, тэчкі праграм, дырэкторыі загрузак, тэмы і плагіны.
• Базы даных: MySQL, MariaDB, PostgreSQL ці іншыя, якія выкарыстоўваюцца.
• Паштовыя даныя: паштовыя скрыні, перасылкі, фільтры, налады аўтаадказчыка.
• DNS-запісы: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
• Канфігурацыі: .htaccess, nginx.conf, php.ini, cron-заданні, файлы асяроддзя.
• SSL-сертыфікаты і адмысловыя правілы бяспекі.

Добрай практыкай будзе зрабіць мінімум дзве копіі бэкапу: адну пакінуць на старым серверы, другую захаваць у іншым месцы. Для вялікіх сайтаў можна выкарыстоўваць rsync для файлаў і mysqldump для базы даных або інструменты рэзервовага капіравання панэлі. Для баз даных памерам больш за 10 ГБ лепш выкарыстоўваць сціснутыя і разбітыя на часткі дампы замест аднаго вялікага файла — гэта больш надзейна.

3. Загадзя знізьце значэнне DNS TTL

Каб DNS-змены распаўсюдзіліся хутка, рэкамендуецца знізіць TTL за 24 гадзіны да міграцыі. Напрыклад, калі TTL складае 14400 секунд, некаторыя карыстальнікі могуць гадзінамі працягваць трапляць на стары сервер. Калі перад міграцыяй паменшыць TTL да 300 секунд, пераключэнне адбудзецца больш кантралявана. Пасля завяршэння пераезду і праверкі ўсяго функцыяналу TTL можна зноў павялічыць да 3600 ці 14400 секунд.

Правільнае кіраванне DNS вашага дамена непасрэдна ўплывае на поспех міграцыі. Для налад дамена і DNS вы можаце азнаёміцца з кіраўніцтвам Праверка дамена і кіраванне даменамі.

Параўнанне метадаў пераносу сервера

Не існуе адзінага ідэальнага метаду міграцыі. Невялікі карпаратыўны сайт можна лёгка перанесці праз панэль кіравання, а вось інтэрнэт-краме з высокім трафікам можа спатрэбіцца паэтапная сінхранізацыя і рэжым абслугоўвання.

Пры выбары новай інфраструктуры арыентавацца толькі на дыскавую прастору памылкова. Колькасць PHP worker, ядра CPU, RAM, NVMe-дыскі, частата бэкапавання, размяшчэнне дата-цэнтра, падтрымка LiteSpeed ці Nginx, WAF і абарона ад DDoS — усе гэтыя крытэрыі таксама вызначаюць прадукцыйнасць. Таму пераход на самы танны тарыф без аналізу патрэб можа прывесці да неабходнасці паўторнага пераезду ўжо ў бліжэйшы час.

Пакрокавая інструкцыя па пераносе сервера

Крок 1: Падрыхтуйце новы сервер

На новым серверы трэба ўсталяваць аперацыйную сістэму, вэб-сервер, патрэбную версію PHP, сэрвіс базы даных і неабходныя модулі. Для WordPress рэкамендуецца PHP 8.2 ці 8.3, актуальная MariaDB, OPcache і адпаведнае значэнне memory_limit. Для фрэймворкаў накшталт Laravel дадаткова трэба наладзіць Composer, cron, queue worker і правы доступу да storage. Калі PHP-пашырэнні, якія працавалі на старым серверы, адсутнічаюць на новым, пасля пераезду вы можаце ўбачыць белы экран ці памылку 500.

У плане бяспекі трэба наладзіць палітыку SSH-партоў, усталяваць надзейныя паролі, файрвол, сканер шкоднасных праграм і аўтаматычныя абнаўленні. Закласці аснову бяспекі на новым, яшчэ пустым серверы значна прасцей, чым выпраўляць недахопы пазней. Калі вам патрэбен SSL, абавязкова ўключыце ў план міграцыі пытанне Устаноўка сертыфіката SSL.

Крок 2: Перанясіце файлы

У залежнасці ад памеру сайта для пераносу файлаў можна выкарыстоўваць FTP, SFTP, SSH, rsync ці рэзервовае капіраванне праз панэль. Для невялікіх сайтаў дастаткова стварыць сціснуты архіў і распакаваць яго на новым серверы. Для буйных сайтаў рэкамендуецца спачатку зрабіць першую копію праз rsync, а другую сінхранізацыю выканаць непасрэдна перад зменай DNS. Гэты метад эканоміць час, асабліва для сайтаў, дзе тэчка uploads пастаянна змяняецца.

Пасля пераносу файлаў абавязкова праверце правы доступу. Звычайна для тэчак выкарыстоўваюцца правы 755, для файлаў — 644, але кожная праграма можа мець свае патрабаванні. Канфідэнцыяльныя файлы, такія як wp-config.php, .env ці аналагічныя, не павінны быць даступныя для чытання ўсім. Таксама пераканайцеся, што схаваныя файлы, напрыклад .htaccess і .user.ini, былі скапіраваны.

Крок 3: Перанясіце базу даных

Перанос базы даных — самы адказны этап для прадухілення страты інфармацыі. Спачатку са старога сервера здымаецца дамп, затым на новым серверы ствараецца база даных і карыстальнік. Па магчымасці варта выкарыстоўваць кадзіроўку utf8mb4. Каб беларускія і рускія літары не ператварыліся ў “краказябры”, падчас экспарту і імпарту важна захаваць аднолькавую структуру параўнання (collation).

Для сайтаў, якія генеруюць даныя ў рэжыме рэальнага часу, такіх як WooCommerce ці сістэмы з рэгістрацыяй, падчас пераносу можна ўключыць рэжым абслугоўвання. Інакш падчас распаўсюджвання DNS частка карыстальнікаў будзе запісваць даныя на стары сервер, а частка — на новы. Гэта прывядзе да нестыкоўкі ў замовах, каментарах, заяўках ці рэгістрацыйных даных. На крытычна важных сайтах апошні дамп базы даных трэба рабіць ужо пасля ўключэння рэжыму абслугоўвання.

Крок 4: Абнавіце канфігурацыйныя файлы

Назву базы даных, імя карыстальніка, пароль, хост і шляхі да файлаў трэба прывесці ў адпаведнасць з новым серверам. Праверце wp-config.php для WordPress, .env для Laravel, config.php ці аналагічныя файлы для ўласных распрацовак. Калі застануцца абсалютныя шляхі, IP-адрасы, SMTP-налады ці дырэкторыі кэша старога сервера, сайт можа візуальна адкрывацца, але ў фонавым рэжыме будзе выдаваць памылкі.

Акрамя таго, значэнні PHP memory_limit, upload_max_filesize, post_max_size і max_execution_time павінны быць настроены ў адпаведнасці з патрэбамі вашай праграмы. Напрыклад, калі панэль кіравання дазваляе загружаць відарысы тавараў па 200 МБ, а ліміт загрузкі застанецца 32 МБ, то нават пасля паспяховага пераезду нармальная праца будзе немагчымай.

Крок 5: Пратэстуйце сайт перад зменай DNS

Самая бяспечная практыка — праверыць сайт на новым серверы да абнаўлення DNS. Для гэтага можна дадаць у файл hosts на вашым кампутары адпаведнасць вашага дамена і IP-адраса новага сервера. Такім чынам, пакуль наведвальнікі бачаць стары сервер, вы можаце тэставаць новы з вашым сапраўдным даменам.

Чэк-ліст тэставання павінен уключаць:

• Ці адкрываюцца галоўная, катэгорыі, карткі тавараў, блог і кантактная старонка?
• Ці працуюць адпраўка формаў, уваход, скід пароля і аплатны працэс?
• Ці загружаюцца выявы, CSS і JavaScript-файлы без страт?
• Ці адкрываецца панэль адміністравання без памылак?
• Ці ўсталяваны SSL-сертыфікат для правільнага дамена?
• Ці ёсць памылкі 404, 500, змешанага зместу (mixed content) ці зацыкліванне рэдырэктаў?
• Ці правільна настроены robots.txt, sitemap.xml і кананічныя тэгі?

Крок 6: Усталюйце SSL-сертыфікат

На сучасных сайтах SSL — гэта не толькі бяспека, але і абавязковая ўмова для SEO і даверу карыстальнікаў. Калі змяніць DNS без усталяванага на новым серверы SSL, наведвальнікі ўбачаць папярэджанне “Ваша злучэнне не абаронена”. Таму SSL-сертыфікат трэба падрыхтаваць адразу перад пераключэннем DNS ці адначасова з ім. Бясплатныя сертыфікаты накшталт Let’s Encrypt падыходзяць для большасці сайтаў, але для карпаратыўных праектаў з прыёмам плацяжоў лепш абраць SSL з больш высокім узроўнем праверкі.

Пасля ўсталявання SSL пераканайцеся, што HTTP-адрасы перанакіроўваюцца на HTTPS з кодам 301, няма памылак змешанага зместу, а ў карце сайта пазначаны HTTPS URL-адрасы. Для азнаямлення з SSL-прадуктамі і варыянтамі ўсталявання наведайце старонку Сертыфікаты SSL.

Крок 7: Змяніце DNS-запісы

Пасля паспяховага завяршэння тэстаў A-запіс у DNS накіроўваецца на IP-адрас новага сервера. Калі паштовы сэрвіс таксама пераязджае, трэба абнавіць запісы MX, SPF, DKIM і DMARC. Калі пошта застаецца ў іншага правайдэра, запісы MX чапаць нельга. Адна з самых распаўсюджаных памылак — выпадковая змена паштовых запісаў пры пераносе толькі вэб-сайта, што прыводзіць да прыпынку паштовага трафіку.

Распаўсюджванне DNS звычайна займае ад некалькіх хвілін да 24 гадзін. Калі TTL быў загадзя зніжаны, большасць карыстальнікаў хутка трапіць на новы сервер. У гэты час не спяшайцеся адключаць стары сервер. Бяспечнай практыкай з'яўляецца падтрыманне яго ў працоўным стане мінімум 48, а лепш 72 гадзіны.

Крок 8: Выканайце апошнюю сінхранізацыю і праверку логаў

Пасля змены DNS трэба праверыць, ці не былі запісаны новыя даныя на стары сервер. Асабліва гэта датычыцца замоваў, формаў зваротнай сувязі, рэгістрацый і каментароў. Файлы access log і error log вэб-сервера дапамогуць зразумець, якія IP-адрасы адпраўляюць запыты на які сервер.

На працягу першых 24 гадзін пасля пераезду трэба сачыць за памылкамі 500, ростам 404-х, павольнымі запытамі, скокамі CPU і паштовымі чэргамі. Калі гэтыя праверкі не выканаць, сайт можа выглядаць працуючым, але ў фонавым рэжыме будзе страчваць канверсіі.

Прафесійны чэк-ліст для пераносу сайта без страты даных

Прыведзены ніжэй чэк-ліст ахоплівае моманты, якія на практыцы выклікаюць больш за ўсё праблем. Калі адзначыць гэтыя пункты да і пасля міграцыі, рызыкі значна знізяцца.

• Час міграцыі запланаваны на гадзіны з нізкай наведвальнасцю.
• Зроблены поўны бэкап файлаў, базы даных, пошты і DNS.
• Праверана, што бэкап можна адкрыць і аднавіць.
• TTL DNS зніжаны як мінімум за 24 гадзіны да пераезду.
• На новым серверы падрыхтаваны PHP, база даных і неабходныя модулі.
• Файлы перанесены цалкам, правы доступу правераны.
• Праверана адпаведнасць кадзіроўкі і collation базы даных.
• Канфігурацыйныя файлы абноўлены ў адпаведнасці з данымі новага сервера.
• Праведзена тэставанне праз файл hosts да запуску ў працоўны рэжым.
• Усталяваны SSL, правераны перанакіраванні на HTTPS.
• Правільна абноўлены запісы DNS A, AAAA, MX, TXT.
• Стары сервер заставаўся актыўным не менш за 48 гадзін.
• Вялося назіранне за Google Search Console, Analytics і лог-файламі.

Праверкі пасля міграцыі, каб не страціць SEO

Тэарэтычна перанос сервера не павінен выклікаць страту пазіцый, калі структура URL не змянілася. Але на практыцы павольная праца, памылкі 404, няправільны robots.txt, адсутнасць SSL ці памылкі рэдырэктаў могуць паўплываць на рэйтынг. Таму SEO-праверка пасля пераезду гэтак жа важная, як і тэхнічная міграцыя.

Праверка URL і перанакіраванняў

Калі падчас пераезду вы не змяняеце структуру URL, патрэба ў 301 рэдырэктах мінімальная. Але калі адначасова змяняецца дамен, структура спасылак ці тэчкі, старыя URL трэба перанакіраваць на новыя з кодам 301. Часовы рэдырэкт 302 не падыходзіць для пастаяннай перадачы SEO-сігналаў. Напрыклад, калі старонка /produkt/abc пераехала на /kram/abc, трэба наладзіць пастаронкавае перанакіраванне; перанакіраванне ўсіх старых URL на галоўную дрэнна ўплывае на карыстальніцкі досвед і SEO.

Праверка robots.txt і Sitemap

Калі падчас тэставання для блакіроўкі пошукавых робатаў у robots.txt выкарыстоўваўся Disallow, пасля запуску яго трэба прыбраць. Гэта адна з самых класічных прычын страты індэксацыі. У файле карты сайта павінны быць пазначаны новыя HTTPS URL-адрасы, і яго трэба паўторна адправіць праз Google Search Console.

Прадукцыйнасць і Core Web Vitals

Нават калі новы сервер больш магутны, няправільныя налады кэша могуць знізіць прадукцыйнасць. Правільна наладзьце LiteSpeed Cache, Redis, OPcache, CDN і аптымізацыю відарысаў. На працягу першага тыдня пасля пераезду адсочвайце паказчыкі LCP, INP і CLS праз PageSpeed Insights, Chrome UX Report і логі сервера. Каб палепшыць прадукцыйнасць хостінгу, вы можаце азнаёміцца з матэрыяламі Аптымізацыя хуткасці WordPress.

На што звярнуць увагу пры пераносе пошты

Пры многіх пераездах вэб-файлы пераносяцца без праблем, а пра пошту забываюць. Калі ваша пошта захоўваецца на бягучым серверы, трэба перанесці паштовыя скрыні, паролі карыстальнікаў, перасылкі і фільтры. Сінхранізацыя IMAP — надзейны спосаб перамясціць лісты са старой скрыні ў новую.

У DNS запіс MX паказвае на паштовы сервер, SPF вызначае дазволеных адпраўнікоў, DKIM адказвае за подпіс, а DMARC — за палітыку дамена. Калі гэтыя запісы сканфігураваны няправільна, вашы лісты могуць трапляць у спам ці адхіляцца. Пасля пераезду адпраўце тэставыя паведамленні на Gmail, Outlook і карпаратыўныя акаўнты, а таксама праверце загалоўкі лістоў.

Самыя распаўсюджаныя памылкі пры пераносе сервера

Агульная рыса паспяховых міграцый — прадухіленне простых памылак загадзя. Вось спіс самых частых праблем:

• Перанос без стварэння бэкапу ці без яго тэставання.
• Змена IP без папярэдняга зніжэння TTL DNS.
• Адключэнне старога сервера да завяршэння распаўсюджвання DNS.
• Няправільны перанос кадзіроўкі базы даных і псаванне беларускіх/рускіх сімвалаў.
• Страта правілаў перанакіравання .htaccess ці nginx.
• Перанакіраванне HTTPS-трафіку на новы сервер без усталяванага SSL.
• Няправільнае абнаўленне паштовых запісаў MX і TXT.
• Пакіданне плагіна кэшавання са шляхамі старога сервера.
• Адсутнасць кантролю Search Console і логаў пасля міграцыі.

Асабліва для сайтаў з жывымі продажамі міграцыю варта праводзіць не ў пік працоўняй актыўнасці, а ў перыяд найменшага трафіку і аб'ёму замоваў. Для буйных інтэрнэт-крам планаванне тэхналагічнага акна на 15-30 хвілін дапамагае пазбегнуць нестыковак даных.

Калі варта звярнуцца па прафесійную дапамогу ў міграцыі?

Перанесці просты сайт-візітку ўручную цалкам магчыма; аднак у некаторых выпадках прафесійная падтрымка будзе таннейшай і больш надзейнай. Сюды адносяцца інтэрнэт-крамы з высокім штомесячным абаротам, кампаніі з вялікай колькасцю паштовых акаўнтаў, парталы на ўласным ПЗ, наведвальныя медыя-сайты і бізнесы, якія захоўваюць даныя пад рэгуляваннем.

Пры прафесійнай міграцыі працэс звычайна складаецца з этапаў: папярэдні аналіз, бэкап, наладка тэставага асяроддзя, перанос, пераключэнне DNS, праверка і маніторынг. Такім чынам, пераносіцца не толькі кантэнт, але і бесперабойнасць бізнесу. Калі вы плануеце перайсці на інфраструктуру Hostragons, наведайце старонку Hostragons рашэнні для хостынгу, каб ацаніць прыдатныя для вас варыянты хостінгу, даменаў і SSL.

Вынік: спланаваны перанос сервера прадухіляе прастоі і страту даных

Перанос сервера — гэта не страшна, калі ўсё правільна спланаваць. Ключ да поспеху: не прапускаць этапы поўнага бэкапу, карэктнай падрыхтоўкі сервера, плана DNS TTL, тэставага асяроддзя, усталявання SSL, праверкі пошты і пост-міграцыйнага маніторынгу. Асабліва для сайтаў з дынамічнай базай даных крытычную ролю адыгрываюць апошняя сінхранізацыя і рэжым абслугоўвання.

Карацей кажучы, каб перанесці сайт без страты даных, не спяшайцеся, правярайце кожны крок і не адключайце адразу стары сервер. Калі вы хочаце абнавіць інфраструктуру і прапанаваць больш хуткі і бяспечны вэб-досвед, вы можаце азнаёміцца з рашэннямі хостінгу, даменаў і SSL на Hostragons і спакойна, кантралявана скласці план пераходу, які адпавядае вашым патрэбам.

Часта задаваныя пытанні

Колькі часу займае перанос сервера?

Час залежыць ад памеру і складанасці сайта. Невялікі сайт на WordPress можна перанесці за 30-60 хвілін, у той час як для буйной інтэрнэт-крамы ці карпаратыўнага праекта з вялікай колькасцю пошты працэс з падрыхтоўкай, тэставаннем і распаўсюджваннем DNS можа заняць 1-3 дні.

Ці будзе мой сайт недаступны падчас пераносу?

Пры правільным планаванні прастой можна скараціць да некалькіх хвілін ці наогул зрабіць яго непрыкметным для карыстальнікаў. Для гэтага трэба загадзя знізіць TTL DNS, пратэставаць новы сервер да запуску і трымаць стары сервер уключаным да завяршэння распаўсюджвання DNS.

Які самы важны крок, каб пазбегнуць страты даных?

Самы важны крок — правераны поўны бэкап. Неабходна зрабіць копіі файлаў, базы даных, пошты і DNS-запісаў; асабліва для сайтаў, якія генеруюць замовы ці рэгістрацыі, апошні дамп базы даных трэба рабіць пасля ўключэння рэжыму абслугоўвання.

Ці паўплывае перанос сервера на пазіцыі ў SEO?

Калі захаваць структуру URL, забяспечыць хуткую працу, правільна наладзіць SSL і рэдырэкты, перанос сервера сам па сабе не выклікае страту SEO. Аднак памылкі 404, няправільны robots.txt, павольны сервер ці хібныя 301 рэдырэкты могуць негатыўна адбіцца на рэйтынгу.

Ці пераносяцца паштовыя акаўнты разам з серверам?

Калі пошта знаходзілася на старым хостінгу, яе трэба пераносіць асобна. Трэба праверыць паштовыя скрыні, перасылкі, фільтры і запісы MX, SPF, DKIM, DMARC. Калі пошта застаецца ў іншага правайдэра, запісы MX мяняць нельга.