Есть старая база УТ (версия 11.3.2.218). Хотим её обновить до УТ (версия 11.4.8.73). Для этого делаем так:
из старой базы выгружаем xml (с частью каких-либо данных, н-р, пко за 10 дней) и загружаем его в новую базу.

Это самый лучший способ, верно? :-)

если в базе 3 документа, то да - это джек-пот

(1) к сожалению, исходная база около 60 гигов

Хотим обновить и обмен данными как-то не сходится.Или обновляйте или обменами до поры какой-то

(0)  это тупизм.
- или обновляйте последовательно с вашего до текущего с вашими данными
- или обрежьте базу и п.1

Переносить как-то частично какие-то доки, справочники - вы посмотрите по балансу, какая фигня у вас произошла.

(3) просто обновить исходную до нужной версии не получилось (проблема была в дополнительных процедурах обновления в режиме предприятия, висело более суток, так и не закончилось, и это только на один релиз)

А чем не подходит дедовский способ :
сравнить с конфигурацией поставщика, перенести изменения в текущий релиз, обновить до текущего через "сравнить объединить конфигурацию".

Я с ут11 не работал, там какие-то особенности в этом плане?

(5) Разбирайся.И на выходных можно запустить.А так мы вырываем гланды через анус выходит

(0) Любая учетная программа - это:
- справочная информация
- начальные остатки
- документы за текущий период

Что вы пытаетесь выгрузить в пунтке "выгружаем xml"???

(0) как вариант попробовать
1. удалить все движения документов
2. обновиться на готовый cf последнего релиза
3. провести заново все документы

(8) ну к примеру, данные по "Реализациям товаров и услуг" за период в месяц.

А просто накатить *.cfu от 11.4 не получается? Заранее посмотреть, какой подойдет к текущему релизу.

(11) не обижайтесь, но что-то фигню какую-то пишете :-)

(12) не обижайтесь, но вот вам ссылка, если гугл сломался https://wiseadvice-it.ru/o-kompanii/blog/articles/perehod-na-1s-ut-11-4-poshagovaya-instrukciya/

(2) была старая УТ 11.2. около 300 Гиг
чтобы переехать в новую написали свой
- перенос справочников
- перенос с вводом остааков
на файлах жисон.

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

(13) спасибо, почитаем :-)

(13) Так и делали. Но вся проблема началась в момент первого запуска базы в режиме предприятия, в этот момент выполняются дополнительные процессы обновления, могут дозаполняться справочники, регистры и тд. И там был большой регистр, который очень долго проверялся, перезаполнялся и в итоге не дождались. База не обновилась до конца и запустить для обычной работы ее было невозможно.

а как вы сможете загрузить, если структура другая?

(0) (10) Вы какую-то куйню пишете.

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

Делайте обычное обновление. Продумайте стратегию - какие релизы можно пропустить, чтобы обновиться в 3-4 итерации (например, с 11.3.2 - 11.3.3 - 11.3.4 - 11.4.1 - 11.4.8). Разберитесь с обработчиками обновления - что там так долго делалось.

Альтернативный способ - это перенос остатков.
Но опять таки нужно будет писать правила обмена. Сложность и объём правил будет зависеть от решения - какие именно данные нужны будут в новой базе - только лишь справочники (остатки буду заноситься руками) или всё-таки ещё и остатки и по каким объектам и разрезам учета.

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

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

>> База не обновилась до конца и запустить для обычной работы ее было невозможно.

А вы что - сразу продуктивную базу обновляете и собирались после обновления сразу туда пользователей запускать? Без тестирования, без проверки?...

Короче. Банальный совет.
Пригласите специалиста (с) кто-то с mista.ru

(18) используется обработка Универсальный обмен данными xml для переноса, для разработки правил используется конфигурация Конвертация данных

(21) То есть правило лепить не лень,а выяснить причину сложно))

(16) А что за регистр-то?

(19) в этом регистре куча доков, поэтому долго

(22) причина в объёме этого регистра. Думаю, поэтому и не стали обновляться, так как очень долго шло обновление для одного релиза, а там их несколько

(25) Нет,причина не в желании разобраться.Даже если бы выложил бы подробности было бы проще.Думаю даже кто-нибудь подсказал бы.А так неправильный путь выбрал

(26) да я особо не программист, передаю что говорит разработчик, но так как вы тут стебётесь, подробностей не будет :-(

Куевый разраб,мы не стебемся,а намекаем на тупик

и вообще, заметил, что уровень советов на форумах и чатах, порядком упал :-) Проще самому разобраться

(25) "причина в объёме этого регистра" - так отключите обработку этого регистра и всё. Вы же его всё равно при выгрузке/загрузке через XML его не обрабатывате?

(28) >> Куевый разраб.

Ага. А Шаляпин - куёвый тенор. Мне сосед напел - полное *авно.

(31) То есть не согласен,что разобраться с обновой вернее чем лепить правила?

(21) Вы либо тролль, либо не понимаете о чём пишете (по незнанию или недостатку информации).

(27) >> так как вы тут стебётесь, подробностей не будет

Мы стебёмся потому, что, с точки зрения разработчика, ты несешь такую несусветную ересь, которую невозможно всерьез комментировать, а остаётся только стебаться.

(30) он записывается при этих действиях

(35) Вызываете свою обработку вместо "долгой" типовой? Что мешает запустить её без выгрузки XML?

(10) Отличный план!
В новой базе у вас будут только продажи. Остатки как будете переносить?

(31) норм шутка :-) Но что я могу поделать, если разраб НЕ ХОЧЕТ здесь вести беседу. Даже уже и читать теперь. А я пока не вник во все эти нюансы, и, честно сказать, особого желания нет. (33) Точного понимания о чём пишу у меня нет, всё верно. Поэтому, думаю, продолжения не будет, так как нужно уточнение подробностей, для ответа на ваши вопросы, но его не ожидается :-(

и вообще, изначально, хотели все эти операции выполнять в файловом варианте, на быстром хосте. Но так как в sql-базе размер одной таблицы более 4гб этот вариант не прокатил :-(

ну что, всё ещё обновляем :-) До конца этого года, "будем надеяться", обновим :-)

(5) арендуйте виртуальную уберчислодробильню на пару дней, чтобы пройти обновление
чтобы прошло в адекватные сроки, вам понадобится очень много оперативки: сколько база физически на диске занимает +20% на временные колебания, плюс подсмотрите, сколько на боевом сервере сейчас занимают rphost, плюс еще гигов 10 на всякий

если оперативки меньше - оно не будет падать, но из-за постоянных обращений к диску можно состариться, пока обновится

либо просто докупите мозгов в основной сервер

(39) Вроде в последних версиях (с 8.3.8) нет такого ограничения + 64 битный клиент. Попробуйте все же развернуть. Я думаю нормально можно файловой версией воспользоватся.

+ (42)  И да. Я прав https://its.1c.ru/db/v838doc#bookmark:adm:TI000000666