Такая ситуация : досталась нетиповая ЗУП ( частично снята с поддержки, плюс расширения чьи то ) - надо обновить. SQL.

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

(0) в кэше застряло. Почисти, перезапусти службы или сам сервер.

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

подобное было в практике, правда, в расширении не было созданных в нем объектов. снес расширение, сохранив на подключение после обновы. почистил кеши, перезапустил все и доехало.

(0) для начала
1. DT-шник выгрузи, попробуй на файловой.
2. Удали расширения-исправляния от 1с
3. Отруби все расширения
4. попробуй обновить

(0) Почистить кэши, перезапустить сервер, если вызывается несуществующая процедура.

(0) я бы пошел следующим путем, для начала выгрузить в DT, попробовать на файловой базе. Если та же шляпа, отключаем расширения, если не поможет, попробовал бы на другой версии платформы (как релиз так и битность х64).
Если на файловой все ок, то чистим кэш как серверный так и юзерский, если не помогает, пробуем другую версию платформы. Ну и далее по нарастающей, отключаем расширения и тд.
Тестирование и исправление тоже кстати можно попробовать, только копию базы сделать нужно обязательно

(5) далеко не все базы по размеру в файловую пролезут

(6) ЗУП же
Пока только ЕРП встречал чтобы не влезала в файловую

Имхо я бы через отладку понял где крашится и там выход сделал перед этим временно
Затем уже разбирался что за фоновое и нафик оно

И да
Правильно сначала приводить к типовому релизу той же самой версии
А уже затем обновлять

Если в метаданных изменения - попытаться понять зачем они нужны

(7) Лет 10 работаю с ЗУПами по 200-800 гиг... Запихни в файловую, ога

(9) Хотите, сделаю файловую на 8 Тб? Даже работать будет :)

(10) Куча не сильно больших таблиц внутри? Ну это сферический конь в вакууме, в реальной жизни есть особо большие таблицы, каждая от 10 гиг размером

(9) Не верю.
Вот не верю даже если за 10 лет и несколько тысяч сотрудников в базе ЗУПа.

Или там тупо прикрепленные файлы, которые легко наружу выкидываются.

ЕРП/КА/УТ легко можно раздуть
Даже БП встречал раздутые что в файловую не лезут, но это очень редко

ЗУП?
Вы там ежедневно (вместо двух раз в месяц) начисляете?
И сотни тысяч сотрудников в одной базе?
Или столько разных по ГПХ и каждый день отдельным вместо за весь период работ?
Еще и туева туча алиментщиков и прочих вычетов? Но они тоже вроде раз в месяц с одного.

Понимаю когда база торговли, услуг или производства раздувается
Там легко можно зафигачить в номенклатуру 500тыщ позиций и удивляться что тормозит
Или сотни если не тысячи доков в день, каждый с кучей позиций

Но в ЗУП то как?
Какой РС/РН с кучей строковых полей например - это я так размышляю ибо больше вроде нечему раздуваться

(13)файлы можно напихать.

(14) Так типовое хранение в томах же
Кто внутри базы файлы хранит когда их много?
Проблема с местом для бэкапов же

(15)+ Хотя согласен, если напихать кучу файлов и все в одном справочнике то может быть упс
В типовых специально раскидано по разным "Справочник.БлаБлаБлаПрисоединенныеФайлы"

(11) Что-то вроде того, создам регистры условно КадровыеДанные_1 и тд до КадровыеДанные_9999999 и внесу правки в текст запроса)

(12) Там раньше были свои приколы с графиками работы, если указывают у сотрудника собственные) (простите, не открывал ЗУП уже лет 5)
Условно если указать один график на всех сотрудников, то база будет весить 10Гб, если указывают свой график каждому сотруднику, то база становится 500Гб на ровном месте :)

(17) Условно можно было-бы со стороны 1С соотнести этих сотрудников в одну группу и писать в регистр сведений:
ГруппаВыходные, 01.01.26 - Выходной
ГруппаВыходные, 02.01.26 - Выходной
и тд, но типовая писала
Сотрудник1, 01.01.26 - Выходной
Сотрудник1, 02.01.26 - Выходной
Сотрудник2, 01.01.26 - Выходной
Сотрудник2, 02.01.26 - Выходной

Ну и представьте на 10 тыс сотрудников идет такой спам записей в регистре. За 5 лет куча мусорных записей набегает.

(18) Еще прикол забыл указать, сотрудник увольняется, но регистр на будущие периоды все-равно заполнялся :)
Этакий регистр накопления (остатки), который никогда не закрывается в 0.