для типовой есть ключ UpdateCfg

а как сделать такое:
1. обновляю штатным обновление cfu, не сохраняя конфу
2. выполняю сравнение и объединение с измененной cf
3. сохраняем результат

"2. выполняю сравнение и объединение с измененной cf"
Это должно выполняться в пакетном режиме, а галочки ставить?

Если у тебя есть готовый CF его можно (и нужно) просто загрузить? В пакетом вроде есть /LoadCfg.

*(1) что-то со знаками препинания не сложилось, второй знака вопроса лишний

>>>Если у тебя есть готовый CF его можно (и нужно) просто загрузить? В пакетом вроде есть /LoadCfg.

а кто обновит конфу поставщика?

ну и потом конфы одинаковые, но не идентичные, это означает, что возможно в них разные идентификаторы метаданных...

Все эксперементы - на кошках. Тьфу - на мышах. Нет, не гуманно. На юзверах vde69.

Кто и что мешает обновлять конфигурацию на копии базы и загружать без сравнения в рабочую базу?

Одинаковые, но не идентичные говоришь? А сделать идентичными религия не позволяет?

и PS: при загрузке конфигурации (если конфигурация была на поддержке) - загружается и конфигурация поставщика.

PSS: сделай свою собственную поставку - некоторые вопросы отпадут сами собой. Появятся новые :)

(4) я стремлюсь перевести в полностью типовые,

сейчас  у меня примерно 6 групп баз по 5-8 баз в каждой группе, обновление всех занимает слишком много времени, хочу упростить все это...

Если конфигурации однотипные и одинаковые, то:
/DumpIB
/LoadCfg
/UpdateDBCfg

(3) при загрузке конфигурации конфигурация поставщика обновляется (точнее заменяется). А вот если ты умудрился наплодить одинаковых конф. с разными идентификаторами метаданных, то теперь мучайся.

Я всегда загружаю и никаких проблем.

Зачем "теперь мучайся"? Это легко решается. Обрати внимание: я не говорю "быстро". Но сделать все конфигурации одинаковыми, через сравнить, объединить конфигурации - рутинная операция.
И даже если будет выявлено, что конфигурации сильно "разбежались" по идентификаторам, то всегда есть на это решение - КД сделает правила автоматически и она же - выгрузить и загружить данные.

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

Если отличия только в идентификаторах то достаточно будет ВыгрузкаЗагрузкаXML, КД здесь лишнее кмк.

Используется 2 тактики обновления боевого контура:

1) Через cfu - как то готовишь его на препродакшн контуре и потом можно автоматически грузануть
2) РБ подключена к отдельному хранилищу, в это хранилище кладут из отдельной базы нужное к обновлению, а забрать в РБ уже можно так же автоматически

а чо в (0) написано я не понял

(9) (8) Вы хоть раз пробовали через КД сделать ПОЛНУЮ выгрузку в новые релизы?

Вы попробуйте банально пустую базу сделать, что бы в ней не было ничего создано заполнением...

Я пробовал - задача совсем не простая.... ибо нужно сначала выгрузить все настройки (и не накосячить с предопределенными).

(11)
1. Я против КД (смотри (9))
2. Переносить строго те данные, которые попали в реструктуризацию из-за идентификаторов. Не надо переносить в пустую базу, нужно лишь восстановить что потерял.

"Вы хоть раз пробовали...?" - нет, я тут мимо случайно пробегал, дай думаю что-нибудь умное скажу. Не только пробывал, но и делал. Миграция из УПП в ЗУП 2.5; из ЗУП 2.5 - в ЗУП 3.1; обмен между УПП и ЗУП 3.1...

RomanYS прав - достаточно частичный перенос только различий. КД предложил исходя из наиболее пессимистического варианта, когда есть различия не только в идентификаторах, но и в метаданных.