ПЛАНИРУЙТЕ ПЕРИОД Экономьте 28% на 6 месяцев · 50% на 12 месяцев · оплата заранее.
Миграция и запуск

Планируйте клиентскую миграцию с учётом последней записи.

Миграция клиента готова, когда вы можете объяснить, какая система владеет текущими данными, доказать работоспособность назначения и безопасно остановиться при провале критической проверки. Начните с письменной описи и репетиции. Выбирайте окно изменений только после того, как агентство и клиент согласовали, кто утверждает перенос, что должно продолжать работать и как будут защищены новые обращения.

Проведите инвентаризацию проекта до назначения переноса

Используйте иллюстративный сайт запросов по адресу client.example.com: редакторы публикуют страницы проекта, посетители загружают бриф, а запланированная задача экспортирует запросы в систему клиента. Перенос только публичных страниц охватил бы лишь часть работы. Подтвердите авторизованный доступ к источнику и назначению, управление доменом и копии восстановления, прежде чем назначать дату.

Для каждого компонента запишите его владельца, версию, расположение, зависимости и проверку приёмки. Храните расположения учётных данных в описи; храните пароли и закрытые ключи в утверждённом хранилище секретов.

Прокрутите по горизонтали, чтобы увидеть все столбцы таблицы.

Начальная опись для иллюстративного сайта запросов
КомпонентЗафиксируйте перед переносомКто подтверждает
Домен и DNSРегистратор, оператор DNS, текущие записи и TTLВладелец аккаунта клиента
ПриложениеРелиз, среда выполнения, расширения и способ развёртыванияСопровождающий агентства
Данные и загрузкиБаза данных, пути загрузок, способ резервного копирования и последняя пригодная копияОператор данных
Формы и интеграцииПолучатели, конечные точки вебхуков и разрешённое тестовое назначениеВладелец рабочего процесса клиента
Запланированная работаCron или планировщик, часовой пояс, очередь и последний успешный запускСопровождающий агентства

Докажите работоспособность копии восстановления до касания продакшена

Восстанавливайте в отдельное тестовое назначение, никогда поверх рабочей базы данных. Для PostgreSQL дамп SQL представляет согласованный снимок базы данных, но дамп одной базы данных не включает обще кластерные роли или табличные пространства. Запишите вспомогательные объекты, требуемые вашим приложением. Этот снимок базы данных также не делает автоматически согласованными отдельно скопированные загрузки. Документация по дампу SQL в PostgreSQL.

Для проекта WordPress включите его файлы и базу данных. Если URL изменятся, следуйте его руководству по миграции: неизбирательная замена по базе данных может повредить сериализованные значения. Отрепетируйте выбранный метод на копии. Руководство по миграции WordPress.

Запишите известный запрос и его вложение, восстановите их и проверьте оба через приложение. Храните исходную резервную копию защищённой вне перемещаемого сервера. Завершённая передача файлов не является приёмкой восстановления.

Отрепетируйте процессы, которые заметит клиент

Тестируйте с использованием временного имени хоста с контролем доступа или сопоставления имён только для оператора. Настройте приложение для этого тестового маршрута, включая HTTPS и соответствующие URL обратного вызова. Не допускайте, чтобы копия отправляла продакшен-сообщения, обрабатывала реальные платежи или запускала продакшен-расписания. Используйте одобренные синтетические записи вместо ненужных персональных данных.

Запишите ожидаемый результат перед каждой проверкой. Фиксируйте пройдено или не пройдено, место доказательства и человека, который его проверил; скриншот главной страницы не может заменить всю сетку.

Прокрутите по горизонтали, чтобы увидеть все столбцы таблицы.

Сетка приёмки репетиции
Рабочий процессОжидаемый результатДоказательства для сохранения
Форма и вложениеОдин сохранённый запрос и один читаемый файл; только тестовый получательИдентификатор синтетической записи и наблюдение доставки
ВебхукОдобренное тестовое событие достигает предполагаемого тестового потребителяИдентификатор события и результат у потребителя
Запланированный экспортОдин контролируемый запуск, правильный часовой пояс, без дублирования на старом сервереИдентификатор запуска и сравнение экспортированных записей
Маршруты редактора и посетителяОжидаемые права, перенаправления, ресурсы и поведение HTTPSПроверенные URL и любые сведения о сбоях

Определите последнюю запись в старой системе

В этом примере агентство предлагает короткое окно обслуживания: приостановить отправку запросов и редактирование, остановить старое расписание экспорта, завершить или учесть работу в очереди, затем создать окончательный снимок базы данных и копию загрузок. Клиент должен одобрить, как посетителям сообщат, что отправка временно недоступна.

Запишите идентификатор последнего принятого запроса и время остановки записей. Проверьте, что назначение включает эту запись и её вложение, прежде чем разрешать новые отправки. Не позволяйте источнику принимать независимые записи, пока ответы DNS могут различаться. Проект, который не может приостановить записи, требует специфичного для приложения проекта синхронизации; не импровизируйте с ним во время переключения.

Ведите журнал решений по DNS

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

Записывайте имя и тип записи, старое значение, предполагаемое значение, прежний TTL, одобрение, время изменения и наблюдаемый результат. Проверяйте записи IPv6, а также записи IPv4, если существуют обе. Сохраняйте несвязанные почтовые записи. После изменения убедитесь, что публичное имя хоста достигает предполагаемого приложения и его критического рабочего процесса, а не только предполагаемого IP-адреса.

Сделайте откат решением о данных

Согласуйте конкретные условия остановки: последний запрос отсутствует, вложения не открываются, вход не выполняется или вебхук достигает неверного получателя. До начала новых записей возможен отрепетированный возврат к сохранённому источнику. После того как назначение принимает новые запросы, восстановление старой резервной копии или только обратное изменение DNS может привести к потере этих записей.

Если условие остановки появляется после возобновления, приостановите записи, сохраните обе копии и поручите назначенному оператору согласовать изменения, прежде чем выбирать авторитетную систему. Утверждающий со стороны клиента решает, продолжать восстановление или использовать согласованную альтернативу. Ведите короткий журнал инцидента вместо многократного переключения DNS.

Закройте перенос с доказательствами и ответственностью

Попросите клиента проверить сетку приёмки. Подтвердите один активный планировщик, новый путь резервного копирования, ответственность за оповещения и следующую контрольную точку наблюдения. Сохраняйте источник в течение согласованного периода, затем явно утвердите его вывод из эксплуатации. Удалите временный доступ и тестовые данные в соответствии с соглашением по проекту.

Используйте результат для обновления листа операционной ответственности и бюджета проекта. Эта процедура организует работу вашей команды; она не подразумевает включённую помощь с миграцией или бесперебойный сервис.

Источники и проверка

Технические ссылки были проверены 12 сентября 2026 года. Примеры являются планировочными упражнениями; документация упомянутого программного обеспечения не подтверждает возможности услуг PrivateHostLab.

ХОРОШЕЕ МЕСТО ДЛЯ СТАРТА

Освободите место для вашего следующего проекта.

Найдите свою отправную точку