когда до обновления ядра битрикс сайт работал без ошибок

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

Да, риски при обновлении если клиент не знает свой сайт хорошо, очень-очень велики.
Если клиент работает не постоянно с каким-то разработчиком, а обращается к стороннему за какой-то конкретной задачей, в частности за обновлением, то с огромной долей вероятности риск огромен. Почему: клиент сказал хочу так и все, разработчик не может аргументировать почему не надо делать такую задачу, в итоге в ядре могут появится свои дописки или использование каких-то старых функций, классов. Когда идет обращение за обновлением об этом неизвестно. вот и получается, что с обновлением полсайта перестает работать. Логично когда после этого клиент начинает ругаться. Но это не только касается обновления ядра. Это так же касается и переверстки разделов. Клиент не знает внутренностей как сейчас и говорит я хочу увидеть чтобы это выглядело так-то. Разработчик не хочет за частую разбираться как сейчас работает, и просто делает верстку и перетаскивает на шаблон, в итоге тоже пол сайта не работает. К кому претензии будут - к разработчику.

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

1. Обновление должно выполняться на тестовом стенде
2. Заказчик должен проверить работоспособность сервиса (сайта) после обновления и подтвердить обновление на прод среде
3. Обновление может влиять на работу ранее реализованного функционала (он может перестать работать, начать работать по другому)
3.1. В этом случае необходимо провести диагностику и дать развернутый ответ о причинах такого поведения и что можно сделать, а сделать как правило можно 2 вещи:
3.1.1. Откатить обновление ядра до предыдущего состояния (но это как правило должно было выясниться на этапе 2)
3.1.2. Предложить доработать функционал, чтобы после обновления работало

И конечно проговорить заказчику все риски и сценарии заранее.

Чебан Валерий, ну пусть сам нажмет, а если без шуток, то он платит за минимизацию рисков.

Сложно объяснять это только в тех случаях, когда сайт генерирует 10 заказов, когда на сайте 1000 заказов в сутки - все вопросы отпадают, так как ошибка, которая может масштабировать убытки или простой сайта в результате ошибки - это всегда дороже.

Всегда найдется тот, кто сделает дешевле и вообще не учитывает всяких особенностей по предыдущему опыту, так как у него его просто нет. Где-то общался на fb и обсуждали тему сроков запуска интернет-магазина. Все пишут что недели 2 надо, но тут же пишут, что никогда такого не было. 2 недели типа это в идеальном сценарии, которого на их памяти не было практически никогда. Ну и встречный вопрос им - зачем тогда вы вообще озвучиваете сроки в 2 недели если это неправда?

Чебан Валерий, статья не поможет. У кого нет опыта - им предстоит его только набраться, у кого опыт есть - всё понимают уже.