Прочитал несколько статей про это на Инфостарте и здесь. Но нигде не нашел ответа на тот вопрос , который мне нужно прояснить.
Есть 20 различных баз БП релиз 2.0.45.5 , нужно обновить до последнего 2.0.52.6 (т.е. 7 ключевых релизов нужно накатывать). В базах изменен план счетов (добавлено много новых счетов , предопределенных через конфигуратор ) , добавлено субконто , на некот. счетах добавлен колич. учет и учет по подразд. , добавлено около 15 док-ов.  И в каждой базе есть свои индивидульные изменения (из 20 баз есть 2-3 пары , которые почти одинаковы). Базы в основном не на поддержке. Есть несколько , которые на поддержке - но поставлены неправильно - вместо типовой конф. 1с соотв. релиза 2.0.45.5 как файла поставщика там в качестве файла поставщика находится файл = основной конфигурации. Вообщем , такое впечатление , что тот кто ставил на поддержку не совсем понимал, что делал и для чего.
В чем состоит вопрос .
1)Сначала я ставлю базу на поддержку - здесь все понятно.
2)Работаю на копиях. Имея две копии одной базы , в одной сравниваю (с флагом "Показывать измененые дважды") , из второй копии беру уже изменения после принятия решения , как переносить проблемный объект - здесь тоже понятно.
А вот собственно сам ВОПРОС.
Т.к. нужно накатывать 7 релизов  , то на каждом из этих 7-ми этапов должен быть некий файл (cf ?) , с помощью которого я буду уже обновлять реальную базу. Что это должен быть за файл ? Если это будет cf уже с моими изменениями - то через Поддержка-->Обновить конфигурацию его ведь нельзя грузить - так ведь только конф. поставщика загружаем (т.е. типовые конф.) . А через сравнение/объединение - нужно уже будет за метаданными следить.  Где-то здесь на Мисте находил тему , что человек делал через хранилище.Т.е. рабочую базу обновлял через хранилище.  Но хранилище организовать здесь нельзя.
Как же лучше сделать ? Или потом на рабочей базе проделывать все манипуляции , которые проделывались на копиях ? - но есть наверное более оптимальный путь.
Спасибо.

(0) раз все базы по-разному изменены, придётся долго и упорно обновлять каждую по отдельности.
Накидываешь обновление до ключевого релиза, сохраняешь cf и так до нужного релиза.
Потом этими cf-никами обновляешь рабочую базу, по очереди

(0) Предлагаю на каждый релиз делать свой cf, с начала апдайтом обновляешь, потом БЕЗ ОБНОВЛЕНИЯ конфигурации базы данных, накатываешь свой cf, так и конфигурацию поставщика не потеряешь, что значительно облегчает следующие обновления и cf готовишь 1 раз на каждый релиз

(1) Спасибо. Это самый очевидный путь - но наверное не самый  оптимальный ,   так как  придется следить за метаданными , сопоставлять их - и теряем еще конф. поставщика.

(2)Спасибо  - вот это , как мне кажется то , что я и хотел прояснить для себя - вот так наверное и стоит делать. Здесь по идее должно быть все нормально. Т.е. еще раз :
а)На выходе каждого шага при обновлениях на копии имеем файл cf. (7 штук для каждой базы)
b)Доходим до обновления реальной базы. Через Поддержка->Обновление конф. накатываем конфигурацию поставщика соотв. релиза (получаем обновленную конф. поставщика) - но НЕ ОБНОВЛЯЕМ конф. базы данных , а потом через Сравнение/объединение накатываем свой cf . (соотв. шага).
==========
Получается что так наиболее оптимально выйти из этой ситуации ? Или есть еще какие-то предложения/идеи ? А свой cf уже с изменениями нникак не можем загрузить через Поддержка->Обновить конф. ? Только через сравнение/объединение получается ?

Ужас, обновление под номером 52.
У нас еле дошло до 2.0.12.7

Что можно добавить к (3) - так это если в дважды измененных на каком-то шаге  не будет ни одного объекта ( как сие состояние приятно созерцать ! ) , то на этом шаге cf сохранять не надо , достаточно для этого шага соотв. конф. поставщика...

а если взять CF от конечной обновленной типовой базы и его накатывать через сравнение-объединение? Зачем каждый шаг по очереди?

Переход на 3.* не предлагать ??)))

у меня обновление УПП было скачком через 4 типовых релиза + обновления написанные головной фирмой, пересекающиеся с нашими. Обновление только одного документа ПТиУ заняло три дня, пока выяснил все зависимости и смерджил тексты модулей.
Я все правильно сделал? )

(6) Каждый шаг по очереди , чтобы при переименовании и удалении метаданных не было проблем . После каждого шага нужно обяз. запускать базу в режиме 1с Предприятие , чтобы выполнились необх. действия при переходе на ключевой релиз (иначе можно данные потерять , например , при изменении хранения к.-л. данных...)

(7) :)  Это само-собой , но позже. Обновляться -то с последних релизов 2.* все равно нужно при переходе на 3.* (чтобы перейти на 3.* , нужно вот эти ~15 нетиповых документов (+неск. отчетов и обработок), которые есть в этих конфигурациях перевести сначала на управляемые формы , потом все внешние обработки и отчеты , которые работают с этими конф ., которых не мало , также перевести на управл. формы , все проверить ,(+ правила обмена с УПП и между собой и ЗУП - также переписывать)
- так что песня не быстрая ...  )

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

(2) Что мешает на финале сравнить-объединить с типовой 2.0.52 без галочек и поставить на поддержку?

(8) Потенциально при обновлении таким образом возможны проблемы , все зависит от конкретики. Классический пример  : в пропущенных тобой релизах (№1-№4)  , которые ты пропустил , в №1 меняется хранение , например, адресов контаргентов - вместо справочника переносятся в РС. РС создан , рекв. справочника переименован в УдалениеАдрес , и при запуске данные переносятся из рекв. спр. в РС. В №2 релизе пропущенном тобой рекв. спр. удаляется . Ты накатываешь сразу релиз №5 - рекв. спр. удаляется после наката (он у тебя с данными) - данные ты потерял.

(12) обычно помеченные на удаление реквизиты долго хранятся.

(10) Попасть как , если обновление идет последовательно на все ключевые релизы с обязательным запуском в режиме 1с Предприятие после каждого шага ? Где может быть проблема ? Пример ?

(12) он попытается выполнить обработку при обновлении и вывалится ошибка, так что попробовать можно.

(14) написал же - при скачке. а попасть именно так, как ты описал в (12)

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

(3) да, все правильно резюмировал

(17) лучше не рисковать, а сделать правильно но не так быстро, чем сразу cf на несколько релизов вперед и потом получить не неожиданный гемор...

Я в место двух конфигураторов, использую 1 и объединение с приоритетом (уже самих процедур) а потом уже пробегаюсь по MRG и анализирую и удаляю их

(18) Буэ... Будь мужиком, используй WinMerge

(19) а подробнее? или как с этим работать? :)

Сделай обновление хотя бы одной базы, не трогая другие. Приобретешь опыт. Или отдашь это более опытному.