По теме Обновление нетиповой через несколько релизов .
Если я делаю обновление на копии базы, а потом загружаю ее в рабочую - это не может вызвать проблем?
Ну, например, я разворачиваю базу как "Копию", сделаю то что надо, а потом разверну ее на рабочей базе? На реальной в это время никто работать не будет, просто лучше "поэксперементировать" на копии, получить правильный результат, а потом загрузить ее обратно.

В принципе, ответ есть и здесь: https://zen.yandex.com/media/id/5ef999eadeaa4a703e986f2a/kak-izmenit-zagolovok-okna-1s-i-ubrat-iz-nego-slovo-kopiia-5fb83242ffe1de7f5c01853d#:~:text=Убрать%20слово%20%5BКОПИЯ%5D%20и%20снять,слово%20%5BКОПИЯ%5D%20из%20него%20исчезнет , но хотелось бы узнать реальный опыт...

Да зачем? Просто с подготолвенной копии выгрузи готовый *cf и загрузи в боевую базу. Только копию сначала сделай.

не, ну как зачем?

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

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

И несколько релизов базы туда-сюда гонять?

(4) для чего?

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

Везёт некоторым, что можно в файловой версии обновлять. Последние базы обычно весили гигов 150-200.

(3) так отметка, что это копия, убирается легким движением руки, в чем там проблема?

(7) если для меня, то никакой проблемы нет. Если для ТС - хз

(0) Если имеется в виду "загрузить подготовленное обновление на 1 релиз" - то никаких проблем не будет, если все сделано верно.
Если же "через несколько релизов" - то скорее всего "пронесет", но гарантий никаких нет.

В качестве примера - "лабораторная работа". Пример упрощенный для понимания.
Абстрактная конфа. Справочник "Сотрудники".

Релиз №1.
Есть Реквизит Пол, булево (НЕТ = мужчина, ДА = Женщина).  

Релиз №2.
//навели порядок, завели перечисление Пол (Муж,Жен)
Реквизит Пол переименовали (УдалитьПол), завели новый Пол (Перечисление.Пол)

При первом запуске перехода с релиза на релиз..
Если НовыйРелиз = 2 тогда
...
  Сотрудник.Пол = ?(Сотрудник.УдалитьПол,Перечисление.Пол.Ж,Перечисление.Пол.М);

(таким образом, при обновлении с релиза 1 на 2 данные не теряются)

Релиз №3.
Ничего не делали со справочником.

Релиз №4.
Удалили реквизит УдалитьПол

Релиз №5.
//в законе 123/45-67 указаны прочие варианты пола.. Средний и т.п.
Реквизит Пол переименован в УдалитьПол
Создали реквизит пол Справочник.Пол, с предопределенными значениями М, Ж
Если НовыйРелиз = 5 тогда
...
  Сотрудник.Пол = ?(Сотрудник.УдалитьПол = Перечисление.Пол.Ж, Справочник.Пол.Ж, Справочник.Пол.М);
..

(таким образом, при обновлении с релиза 4 на 5 данные не теряются)

И, наконец, вопрос: Потеряется ли реквизит Пол при обновлении с релиза 1 на релиз 5 ?  :)
Вероятность нарваться на такую проблему минимальна, но она при обновлении прыжком через 100500 релизов существует...

(9) Спасибо, вот именно о таких случаях я и думал.

(2) "Выгрузи готовый *.cf и загрузи в боевую базу" - это как раз и есть тот случай, когда делается неправильное обновление. В итоге обработки по обновлению не сработают, а в качестве конфигурации поставщика останется старая версия.

(10) отчего обработчики не сработают? Номер версии конфигурации сменился? Значит сработают. А обновить конфу поставщика потом до нужной версии не очень большая проблема (если заморочится то можно и через sql потом накатить сразу нужную версию)

(10) загрузка CF из файла сносит напрочь конфиг поставщика.

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

Повторюсь : при небольшом размере базы гораздо лучше и проще получить ее в полностью обновленном виде в файловой версии и затем загрузить в серверную.

Но если с этим есть проблемы... ну проблемы надо преодолевать

(10) (11)

В  (9) приведен упрощенный пример, когда обработчики корректно не сработают.
Да, пример условный. Да, 1С очень редко удаляет реквизиты "УдалитьИмяРеквизита". Но иногда это происходит.
И бывают более сложные ситуации, например - уменьшение измерений регистра сведений...
А также бывает, когда 1С удаляет старый код обновления... т.е. был обработчики условно говоря с релиза 1 до 30 - стали с 15 до 31, старый код удален.
Да, и это происходит редко; но однозначно допустимость "прыжка" можно определить, только проанализировав код обновления при первом запуске нового релиза.

(6) >весили гигов 150-200

это sql базы столько весят, а файловая из нее будет сильно меньше