Коллеги, доброго дня!
Есть база УТ11 типовая.
Планируется сильное изменение, поделитесь опытом, куда вносить изменения, чтобы потом было проще обновлять?

Зависит от самих изменений.

(1) по объёму планируется до четверти конфигурации. Документы, справочники, регистры. Скажем так, адаптация для отраслевика.

(2) Если планируются новые документы, справочники, регистры (или их реквизиты), то их я бы вносил в саму конфу. Не люблю новые метаданные выносить в расширения. Хотя, наверное, кто-то считает иначе.

Если менять типовой программный код, то по возможности, в расширение(и то надо смотреть).
Если в типовые объекты добавлять новые реквизиты метаданных - то снимать объект с замка и добавлять в конфигурацию.
Если совсем новые объекты - добавлять в конфигурацию.
ИМХО

если потерять новые данные не критично - выносить в расширение и не лохматить бабушку

(0) тут есть тонкость: если будете продавать - имеет смысл вынести доработки в расширение, но, при обновлении конфы и доработке в режиме &ИзменениеИКонтроль может отвалиться всё расширение (чисто алгоритмы, данные останутся целыми).
Тут важно помнить - расширения не видят друг друга, т.е. если добавить справочник в одно расширение, использовать его в другом не получится
Подход в (3) более устойчив в плане собственных доработок, но при продаже, придётся внимательно переносить исправленное

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

(7) Почитаю про новые возможности в последних релизах платформы, если справочники видны между расширениями, то  это очень хорошо

(7) "консоль запросов все видит" - Имеется ввиду конструктор запросов в конфигураторе? Потому что консоль запросов в предприятии вроде всегда видела все справочники всех подключенных расширений.

(9) ага, про конструктор речь вел

(9) Консоль запросов в режиме Предприятия всё видит, в режиме Конфигуратора конструктор запроса видит:
1. Основная конфигурация - Только Основная конфигурация
2. Расширение1 - Основная конфигурация + Расширение1
3. Расширение2 - Основная конфигурация + Расширение2
правильно?

(0) Новые объекты, информация в которых ценна и трудно восстанавливать (регистры с важными данными, документы) - в основную конфигурацию, а все остальное в расширения. Даже формы новых док-тов и справочников можно в расширения.

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

(11) Тут не подскажу.

(0) Реквизиты менять в основной конфигурации.
Формы основной конфигурации менять в расширении.
Формы менять программно, т.е. писать код по добавлению реквизитов. (просто стабильно работает, чем изменение мышкой в расширении)
У вас будет некий симбиоз. Как бы вы что-то изменили, и не изменили :)

(11) Если справочники будете добавлять в расширении, то словите баги работы с консолью запросов из обработок.

- Метаданные расширения не доступны из внешних обработок. (я тут про Запросы, СКД и другие работы в конфигураторе)
- Запросы потребуют от вас наличие ссылок на объект метаданных из основной конфигурации.
- не всё в консоли запросов обрабатывается корректно, которые написаны в расширении. Увы, есть баги и странное поведение консоли, которая запускается из текста модуля расширения. (запрос работает, а консоль ругается на ошибки)

+ (0) В расширении не все работают методы из основной конфигурации. Включая планы обменов, критерии отборов, нет доступа для добавления реквизитов в регистры сведений из расширения. Не работает в расширении и определяемые типы.

+(0) Камень в сторону БСП, она некорректно работает с расширением. Есть баги обработки настройки ролей для объектов из расширения.
Про РЛС в расширении тоже забудьте :)

А так, проект может жить и в расширении, всё зависит от того, он самостоятельный, или дополнение к основной конфигурации :)

(16)
Определяемые типы совсем не работают?

(17)
Совсем про РЛС забыть. Есть проблемы?

(0) Если конфигурация пилится для себя и не планируется её масштабирование на другие базы и/или продажа, то я придерживался бы следующего алгоритма.

