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

(0) отложенные обработчики обновления БД могут быть пропущены.
это перекладывание из пустого в порожнее обычно, но если там окажутся твои данные - будет больно.

если возник такой вопрос - то нельзя.
Кто знает, как можно - такие вопросы не задаёт

просто раньше в общем модуле добавляли обработчики для всех релизов, теперь так не делают?

(3) Вот видишь - ты даже не знаешь, как проходит процесс обновления. И даже в код не смотришь.
А рвёшься разрушать устои и разбивать скрепы...

(0) нельзя, надо запускать предприятие чтобы там выполнилась обработка
и обязательно проверять что нет ошибок

(5)+ причем в последних релизах постобработка фоновая, т.е. надо это учитывать

(6) Прошу уточнить, что поменялось? Ранее тоже было два этапа: первый - с незакрываемым окном, а втором - в фоне.

(7) да ничего просто незакрываемого окна может и не быть ))

(8)+ точнее оно быстро проскакивает а вся реальная обработка в фоне

пока работают обработчики в предприятии - обновляется конфиг на след релиз, почти всегда обработчики успевают

(10) зависит от объемов
у нас нихрена не успевают уже хотя базе всего полтора года

(0) Можно, но может не сработать и надо будет всё повторять вручную.

ясно, спасибо
(10) разумно
(4) раньше было, что то типа:
Обработчик = Обработчики.Добавить();
    Обработчик.Версия = "11.1.2.10";
    Обработчик.Процедура = "ПланыВидовХарактеристик.СтатьиАктивовПассивов.УстановитьПризнакАктивПассивУПредопределенныхЭлементов";
    Обработчик.Опциональный = Ложь;
        
    Обработчик = Обработчики.Добавить();
    Обработчик.Версия = "11.1.2.11";
    Обработчик.Процедура = "ПартионныйУчетСервер.ИсправитьДвиженияСебестоимости";
    Обработчик.Опциональный = Ложь;
деталей не помню, но обновлять можно было, без запуска, сейчас не знаю, поэтому спросил

(3) Дело не только в отсутствии или наличии обработчиков. Классический случай: изменение значений одного типа на другой с потерей данных.

(14) если они последовательно бы выполнялись, как бы такое случилось?

(13) Так же всё осталось, но проблема при заполнении удаленных реквизитов и объектов метаданных мешает, а в 1с окопался вредитель, который меняет наименования реквизитов и объектов метаданных.

(13) в 1С косячат:
релиз 1.1.1 добавлено создание предопределенного ПВХ в отложенных обработчиках обновления
релиз 1.1.2 идет обращение к предопределенному ПВХ напрямую в коде без поиска в обязательных процедурах (которые обрабатывают при старте).

С 1.1.0 не перейти сразу на 1.1.2 без правки кода, только по-порядку.

(16) теперь всё понял, т.е. последний релиз переименовывает реквизит в УдалитьКонтрагент, а обработчик первого уже значения реквизита Контрагент в Партнер перенести не может, так как нет его.

(18) Случай из практики (и не однократно): был реквизит справочника с типом строка, а стал - с типом справочника. При первом обновлении реквизит сделали составного типа (строка, тип справочника); обработкой обновления строками реквизитов заполнили справочник и в значения реквизитов указали ссылки на эти записи. При втором обновлении у реквизита убрали тип строка. Не сложно догадаться чем закончится прыжок через первое обновление.

(0)При наличии бакапа можно обновляться даже cf-файлом. С некоторого времени типовые 1с при резвом обновлении начинают писать, что могут обновиться только с такого-то релиза. Тогда нужно восстановиться из бакапа и накатить сначала тот релиз.

(0) можно, но не нужно,
эффект будет такой же, как обновлять с помощью полного cf с перескоком - может повезет, а может и нет

(0) Обновлятор-1С в помощь