Сайт может годами выполнять свою задачу, хотя никто уже не помнит, как его развернуть заново. На сервере остаются неподдерживаемые компоненты, неизвестные задания и ручные исправления. Владелец замечает проблему, когда очередное обновление становится опасным или прежний исполнитель перестаёт отвечать.
Начинать модернизацию с одновременной замены сервера, CMS и интеграций рискованно. При ошибке будет трудно определить причину и сохранить новые данные. Лучше разделить работы на этапы с собственным результатом, проверкой и возможностью возврата. Такой подход подходит и небольшому сайту, и магазину с несколькими внешними системами.
Верните управление ресурсами
Проверьте домен, DNS, хостинг, репозиторий, почту и учётные записи интеграций. Уточните, кто может восстановить доступ без прежнего разработчика. Выдайте персональные права команде, которая будет выполнять работы. Секреты храните защищённо, а в схеме укажите, где их получить.
Сразу зафиксируйте ближайшие сроки: окончание регистрации домена, сертификата, лицензий и оплаченного размещения. Эти события могут прервать модернизацию независимо от качества кода. Если доступов нет, включите их восстановление в первый этап и не обещайте техническое переключение к дате, которую пока нечем обеспечить.
Опишите текущее состояние
Соберите версии ОС, PHP, базы, CMS, модулей и расширений. Отдельно перечислите пользовательские файлы, задания, очереди и внешние API. Проверьте фактическую конфигурацию, а не только старую документацию. Веб-запросы и команды планировщика иногда используют разные версии PHP или разные файлы настроек.
Запишите важные сценарии: вход, редактирование, поиск, отправка заявки, заказ и обмен данными. Для каждого нужен ожидаемый результат. Сохраните примеры ошибок и исходные измерения производительности. Этот набор позволит сравнивать этапы модернизации и замечать, что исправление одного участка нарушило другой.
Проверьте возможность восстановления
До рискованных изменений подготовьте согласованную копию данных и восстановите её в отдельной среде. Проверьте доступность архива, ключей и конфигурации при потере рабочего сервера. Если для запуска приходится забирать забытые файлы с production, внесите их в процедуру и повторите тест.
Уточните, какие изменения появляются во время работ: заказы, заявки, загрузки и обмены. Восстановление старой базы поверх живого магазина может удалить новые записи. Поэтому план возврата должен учитывать данные, а не только файлы приложения. Подробная подготовка описана в проверке резервных копий.
Отделите срочные риски от улучшений
Истекающий сертификат, открытая административная панель и подтверждённая уязвимость требуют отдельного рассмотрения. Не откладывайте их только потому, что впереди большой переезд. Но и не меняйте всё без проверки: временное ограничение может быть безопаснее немедленного обновления несовместимого модуля.
Для каждого замечания определите последствия, подтверждение и ближайшее действие. Изменение внешнего вида обычно можно планировать позже, чем восстановление потерянного доступа к копиям. Приоритеты согласуются с владельцем, поскольку техническая серьёзность и влияние на работу проекта не всегда совпадают.
Постройте маршрут совместимости
Уточните, какие версии компонентов поддерживаются приложением и его расширениями. Иногда сначала нужно заменить заброшенный плагин, затем обновить CMS и только после этого переключить PHP. Для базы также проверяют расширения, кодировки, режимы и собственные запросы. Универсальная команда обновления всего проекта здесь не подходит.
Ориентируйтесь на документацию конкретных продуктов и проверку на копии. Не считайте отсутствие видимой ошибки на главной доказательством совместимости. Пройдите редактор, формы, фоновые задачи и интеграции. Отдельные особенности смены окружения разобраны в материале об обновлении PHP.
Выполняйте небольшие завершённые этапы
Для каждого этапа запишите исходное состояние, изменения, критерий приёмки и способ отмены. Например: подготовить новый сервер без переключения пользователей; обновить библиотеку на тестовой среде; перевести почтовую отправку и проверить доставку. Размер этапа должен позволять понять результат.
Если требуется перенос, заранее проверьте сайт под рабочим именем в новой среде. Учтите DNS, сертификаты, запись новых данных и запуск планировщика только на нужной стороне. Порядок переключения приведён в плане переноса сайта. Не используйте переезд как повод одновременно менять каждую технологию без отдельной необходимости.
Завершите модернизацию рабочим процессом
После переключения настройте мониторинг, резервное копирование и регулярные проверки уже для новой конфигурации. Удаление старой среды планируйте после контроля остаточного трафика, данных и зависимостей. Зафиксируйте новые адреса, версии, доступы и порядок публикации.
Итогом должен быть проект, который можно обслуживать без повторного обследования перед каждой задачей. Оставшиеся ограничения внесите в список работ с ответственными. Повторите ключевые сценарии после периода обычной нагрузки: некоторые ошибки проявляются только во время импорта, ночного задания или очередной отправки уведомлений.
Сохраните перечень временных ограничений после каждого этапа. Например, старый модуль ещё работает, но его замена запланирована; доступ к нему ограничен, а резервирование проверено. Такая запись позволяет продолжить работу другому специалисту и не принять промежуточное состояние за окончательное решение. Для оставленных рисков нужны ответственный и повод вернуться к вопросу.
Если вашему сайту требуется поэтапное обновление, обратитесь в HOMEWEB. Укажите CMS, возраст окружения, известные проблемы и доступные сведения о сервере — обсудим обследование и безопасную последовательность работ.
