8.х Обновление сильно не типовой БП

Не нужно ничего с поддержки снимать. Лично я обновляю конфы измененные сильно так. Например надо обновить с релиза 1.1.1 на релиз 1.1.2
Создаю две базы.
1) Типовая релиза 1.1.1
2) Измененная 1.1.1
Обе начинаю обновлять на 1.1.2. Появляется окно сравнения и объединения. И поэтапно начинаю смотреть и выявлять где изменения от поставщика, а где мои. После обновления на локальной машине, сохраняю cf. Тащу на сервер и полностью загружаю ее в рабочую базу.
nomad_irk скорее всего имел в виду, что просто разблокировать все объекты нужно, чтобы конфа загрузилась. С поддержки не надо снимать. Сам лично по такой технологии обновлял процентов на 50% переписанный ЗУП 15 релизов. Так что проверено.
Надеюсь перед обновлением не забудете сделать копию базы.

Ты про скрытые что ли?

Опять друг друга не поняли

Нет. В конфигураторе. Пункт меню Конфигурация-->Загрузить конфигурацию из файла.

Вот например где замочек есть, эти объекты не доступны для редактирования.

Когда Вы начнете загружать конфигурацию по методу описанному выше, программа будет ругаться, что типа есть заблокированные объекты. А если в конфигурации присутствуют скрытые модули, то придется снимать с поддержки, как написал nomad_irk. Скрытый модуль, это модуль, который зашифровал средствами платформы и скрыт от глаз пользователя. Выглядит это так

Как правило, такое встречается в конфигурациях с дополнительной лицензией. Таких компаний как РАРУС к примеру. Т.к. в 1С отсутствует какое-либо другое средство защиты.
P.S. Чтобы обновить измененную 1С нужно понимать какой-именно функционал "дописан" в исходной конфигурации. Его нужно понимать. Если у Вас есть подобные вопросы, то может следует задуматься о том, чтобы доверить эту работу кому-то другому?! Не хочу ничего сказать плохого. Просто помню как исправлял ошибки незнающих людей при обновлении. Ну конечно если Вы хотите научиться и возможность есть, то вперед, мы подскажем

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

Хранилище предназначено для групповой разработки. Не пойму где вообще связь с обновлением.

Через хранилку удобно как раз обновлять сильно не типовые конфигурации (даже если не ведется групповая разработка). Позволяет откатиться на предыдущую версию в случае некорректного обновления и не возникает вопросов типа "я обновил локальную базу, что мне делать дальше?". Вообщем на любителя, но я считаю что вариант приемлемый: обновили локальную базу, проверили и можно дальше не заморачиваться с выгрузками/загрузками .cf и прочим.

Короче, опять удостоверился. Сколько людей, столько и мнений.

При таком способе обновляется конфигурация поставщика?

Конечно.

Эт хорошо, а то вопросом таким задавалась, а пробовать, не пробовала.