0. Разумеется включаем возможность изменения конфигурации с установкой рекурсивно у всех объектов, начиная с корня, правила поддержки "Редактируется с сохранением поддержки". После каждого обновления не забывать устанавливать это правило поддержки для всех добавленных и измененных при обновлении объектов (в соответствующем диалоге, выскакивающем перед выполнением обновления, устанавливать переключатель).
1.  Все новые объекты метаданных (включая роли, общие модули, общие макеты пр. общие), а также новые реквизиты/измерения/ресурсы/табличные части/макеты/формы у существующих объектов конфы поставщика добавлять в самой конфигурации. Никаких расширений.
2. Вся логика работы ваших новых объектов тоже прописывать в самой конфигурации.
3. Подключаемые команды (обработки ввода на основании, обработки заполнения, печатные формы и все прочие отчёты и обработки, включая как самостоятельные так и подключаемые к объектам конфигурации и/или отображаемые на общих панелях), а так же то, что в стародавние времена делалось через внешние отчеты и обработки. Это всё делаем в расширении(ях). Стандартные подсистемы БСП позволяют это делать просто, прозрачно и понятно, с адекватной настройкой ролей и прав, а также встраиванием в командный интерфейс.
4. Доработка форм основой конфигурации поставщика. Если доработка относительна невелика, то делаем это в расширении, стараясь по максимуму использовать программные методы доработки форм (в идеале - только их). Если изменения значительные, то лучшим вариантом может быть не доработка существующей, а создание своей собственной формы. В таком случае свою форму помещаем в саму конфигурацию (расширение тут нафиг не нужно).
5. (Самая сложная часть). Доработка существующих объектов конфигурации поставщика. Какие доработки делать в расширении, а какие в самой конфе? Универсального и единственно верного ответа тут нет. Про добавление реквизитов/ресурсов/измерений/табличных частей и т.п. см. п.1 - добавляем всегда в самой конфе.
А дальше есть два сценария.
А) (пример) Мы решили переписать всю подсистему распределения и расчёта НДС при раздельном учёте. Это как минимум с десяток общих модулей, несколько десятков объектов (документов/справочников/регистров, их модулей, форм и модулей форм). Всё это в разных местах и разных подсистемах. А ещё регламентные процедуры закрытия, регламентированная отчетность и прочая фигня по мелочи, которая вылезет в непредсказуемых местах.
Такое я бы делал в основной конфе. Чтобы при каждом обновлении, когда вендор решит в очередной раз перетасовать все общие модули и в десятый раз перенести экспортные процедуры и функции из одних модулей/объектов в другие, я мог это видеть в окне трёхстороннего сравнения/объединения. Чтобы я имел возможность проанализировать сделанные вендором изменения и НАГЛЯДНО сравнить их с моими. Для крупномасштабных изменений это критически важно. Как бы аккуратно вы не делали доработки в расширении(ях) со всей документацией, после десятого обновления спустя пару лет удержать всё в голове невозможно. А даже самые идеальные тесты никогда не покрывают все 100%.
Б) Относительно небольшие изменения, не вмешивающиеся в какие-либо ключевые и очень сложные разделы и подсистемы учёта. Или эти вмешательства "сбоку" (назовём так) - то есть дополняют, но не ломают и не меняют типовое. Такие доработки лучше делать в расширениях.

В дополнение.
Особенности использования расширений (если доработка делается с их использованием)

Общие правила примерно такие (в порядке приоритета сценария от лучших к худшим):
- Если можно использовать модули с постфиксом Переопределяемый, то помещаем их в расширение и расширяем его процедуры с вызовом &После или &Перед.
- Если переопределяемых модулей нет или они не подходят и необходимо вмешиваться в обычные модули, то пытаемся в расширении расширять их методы с вызовом &После или &Перед
- Стараемся избегать расширения &Вместо. Непременно продолбаем тот момент, когда вендор что-то важное изменит в том модуле, который мы решили обходить "вместо". И хорошо если проблема вывалиться с ошибкой (например, изменилось количество или состав аргументов). Но в 90% таких случаев никакой программной ошибки не возникает. Косяк всплывает либо по заявке пользователя (где-то порушилась какая-то логика), либо при закрытии периода, когда не сходятся данные (не срослась логика изменённая вендором в обновлении с вашей доработкой, сделанной три года назад под старую логику).
- Стараемся избегать ИзменениеИКонтроль. Оно конечно лучше, чем вообще без контроля, но тоже нифига не всегда помогает разобраться в том что изменили и зачем, когда спустя пару лет вендор вдруг решил нахрен переписать всю процедуру, раздербанив её на несколько или наоборот объединив её с несколькими другими.
- Не плодим слишком много расширений. Отдельные расширения для подключаемых команд (обработки создания на основании, обработки заполнения, печатные формы, свои отчёты и обработки). Ещё отдельные расширения имеет смысл делать, (а) когда планируется тиражирование доработки (перенос на другие базы внутри компании, например) (б) доработка совсем уж "сбоку" - не использует механизмы самой конфигурации и не вмешивается в них. Во всех остальных случаях лучше делать все доработки в одном расширении. Разделять на несколько можно только те, которые точно никогда не пересекутся (по объектам, по логике, по подсистемам и т.д.). Отдельное расширение на каждую доработку кажется логичным и разумным. Но при значительных доработках (как в вашем случае) это со временем неизменно приводит к хаосу и конфликтам между расширениями.
- для временных исправлений (патчей) используем расширения. Не забываем их удалять после исправления ошибки в основной конфигурации.

Небольшие изменения - расширения.
Большие изменения - в основной конфе.

Ретрограды)

(2) "Скажем так, адаптация для отраслевика."
Купить отраслеву и не делать мозг.

(23) Они хотят продать, а ты им предлагаешь купить :))

(19) Нет, в расширении не позволяет редактировать из Основной конфигурации.

(20) Если сможешь из расширения использовать РЛС, напиши. У нас не вышло... Но мало ли, всё дело в сноровке :)