Коротко. Виртуальный хостинг — общий аккаунт на общем веб-сервере с жёсткими лимитами и без root. VPS (он же VDS) — отдельная виртуальная машина с root и гарантированными ресурсами. Выделенный сервер — физическое железо целиком. Облако — пул ресурсов с почасовой оплатой и API. Выбор определяют не абстрактный «объём трафика», а нужный уровень изоляции, наличие администратора и характер нагрузки.
Чем отличается хостинг от VPS: четыре типа и что за ними стоит
Разница между типами хостинга — не в цене и не в маркетинговых названиях тарифов, а в том, где проходит граница вашей ответственности и чем вы делитесь с другими клиентами. Ниже — что физически стоит за каждым вариантом.
Виртуальный (shared) хостинг
Ваш сайт — это каталог и системный пользователь на машине, где живут ещё десятки или сотни таких же аккаунтов. Веб-сервер (Apache, nginx, LiteSpeed), интерпретатор PHP, MySQL/MariaDB, почтовый и cron-демоны — общие, их версии и настройки задаёт хостер. Вы получаете панель управления, FTP/SFTP, иногда ограниченный SSH. Ядро, systemd, фаервол, порты — не ваши. Изоляция строится не на виртуализации, а на правах файловой системы, отдельных пулах PHP-FPM и лимитах ядра (на CloudLinux — механизм LVE).
VPS / VDS
Физический сервер нарезан на виртуальные машины. При аппаратной виртуализации (KVM) у каждой машины своё ядро, свой набор устройств и почти любая ОС на выбор. При контейнерной (OpenVZ, LXC, Virtuozzo) ядро одно на всех, а изоляция сделана средствами ядра — namespaces и cgroups. В обоих случаях у вас root, свой IP, свой набор сервисов и полная ответственность за обновления, бэкапы и безопасность.
Выделенный сервер
Физическая машина целиком: конкретные процессоры, планки памяти, диски и RAID-контроллер, IPMI/KVM-over-IP для доступа к консоли и перезагрузке. Соседей нет, гипервизора над вами тоже нет — производительность предсказуема, но отказавший диск или блок питания меняют руками, и это часы, а не секунды живой миграции.
Облако
Инстанс запускается в пуле гипервизоров поверх сетевого хранилища. Ресурсы (vCPU, RAM, диск, IP, трафик) тарифицируются по времени использования, машина создаётся и удаляется через API или Terraform, рядом доступны управляемые сервисы: базы данных, балансировщики, объектное хранилище, снапшоты. Ключевое отличие от VPS — не «мощнее», а эластичнее и программируемее.
| Критерий | Виртуальный хостинг | VPS / VDS | Выделенный сервер | Облако |
|---|---|---|---|---|
| Изоляция ресурсов | Слабая: лимиты поверх общих демонов | Средняя–высокая: KVM сильнее контейнера | Полная: железо ваше | Средняя–высокая, как у VPS, плюс сетевой диск |
| Кто администрирует ОС | Хостер | Вы (если тариф не managed) | Вы (провайдер — только железо и сеть) | Вы; часть сервисов может быть managed |
| Root-доступ | Нет | Есть | Есть, плюс BIOS/IPMI | Есть |
| Масштабирование | Смена тарифа, потолок низкий | Ресайз с перезагрузкой, потолок — физическая нода | Апгрейд железа, миграция на новую машину | Вертикально и горизонтально, за минуты, через API |
| Типичный порог, после которого становится тесно | Динамика на десятки тысяч визитов в месяц, всплески больно бьют | Сотни тысяч визитов при нормальном кэше | Постоянная тяжёлая нагрузка 24/7, крупные БД | Неравномерная нагрузка и требования к отказоустойчивости |
| Главные риски | Шумные соседи, скрытые лимиты, общая репутация IP | Overselling, steal time, вы сами отвечаете за безопасность | Одна точка отказа, время замены железа, простой при апгрейде | Неконтролируемый счёт, платный трафик и IOPS, привязка к API провайдера |
Виртуальный хостинг простыми словами: лимиты и «шумные соседи»
Виртуальный хостинг — это аренда доли вычислительных ресурсов, а не самих ресурсов. Модель работает, пока средняя нагрузка аккаунтов невелика и всплески не совпадают. Чтобы один клиент не утопил ноду, хостер накладывает лимиты, о которых чаще всего узнают уже по авариям.
- Иноды (inode) — счётчик файлов, а не гигабайт. Кэш шаблонов, тысячи миниатюр, папка сессий и старые бэкапы легко выбирают квоту при формально свободном месте. Симптом: «нет места» при 30–40 % занятого объёма.
- CPU-время — процент ядра или CPU-секунды. При превышении процессы не убивают, а притормаживают: страница, которая рендерилась 200 мс, начинает отвечать секундами.
- Число процессов и одновременных запросов (NPROC, entry processes). Когда лимит выбран, лишние запросы получают ошибку вместо ответа — на CloudLinux это характерная
508 Resource Limit Is Reached. - Оперативная память на аккаунт — обрывает импорт каталога, генерацию фида, сборку архива.
- Ограничения PHP:
max_execution_time,memory_limit,max_input_vars, размер загружаемого файла. Именно они рвут дампы, миграции и длинные обработчики. - Ввод-вывод и IOPS. Здесь и живут «шумные соседи»: чужой кривой плагин, который пишет мегабайты логов, портит время ответа всем на ноде.
Как понять, что вы упёрлись, а не «сайт просто тяжёлый»: время ответа плавает в разы при одном и том же коде, ошибки 5xx и 508 появляются в часы пик, cron не успевает отработать, бэкап падает по таймауту, а панель показывает упирающийся в потолок график CPU или процессов.
# Виртуальный хостинг: во что упирается аккаунт
df -h . # объём
df -i . # ИНОДЫ: кончаются раньше гигабайт
find . -xdev -type f | wc -l # сколько файлов реально создано
ulimit -u # лимит числа процессов пользователя
ulimit -n # лимит открытых файлов
# Лимиты PHP, из-за которых падают импорт, бэкап и дамп
php -r 'foreach (["max_execution_time","memory_limit","max_input_vars",
"post_max_size","upload_max_filesize"] as $k)
printf("%s = %s\n", $k, ini_get($k));'
# Куда уходит время ответа (запускать с вашего компьютера)
curl -o /dev/null -s -w \
'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
https://example.com/Нестабильный TTFB — более честный сигнал, чем средний. Если один и тот же URL отвечает то за 200 мс, то за 2 с без изменений в коде и без роста трафика, вы делите ресурс с кем-то ещё, и переезд решит проблему быстрее, чем оптимизация запросов.
Отдельный побочный эффект общей площадки — общий IP-адрес. Репутация этого IP в почтовых и антиспам-системах складывается из поведения всех соседей, поэтому письма с shared-хостинга доставляются менее предсказуемо. Про диагностику причин медленной отдачи есть отдельный разбор: почему сайт долго грузится и что с этим делать.
VPS или VDS: в чём разница и на что смотреть вместо аббревиатуры
Короткий ответ: в российской рознице VPS и VDS — маркетинговые синонимы, и выбирать «что лучше» по буквам бессмысленно. Исторический смысл был: VDS (virtual dedicated server) продавали как машину на аппаратной виртуализации с собственным ядром, VPS (virtual private server) — как контейнер с общим ядром хоста. Сегодня один и тот же провайдер может называть KVM-машину «VPS», а контейнер — «VDS», и наоборот.
Смотреть нужно на технические параметры, а не на название тарифа.
Тип виртуализации
KVM — полноценная виртуальная машина: своё ядро, свои модули (можно поднять свой firewall, VPN, докер с нужными возможностями), свой swap, установка любой ОС из ISO, предсказуемое поведение. OpenVZ/LXC/Virtuozzo — контейнер: ядро общее с хостом, свои модули не загрузить, ядро не обновить, часть счётчиков в /proc показывает хост, а не вас. Контейнеры дешевле и плотнее упаковываются, и именно на них чаще встречается переподписка.
Выделенное ядро или переподписанное
«2 vCPU» ничего не говорят о том, сколько виртуальных ядер провайдер посадил на одно физическое. Реальный индикатор — steal time: доля времени, когда ваша машина была готова считать, но гипервизор отдал такт другому. Стабильные единицы процентов терпимы, стабильные десятки означают, что вы платите за чужую нагрузку.
Память, диск и сеть
Проверяйте, гарантирована ли память или заявлена «до» (burst), есть ли swap, какой тип диска (NVMe, SSD, HDD) и есть ли лимит IOPS и полосы. Дешёвый тариф с сетевым диском и жёстким лимитом IOPS может оказаться медленнее старого shared-хостинга на локальном NVMe. Отдельно уточняйте скорость порта, лимит трафика и его стоимость после лимита, наличие снапшотов и бэкапов, возможность добавить IP.
# Что за машина под вами: гипервизор, контейнер или железо
systemd-detect-virt # kvm / lxc / openvz / none (none = bare metal)
lscpu | grep -E 'Model name|^CPU\(s\)|Hypervisor vendor|Virtualization'
uname -r # в контейнере это ядро ХОСТА, вы его не меняете
ls /proc/user_beancounters # файл есть -> OpenVZ/Virtuozzo-контейнер
# Реально ли ядро ваше: колонка st (steal time) = время, отданное соседям
vmstat 1 5
# Память и swap: в контейнерах swap часто отсутствует или общий
free -m
swapon --show
# Диск: последовательное чтение и задержки
lsblk -d -o NAME,ROTA,SIZE,MODEL # ROTA=1 -> HDD, 0 -> SSD/NVMeПроверяйте виртуализацию и steal time на тестовый период, а не по описанию тарифа. Переезд с контейнера на KVM внутри одного провайдера — это почти всегда новая машина и повторная миграция данных, так что дешевле выяснить всё до боевого запуска.
Готовый разбор критериев и типовых конфигураций есть в подборке лучших провайдеров VPS, а логику выбора уровня — в статье как выбрать хостинг для сайта.
Аренда выделенного сервера: когда это оправдано, а когда переплата
Выделенный сервер решает три класса задач, которые виртуализация закрывает плохо.
- Лицензии и требования, привязанные к железу. Часть коммерческого ПО лицензируется по физическим ядрам, сокетам или требует стабильного идентификатора машины. На виртуалке это либо дороже, либо формально нарушает условия.
- Специфичное железо. GPU для инференса и обработки видео, много локальных NVMe в RAID, большой объём RAM под базу целиком в памяти, аппаратные ключи и платы расширения.
- Требования к изоляции. Когда регламент или договор запрещают делить хост с чужими нагрузками — обработка чувствительных персональных данных, требования аттестации, отдельные банковские и платёжные сценарии.
Плюс к этому есть экономический сценарий: постоянная тяжёлая нагрузка 24/7. Если машина утилизирована ровно и круглосуточно, фиксированная аренда железа обычно дешевле эквивалентного облака.
Когда выделенный сервер — переплата: нагрузка пиковая и редкая; нужен быстрый ресайз под акцию или сезон; нет системного администратора; критична высокая доступность. Последнее важно: одна физическая машина — это одна точка отказа. Живой миграции на другую ноду, как в облаке, у вас нет; отказ диска, памяти или блока питания означает работу инженера в стойке. Отказоустойчивость на выделенных серверах строится не «мощнее», а «две машины и балансировщик», и это сразу удваивает бюджет.
RAID — не бэкап. Он спасает от отказа диска, но не от DROP TABLE, шифровальщика и ошибки деплоя. На выделенном сервере обязательна выгрузка копий на внешнее хранилище и регулярная проверка восстановления.
Облачный хостинг: пул ресурсов, почасовая оплата и когда он дороже VPS
Облако продаёт не машину, а возможность в любой момент получить и вернуть ресурс. Отсюда его сильные стороны: создание и удаление инстансов через API и инфраструктуру-как-код, снапшоты и клоны окружений, автоматическое масштабирование под нагрузку, управляемые базы данных с репликацией и бэкапами, балансировщики, объектное хранилище под статику и бэкапы, сеть между сервисами внутри одного проекта.
Облако выигрывает, когда нагрузка неравномерна (сезон, распродажа, рекламная кампания), когда нужны одноразовые окружения под тесты и релизы, когда требуется отказоустойчивость из нескольких зон, когда команда работает через CI/CD и не хочет вручную настраивать серверы.
Облако проигрывает по деньгам, когда нагрузка ровная и предсказуемая. Постоянно включённый инстанс по часовому тарифу обычно дороже эквивалентного VPS или выделенного сервера с фиксированной ценой. Добавьте к этому платный исходящий трафик, отдельную тарификацию снапшотов, публичных IP и повышенных IOPS, наценку на managed-сервисы и классическую утечку бюджета — забытые тестовые инстансы, неудалённые диски и снапшоты. Ещё одна цена — привязка к API конкретного провайдера: чем глубже вы используете его управляемые сервисы, тем дороже переезд.
Российский рынок закрывает все четыре сценария: есть классические shared-хостеры, провайдеры VPS и полноценные облака с API и managed-сервисами — в этой категории работают, например, Selectel и другие крупные операторы дата-центров. Сравнение вариантов по задачам — в обзоре хостинг-провайдеров.
Кто администрирует ОС: managed, unmanaged и панели управления сервером
Это вопрос, который чаще всего недооценивают при переезде с shared-хостинга. На виртуальном хостинге операционную систему администрирует хостер: он обновляет пакеты, следит за демонами, чинит ноду. На VPS, выделенном сервере и в облаке по умолчанию действует модель unmanaged: провайдер отвечает за железо, сеть, гипервизор и доступность порта, а всё внутри ОС — ваше. Обновления безопасности, фаервол, SSH-политика, TLS-сертификаты, тюнинг nginx и БД, мониторинг, бэкапы и разбор инцидентов — тоже ваши.
Managed — платная услуга администрирования поверх той же машины. Перед подключением стоит выяснить четыре вещи: что именно входит в услугу (только ОС или ещё веб-сервер, БД и приложение), остаётся ли у вас root, каково время реакции по SLA и кто отвечает за последствия взлома, если уязвимость была в непропатченном пакете. Формулировка «администрирование включено» без этих деталей ничего не гарантирует.
Панели управления: зачем и какова цена в ресурсах
Панель (cPanel, Plesk, ISPmanager, FastPanel, HestiaCP, aaPanel и подобные) даёт графический интерфейс для типовых операций: сайты и виртуальные хосты, почтовые ящики, базы, DNS-зоны, сертификаты, FTP-доступы, бэкапы, несколько версий PHP рядом. Это оправдано, когда сайтов много, нужна почта на своём домене, а обслуживать сервер будет не системный администратор.
Цена вопроса тоже конкретная:
- Панель приносит свой стек — часто связку nginx+Apache, собственные сборки PHP, свою базу для настроек, агента мониторинга. Это заметный расход RAM и диска, что чувствительно на младших тарифах VPS.
- Панель — это дополнительная точка входа: собственный веб-интерфейс на нестандартном порту, свои пользователи и своя история уязвимостей. Её нужно закрывать фаерволом или доступом по списку IP, включать двухфакторную аутентификацию и обновлять отдельно.
- Панель управляет конфигурацией. Правки конфигов руками она может перетереть при обновлении, поэтому менять настройки нужно через её механизмы шаблонов, а не напрямую.
- Лицензирование различается: часть панелей коммерческие, с оплатой за сервер или за число аккаунтов, часть — бесплатные с платными дополнениями. Бесплатная панель на дешёвом VPS иногда экономит больше, чем стоит.
Альтернатива для одного проекта с инженером в команде — сервер без панели: конфиги в репозитории, развёртывание через Ansible или контейнеры, сертификаты через ACME-клиент по расписанию. Меньше потребление, меньше поверхность атаки, но нужен человек, который это поддержит.
Локация и юрисдикция — коротко
Три практических соображения: сетевая задержка до вашей аудитории (для России это десятки миллисекунд разницы между Москвой и Европой), требования законодательства к месту хранения персональных данных и устойчивость сервиса к внешним ограничениям — блокировкам, отказу в обслуживании, проблемам с оплатой. Детально этот выбор разобран в отдельном материале про провайдеров и площадки размещения.
Как понять, что пора переезжать, и как перевезти сайт без даунтайма
Признаки, что вы переросли текущий тариф
- TTFB на закэшированной странице стабильно держится в районе секунды и выше, а оптимизация кода и кэша даёт всё меньший эффект.
- В часы пик и во время рекламных кампаний появляются ошибки 502, 503 и 508, а после спада нагрузки всё «само чинится».
- Панель или письма хостера сообщают о превышении лимитов CPU, процессов или инодов.
- Бэкап и восстановление занимают часы, дамп базы обрывается по таймауту, а выгрузить файлы одним архивом уже невозможно.
- Проекту нужны вещи, которых на shared нет по определению: собственный демон или очередь, Redis, поиск, Node.js или Python-процесс, контейнеры, cron чаще чем раз в 15 минут, WebSocket, конкретная версия библиотеки, доступ к системным логам.
- База выросла до нескольких гигабайт, и тяжёлые запросы конкурируют с чужими на общем сервере СУБД.
Один-два пункта — повод оптимизировать. Три и больше — повод переезжать: дальше вы будете платить временем разработчика за обход чужих ограничений.
Чеклист переезда без даунтайма
- Инвентаризация. Домены и все DNS-записи (A, AAAA, CNAME, MX, TXT со SPF и DMARC, DKIM-селекторы), почтовые ящики, cron-задачи, сертификаты, внешние сервисы, у которых ваш IP прописан в белом списке, вебхуки платёжных систем и CRM.
- TTL заранее. За 24–48 часов до переключения снизьте TTL записей A/AAAA (и MX, если переносите почту) до 300 секунд. Снижение вступит в силу не мгновенно, а после истечения старого TTL — поэтому «заранее», а не в день переезда.
- Параллельный запуск. Поднимите сайт на новом сервере полностью и проверьте его по боевому домену без изменения DNS — через
curl --resolveили локальный hosts. Проверяйте не главную, а формы, авторизацию, оплату, загрузку файлов и админку. - SSL до переключения. Сертификат должен быть выпущен и установлен на новом сервере заранее. Если валидация идёт по HTTP, а трафик пока на старом сервере, используйте DNS-валидацию или скопируйте существующий сертификат и ключ. Иначе первые минуты после переключения посетители увидят ошибку сертификата.
- Данные в два прохода. Сначала полная синхронизация файлов и дамп базы, затем короткое технологическое окно: включить режим обслуживания, догнать дельту
rsync, снять финальный дамп, залить. - Почта. Ящики переносятся отдельно и обычно дольше сайта: синхронизируйте их через IMAP, а MX переключайте отдельным шагом. Часть писем в момент смены MX уйдёт на старый сервер — держите его принимающим ещё несколько суток.
- Переключение и параллельная работа. Меняете A-запись. Старый сервер не выключаете 48–72 часа: часть резолверов и провайдеров подтянет новый адрес с задержкой. На старом сервере лучше поставить режим «только чтение» или редирект, чтобы заказы не падали в две базы.
- После переезда. Верните TTL к нормальному значению, проверьте редиректы и коды ответа, наличие сайта под всеми доменами и с www, отзовите доступы к старому серверу, обновите белые списки IP у внешних сервисов и включите мониторинг доступности.
Не переключайте DNS в пятницу вечером и не совмещайте переезд с релизом. Если что-то пойдёт не так, вам понадобится возможность вернуть A-запись обратно — а это работает только тогда, когда старый сервер жив и отдаёт актуальные данные.
# 1. За 24-48 часов до переезда снижаем TTL (сначала смотрим текущий)
dig +noall +answer example.com A # вторая колонка вывода - оставшийся TTL
dig +noall +answer example.com MX
# 2. Копируем файлы на новый сервер, права и атрибуты сохраняем
rsync -aHAX --numeric-ids --delete -e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 3. База: согласованный дамп без длинной блокировки таблиц (InnoDB)
mysqldump --single-transaction --quick --routines --events --triggers mydb \
| gzip -1 > /backup/mydb.sql.gz
# 4. Проверяем НОВЫЙ сервер по старому домену, не трогая DNS
curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -20
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -c '</html>'
# 5. Почта: синхронизация ящиков между старым и новым IMAP
imapsync --host1 old.example.com --user1 box@example.com \
--host2 new.example.com --user2 box@example.com --dry
# 6. После переключения смотрим, кто ещё стучится в старый сервер
tail -f /var/log/nginx/access.logПошаговый план со всеми проверками и типовыми ошибками собран в материале чеклист переноса сайта, а привязка домена к новой площадке — в инструкции как подключить домен к хостингу.
Как проверить: TTFB, текущий хостинг и стек сайта
Прежде чем менять тариф, соберите факты — часто оказывается, что виноват не хостинг, а конкретный запрос или отсутствие кэша.
- Замерить время ответа и скорость — проверка скорости сайта: TTFB, полное время загрузки и вес страницы. Замеряйте один и тот же URL в разное время суток: важен разброс, а не одно значение.
- Узнать текущий хостинг и IP — определение IP-адреса и WHOIS: кому принадлежит адрес, в какой автономной системе и стране он находится. Отдельный разбор — в статье как узнать хостинг и IP сайта.
- Определить стек — определение технологий сайта: веб-сервер, CMS, версия PHP, наличие CDN и кэширующего слоя. Это подсказывает, где узкое место и что придётся перенести.
- Следить за доступностью после переезда — мониторинг доступности: проверки с интервалом и уведомления, чтобы падение нового сервера не обнаружилось через сутки от клиента.
- Проверить сертификат на новом сервере — проверка SSL сразу после переключения DNS, включая цепочку и срок действия.
Частые вопросы
Чем виртуальный хостинг отличается от VPS?
На виртуальном хостинге вы арендуете аккаунт на общем сервере: ОС и демоны настраивает хостер, root у вас нет, ресурсы ограничены квотами и делятся с соседями. VPS — это отдельная виртуальная машина с собственной ОС, root-доступом и выделенными ресурсами; взамен вы полностью отвечаете за её обновление, защиту и бэкапы.
VPS или VDS — что лучше?
Это не выбор: у большинства российских провайдеров термины взаимозаменяемы. Смотрите на характеристики: тип виртуализации (KVM против контейнера), гарантированные, а не «до», память и ядра, тип и лимиты диска, стоимость трафика, наличие снапшотов. Аббревиатура в названии тарифа ничего не гарантирует.
Сколько трафика выдержит виртуальный хостинг?
Правильнее считать не визиты, а одновременные запросы к динамике. Статика и закэшированные страницы отдаются дёшево, а вот два-три десятка параллельных обращений к некэшированному PHP уже упираются в лимит процессов на типовом тарифе. Сайт с полноценным кэшем переживает всплеск, который положит такой же сайт без кэша.
Нужен ли интернет-магазину выделенный сервер?
Обычно нет. Большинство магазинов до нескольких тысяч заказов в месяц спокойно живут на VPS с нормальным кэшем и вынесенной в CDN статикой. Выделенный сервер нужен, когда упираетесь в диск и память под базу, есть лицензионные требования к железу или регламент запрещает делить хост.
Что дешевле — VPS или облако?
При ровной круглосуточной нагрузке дешевле фиксированный VPS. Облако выгоднее, когда нагрузка неравномерна, когда окружения создаются и удаляются, когда нужна отказоустойчивость из коробки. Считайте не только инстанс, но и трафик, снапшоты, диски и управляемые сервисы — счёт складывается из них.
Обязательно ли ставить панель управления на VPS?
Нет. Панель оправдана, если сайтов несколько, нужна почта и обслуживать сервер будет не администратор. Для одного проекта с инженером в команде сервер без панели потребляет меньше ресурсов и даёт меньшую поверхность атаки, но требует навыков и автоматизации.
Чеклист: выбор типа хостинга и переезд
- Сформулировать требования: root, свои демоны, версии ПО, изоляция, требования к данным.
- Замерить текущее состояние: TTFB в разное время суток, доля 5xx, упор в иноды и CPU-лимиты.
- Проверить, исчерпаны ли дешёвые меры: кэш, оптимизация запросов, вынос статики.
- Для VPS уточнить: KVM или контейнер, гарантированные ресурсы, тип диска и лимит IOPS, стоимость трафика.
- Проверить steal time и диск на тестовом периоде до боевого запуска.
- Решить вопрос администрирования: свой инженер, managed-услуга или панель — и заложить их в бюджет.
- Проверить, нужна ли панель, и если да — закрыть её порт фаерволом и включить двухфакторную аутентификацию.
- За 24–48 часов до переезда снизить TTL записей A/AAAA.
- Поднять и протестировать новый сервер по боевому домену через
curl --resolve. - Выпустить и установить SSL до переключения DNS.
- Перенести почту отдельно, MX переключать отдельным шагом.
- Держать старый сервер живым 48–72 часа после смены DNS.
- После переезда вернуть TTL, проверить редиректы и включить мониторинг доступности.
- Настроить внешние бэкапы и проверить восстановление, а не только создание копии.