Задача и границы решения
На собственном сервере легко изменить поставляемый код напрямую. Такая свобода может сделать следующее обновление дорогим и непредсказуемым.
Как подойти к задаче
Перед разработкой составьте карту существующих доработок. Используйте документированные расширения, модули и события, отделяя их от ядра. Зафиксируйте зависимости от редакции, PHP и сторонних компонентов.
Что проверить на практике
На копии портала проверьте затронутый процесс до и после обновления. Убедитесь, что права и фоновые задачи сохраняются. Для каждого изменения оставьте описание назначения и способ отключения.
Какой ошибки избежать
Ошибка — считать отсутствие конфликта файлов достаточной проверкой. Измениться может поведение API. Нужны сценарии работы пользователей и контроль журналов, а не только успешная установка обновления.
Пример для проверки на вашем проекте
Собственный обработчик запускается при изменении сущности и обращается к внешнему сервису. После обновления меняется поведение одного из используемых методов. Файлы не конфликтуют, но сценарий даёт неверный результат. Поэтому проверка обновляемости включает реальные входные данные и ожидания. Отсутствие прямой правки ядра облегчает сопровождение, но не заменяет тест поведения до публикации.
Работа с вашим окружением
До изменения коробочного портала проверяем версии, ресурсы, собственные доработки и фоновые задачи. Резервная копия включает файлы и БД. На тестовой копии отключаются реальные внешние действия. Состав работ определяется обнаруженной причиной и необходимыми ограничениями, а не предположением, что любой сбой решит обновление.
Публикация с возвратом
Согласуем время переключения и контроль последних изменений пользователей. После публикации проверяем доступность портала, ключевую работу с CRM и расписание. Старый рабочий вариант сохраняется до завершения наблюдения. Описание доработок и проверки помогает безопасно обслуживать систему следующему специалисту.