Есть модуль Битрикса, 3 года назад он поставлялся как доработка основной конфигурации, у нас сейчас на нём завязано несколько расширений

Я думаю будет правильно из типовой конфигурации убрать объекты конфигурации Битрикс, и сделать из неё расширение.

Кто что посоветует ?

Пробую и так и сяк, но 1С не позоволяет изменять принадлежность модулей (из конфы в расш).
Я так понимаю остается только вручную переносить ?

выгрузка в файлы -> правка -> загрузка из файлов

(1) да
(2) данные это не перенесет правильно

(1) в планах развития 8.5.4 был перенос туда обратно, но планы перенесли на след релизы
В планах на 8.5.5 этого нет

(4) понял все, благодарю!

(2) как вариант, ну там другие подводные камни.

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

(3) Для данных код писать
Сначала оставить в конфе, сделать расширение с префиксом
Затем перенести данные
И удалить в конфе

Но имхо критичные данные в расширениях лучше не хранить
Все еще чревато

(6) больше страшилки. Тьфу тьфу тьфу, 8 лет храним, полет нормальный

(6) были какие то проблемы с этим уже?
с данными в расширении

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

(8) клиент при смене платформы получил ошибку в структуре таблиц бд с расширением. пришлось отключать расширение с переносом данных в новое подключенное.
а так, давно использую - нет проблем)))

(0) >> Я думаю будет правильно из типовой конфигурации убрать объекты конфигурации Битрикс, и сделать из неё расширение.

Почему ты так думаешь?
Есть хоть одно обоснование? Ну хотя бы тупо - зачем и для чего?

>> Кто что посоветует?

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

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

PS Разумеется высказывание - ИМХО.

(7) >> 8 лет храним, полет нормальный

Частный пример когнитивного искажения "ошибка выжившего". Это тип смещения выборки, возникающий, если при принятии решения человек опирается только на примеры «выживших» (тех, кто добился успеха), но не учитывает статистику по «погибшим» (тех, у кого не получилось прийти к такому же результату), поскольку данных по ним мало или они отсутствуют.

В нашем случае данные по "погибшим" есть. Но они упорно игнорируются. Хотя, по здравой логике, пусть даже самая минимальная вероятность негативного сценария потери данных должна исключаться. Но нет!!!! Нам же хочется, чтобы было модно-молодёжно ©. Пусть даже мы не знаем зачем.

(12) вероятность потери данных данных исключается бэкапами.
Всё остальное только снижает вероятность

(12) У вас у самого ошибка выжившего.
Никогда по бороде не шла основная конфигурация, что сервер 1С не стартовал?
Расширения настолько же опасны как и все остальное.
Конфа основная бородилась не только у меня.
И динамические обновления тоже бородили конфу
И расширения бородили конфу
Реструктуризация версии 2.0 вообще базу бородит да так, что только восстанавливать, потому этот способ не юзаем
Расширения меньшее из зол.

(13) согласен
Бэкапы позволяют даже на уровне скуля скопировать рабочую конфу в нерабочую базу не утратив введенные юзерами данные

(13) Не исключается, а просто снижает вероятность (кому-то и потеря данных за 1-2 часа критична).
Всяко бывает: и гнутая / недописанная копия, и поломка хранилища оных, и прочее непредвиденное

(12) Причина может быть не только в "Стильно, модно, молодёжно", но и "Политическое решение руководства" (мало того, некоторые, шибко грамотные конторы, доработки типового функционала пытаются продавать расширениями)

(11) Ну честно говоря, я только 2 месяца тут работаю, больше года до этого с 1С не взаимеодействовал, ну и подумал что эти объекты уже неактуальны, т.к. есть на его замену Расширение 1С БУС которое на поддержке

А так та, мне возможно нечем заняться )

(15) Это если поломалась конфа, а если погнули данные обновлением? Т.е. конфа целая, а данные не очень и поняли это в середине дня.
Надо поднимать копию и чинить то, что поломали.

(16) кому-то и потеря данных за 1-2 часа критична
Значит их политика бэкапов должна исключать такую потерю данных. Речь же не про математическую вероятность потери каких-либо данных, а про исключение критической потери данных для конкретной базы.

(18) Ну и тут аналогично: или ты готов тестировать обновления или готов принять принять риск "поднимать и чинить"

(15) Можно и в рабочее

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

(21) возьму на заметку, спасибо

(21) Странное решение

Имхо все данные в основной конфе если можно
Данные в расширении только когда их нельзя легко засунуть в основную конфу

(23) пчму странное? стратегия вполне оправданная - это позволяет лезть в конфу в последнюю очередь.

(24) Легкость обновления типовой конфы теряется
Заипешься и в т.ч. на реструктуризации
Что там произойдет когда расширение нафигачило своих реквизитов и ТЧ (по сути новые таблицы созданы)
А в обновлении типовой эти же метаданные меняются? (пытаемся изменить исходные таблицы)

(25)+ Когда все данные в конфе - можно в крайнем случае сползать в СУБД и там запросами править/восстанавливать довольно легко
В случае увеличения кол-ва таблиц в СУБД, а что еще хуже несколько разных расширений подряд одну исходную - нюню

(18) бывало и такое, с бэкапа выгружаешь загружаешь, в зависимости от ситуации пишешь обработки запросы.... Адреналиновые ситуации

(25) все надуманно
Есть и есть реквизиты добавленные расширениями, никаких пооблем
Чаще проблема в другом
Типовые реквизиты меняют тип или их удаляют

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

(26) "а что еще хуже несколько разных расширений подряд одну исходную" а вы что, в расширении меняете таблицы объектов конфигурации??? охренеть, какие рисковые пацаны, ажно завидки берут... Все доп. реквизиты в таблицах конфигурации давно делаю только через регистры сведений в расширениях. был плохой опыт как только появилась возможность расширениями изменять состав реквизитов объектов...

(30) При этом способе теряется смысл в расширениях.Расширения уже давно не те, что были несколько лет назад.Поэтому чем городить обвязки через РС, лучше прямо изменить конфигурацию,сняв ее с поддержки,ИМХО это не нарушит логику работы с реквизитами как ваш подход.
Кроме того вы противоречите своему же правилу(21).
В каждом конкретном случае выбор между расширением и конфигурацией должен быть взвешенным.
(0) Я поддерживаю Dmitrii (11).Вам просто нечем заняться))
В(11) разумный подход.Не нужно все тащить в расширение.Гдето РС в расширении - отличная идея, сам так делал,но добавление существенных данных в таблицы с возможностью их почти типовой обработки - дорогого стоит.