Есть нетиповая Розница 2.2, немного, а может и сильно доработанная. Из основных доработок, которые я там уже нашел - это добавление партионного учета (новые регистры, добавление изменений в механизмы проведения и прочее).

Надо обновить ее до последнего релиза 2.3. Но проблема в том, что для того, чтобы "дойти" до последнего релиза, надо "перескочить" через 10 предыдущих. И каждый раз, обновляя предыдущий релиз, запускать ее в режиме Предприятия. Как это делать, я знаю. Также знаю, как сохранить данные, чтобы все новые регистры, справочники, документы, реквизиты со старыми данными не "потерялись". Но раньше я обновлял нетиповые только с релиза на релиз, а тут их целых 10! Проблемка...

Вот и возник вопрос - а что, если я буду переносить с релиза на релиз только данные, а все изменения в модулях перенесу уже в последний момент - с первого на последний? Кто-нибудь с этим уже сталкивался? Подскажите, плз.

Ну... Готовь три конверта, бочку вазелина и медаль чемпиона области по стайерному бегу. И удостоверение разведчика не помешает.

(1) ?

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

Делал так. Но все индивидуально. Может стоит все изменения сначала в расширение перенести?

Оцени, как сам думаешь, и умножай на 5.

(2) оценивай по наихудшему варианту

(2) Как там было в книге, которую не читал ТС в соседней ветке...
"мнээээ... не советую.... Мнээээ.... съедят...."

(3) Расширения тоже зло. Обновление объекта в расширении

(3) Предложение интересное. Можно перенести дополнения в модулях, но я боюсь переносить туда те же регистры - хоть и говорят, что при правильном обращении данные не потеряются, но все равно... как-то не по себе...

(2) Поставь себе kdiff3 и настрой 1С на работу с ним. И обновляй через типовое обновление, тогда процесс обновления значительно упростится.

(2) Есть вероятность того,что все дописки работать через 10 обновлений не будут.И через 1,2 обновления тоже. (8) Расширения это зло.

(8) в расширение нужно перенести только программный код.
(7) На вкус и цвет...

(0) Почему партионный учет не был сделан в Рознице штатными средствами?
Имхо я бы взял последний релиз Розницы 2.3, сделал нужные доработки в виде расширения.
Затем сделал копию старой Розницы 2.2, тупо вернул на поддержку и обновил штатно с потерей данных.
Затем через json перенес "партионный учет" и прочие данные из старой копии в новую с доработками расширением.

(0) При обновлениях и запуске в режиме предприятия, обычно выполняются всякие обработки. Пример:
В релизе 1.1 в документе присутствует реквизит1. Есть данные которые в нём хранятся.
В релизе 1.2 от этого реквизита решили отказаться, и разработчики решили перенести инфу  в новый реквизит.
При запуске в режиме предприятия после обновы на 1.2 выполнится обработка которая переносит эту инфу в новый реквизит

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

(12) "Почему партионный учет не был сделан в Рознице штатными средствами?"

Это как?

(14) Вот я об этом тоже подумал.
Можно перенести только обработки проведения, если... из них не тянется "что-то еще".

(15) через характеристики

(17) Ну, это делал не я, а почему так сделали - наверное, клиент и разработчик сошлись на таком варианте.
Я сам делал в другой фирме через характеристики.

Возник еще один вопрос по теме, которая здесь обсуждалась.

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

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

Кто-нибудь так делал? Могут быть с этим какие-то проблемы?

(19) Нужно понимать какой у заказчика компьютер и интернет (может быстрее будет скачать базу себе, обновить и вернуть обратно).
Через cfu дольше, чем просто загрузить конфигурацию, т.к. требуется время ЦП на создание новой конфигурации на основе старой и cfu.

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

(20) "Просто загрузить конфигурацию" - мне потом нужно будет менять и конфигурацию поставщика.

(21) "Но там минут 10 нужно" - не факт, иногда после обновления первый запуск в режиме Предприятия идет ну ооочень долго. А сделать это нужно целых 10 раз (скачок через 10 обновлений, написано в (0) ).

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

(22) лучше наверно не сразу на 10, а два раза по 5

(24) лучше обновиться на последнюю 2.2, потом на последнюю 2.3.
Проверить на копии (в т.ч. замерить время) после этого спланировать загрузку конфигурации в продуктив.

(7) // (3) Расширения тоже зло. Обновление объекта в расширении

Дай дуракам хрустальный хер - и разобьют его и руки порежут

А по текущему топику возникает вопрос : если в конфу добавлены новые объекты, то с какого перепугу эти якобы новые должны похериться от какого-то типового накатывания обновлений?

Или якобы новые объекты на самом деле вкорячили через задницу и они норовят отвалиться даже при минимальных касаниях?

И очередной раз обсуждение сферического коня в вакууме.

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

(28) С 2.2.11.24 на последний, 2.3.7.22.

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

1. Вариант оптимизировать изменения , вынести все по максимуму в отдельные модули, в штатных модулях вызов доработок одной функцией. С такой стратегией 10 обновлений можно провести за небольшое время. Мои измененные конфы УТ11, УТ10 как правило при обновлении и сопоставлении дважды измененных в 80% вообще не требуют доработок, а если и требуют то замерджить одну строчку.
2. Если первый вариант не вариант, был у меня опыт когда обновлял все релизы без учета сторонних изменений в конфе (тянулись только данные)  а на последнем релизе накатывались уже все изменения модулей, анализировались процедуры обновления и писалась своя обработка которая делала нужные перепроведения документов, кстати в итоге выяснилось что не было надобности что то препроводить.
3. Сейчас я вообще плотно подсел на расширения, пока что очень устраивает, и про данные были опасения но пока проблем не встречал, нужно расширения тоже очень грамотно писать и не привязываться к изменениям как платформа любит сделать по умолчанию.

(13) если просто удаление, то не страшно. Хуже, если идет переименование реквизита.

Если удаляется, то можно взять пустую типовую. Ее обновить - получим cf нужного релиза.
Далее берем свою конфу и делаем сравнение и объединение. Запрещаем удалять реквизиты.
Таким образом Реквизит1 остается и при переходе на релиз в него попадут данные.
И когда будет выполнен переход на последний релиз, то удалить реквизит