Когда компания начинает уходить с Microsoft SharePoint, самая частая проблема связана не с дизайном портала и не с новостной лентой, а с рабочими данными: списками контрагентов, заявками, внутренними реестрами, каталогами и другими сущностями, на которых держатся повседневные процессы. Полностью отключить старую систему за один день обычно нельзя, потому что бизнесу нужен непрерывный доступ к данным, привычным сценариям работы и корректно настроенным правам доступа.

Именно поэтому плавная миграция с SharePoint становится не компромиссом, а рабочей стратегией. Инкоманд в этом сценарии выступает как российская альтернатива Microsoft SharePoint и Microsoft Viva, которая позволяет не только строить новый корпоративный портал на отечественном стеке, но и подключать внешние источники данных, сохраняя для пользователей единое рабочее пространство. Один из самых практичных сценариев такого перехода — отображение и редактирование списков SharePoint прямо в интерфейсе Инкоманд.

Рассмотрим подробнее на примере демонстрационного кейса:

Почему списки SharePoint мешают миграции больше всего

В SharePoint списки часто используются как прикладной слой: в них живут заявки, справочники, карточки контрагентов, учёт договоров, журналы проверок и десятки других рабочих сущностей. Поэтому миграция корпоративного портала упирается не только в перенос страниц и документов, но и в корректное сохранение структуры списков, полей, связей, прав и пользовательских сценариев.

Именно на этом этапе многие компании сталкиваются с ложным выбором. Первый путь — долго держать SharePoint как основной рабочий контур и откладывать переход. Второй — пытаться перенести всё сразу, создавая окно риска, в котором страдают бизнес-процессы, доступность данных и пользовательский опыт. На практике устойчивее работает третий сценарий: новый портал запускается на Инкоманд, а критичные списки SharePoint временно остаются внешним источником данных, доступным в новом интерфейсе.

Плавная миграция: что это означает на практике

В ранее опубликованном материале Инкоманд о бесшовном переходе с SharePoint описан подход, при котором миграция начинается с инвентаризации текущих сайтов, списков, библиотек, полей и контент-типов, затем проектируется целевая модель данных, а после этого строится миграционный конвейер: экспорт, трансформация, импорт и делта-перенос изменений. Такой подход важен потому, что корпоративный портал почти всегда приходится переводить поэтапно, а не одним релизом в выходные.

Для бизнеса плавная миграция означает простую вещь: сотрудники уже начинают работать в новом портале, но не теряют доступ к данным, которые пока физически находятся в старой системе. Для ИТ это означает контролируемый переход: можно запускать пилотные зоны, переносить сайты и разделы волнами, отдельно отрабатывать права, маппинг полей и интеграции, а затем выполнять дельта-миграции перед окончательным отключением SharePoint.

Именно в такой модели Инкоманд особенно полезен как российский корпоративный портал. Платформа развивает сценарии самостоятельной сборки прикладных решений, работы с данными через объекты, канбан-доски и таблицы, а также ориентирована на замещение SharePoint и Viva в российском контуре. В результате миграция превращается не в разовый проект по «перекладке контента», а в последовательное создание нового цифрового пространства поверх уже существующих данных и процессов.

Какую роль в этом играет Инкоманд

Инкоманд 7.4 усилил позицию продукта как российской альтернативы Microsoft SharePoint и Microsoft Viva: в релизе появились «Объекты Инкоманд», новые форматы работы с данными в виде досок и таблиц, улучшенные витрины контента, сценарии самообслуживания и расширенные интеграционные возможности. Для миграции это важно по двум причинам: во-первых, платформа даёт новый пользовательский слой, в который можно постепенно переводить сотрудников; во-вторых, она позволяет строить прикладные сервисы без ожидания длительной разработки под каждую сущность.

Если упростить, Инкоманд в таком проекте может выполнять сразу три роли. Первая — целевой корпоративный портал на российском стеке. Вторая — единая точка входа для сотрудников, которые больше не должны помнить, в какой системе физически лежат данные. Третья — прикладной слой, через который внешние списки и реестры можно подключать, отображать и постепенно переносить в новый контур.

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

Proxy Object Storage: почему не обязательно сначала переносить данные

В статье на Хабре мы рассказали о том, как для Инкоманд реализован механизм Proxy Object Storage для отображения списков SharePoint в корпоративном портале. Главная идея этого подхода заключается в том, что объектная модель портала может работать не только с собственной базой, но и с внешним хранилищем, выступая в роли единого интерфейса к данным.

Для миграционного проекта это даёт важное преимущество: критичные данные можно не копировать в спешке и не дублировать без необходимости. Пока SharePoint ещё остаётся источником истины, Инкоманд уже может выступать фронтом для чтения и изменения этих данных, а значит, пользователи привыкают к новому интерфейсу раньше, чем завершится полный перенос.

С точки зрения архитектуры это лучше, чем временные «костыли» с ручной синхронизацией, выгрузками по расписанию и отдельными интерфейсами для разных отделов. Proxy Object Storage делает внешний список частью модели данных Инкоманд, а не сторонним виджетом без бизнес-логики.

ERC как связующее звено между SharePoint и Инкоманд

В демонстрации ключевую роль играет ERC, External Reference Code. Для объекта его значение должно совпадать с именем списка в Microsoft SharePoint, а для каждого поля — с именем соответствующего столбца в исходном списке. За счёт этого объект в Инкоманд получает понятное и управляемое сопоставление с внешней структурой данных.

Практический смысл ERC в миграции очень большой. Он позволяет не «зашивать» интеграцию глубоко в код конкретного сценария, а строить управляемую модель соответствия между сущностями двух систем. Это упрощает настройку, документирование, тестирование и последующий перенос данных в собственное хранилище Инкоманд, когда компания будет к этому готова.

Для ИТ-команды это ещё и удобный контракт между аналитикой и реализацией. Есть объект в целевой системе, есть поля, есть внешний список и его колонки, и между ними описано явное соответствие. Именно такой подход обычно и требуется при поэтапной миграции, когда нужно сначала стабилизировать модель данных, а уже потом окончательно менять источник хранения.

Как это выглядит в Инкоманд: сценарий из видео

В опубликованном видео показывается типовая ситуация: у компании уже есть портал на базе SharePoint, но она внедряет новый портал на платформе Инкоманд и не может остановить старую систему одномоментно. Поэтому задача формулируется прагматично: сделать так, чтобы ключевые списки, например список контрагентов, были доступны пользователям прямо в Инкоманд уже на переходном этапе.

Сначала в разделе «Сторонние библиотеки» настраивается подключение к SharePoint Online. Для этого указываются Tenant ID, Client ID, адрес сайта и секрет для подключения. Важно, что такие параметры можно задавать отдельно для каждого сайта Инкоманд, а значит, разные разделы портала или разные подразделения могут обращаться к своим источникам данных без создания общей громоздкой схемы.

После этого в панели управления создаётся новый объект. В качестве типа хранения выбирается SharePoint, то есть данные объекта физически остаются в списке SharePoint, а не записываются в базу портала Инкоманд. Затем для объекта и его полей задаются ERC, после чего администратор настраивает представление: выбирает поля, фильтры, сортировку, группировку и другие параметры показа данных.

Готовое представление размещается на нужной странице портала, например в разделе «Продажи и дистрибуция». В результате в интерфейсе Инкоманд появляется таблица, которая показывает данные из списка SharePoint так, как если бы это был внутренний реестр самого портала. При этом можно использовать не только таблицу, но и другие форматы, включая канбан или коллекцию, если они лучше подходят под задачу конкретного подразделения.

Важный момент: это не read-only витрина

Ценность такого сценария в том, что он не ограничивается отображением данных. В видео показано, что пользователь может изменить запись в Инкоманд, сохранить её и затем увидеть эти изменения в самом списке SharePoint после обновления страницы. Это значит, что интеграция работает в обе стороны и подходит не только для просмотра, но и для реальной операционной работы.

Для переходного периода это особенно важно. Если новый корпоративный портал умеет только читать старые данные, пользователям всё равно приходится возвращаться в SharePoint для редактирования. Тогда единое окно не возникает, а внедрение нового интерфейса замедляется. Когда же создание и изменение элементов доступны прямо в Инкоманд, сотрудники начинают работать в новой среде сразу, даже если источник хранения пока ещё внешний.

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

Что это даёт бизнесу во время миграции

Для бизнеса основной эффект состоит в том, что переход перестаёт выглядеть как болезненное переключение между двумя несвязанными мирами. Сотрудники получают один интерфейс в Инкоманд, а команда проекта может постепенно выводить SharePoint из роли пользовательского фронта и переводить его в роль временного источника данных.

Это снижает и организационные, и технологические риски. Можно запускать новый портал сначала для пилотной группы, затем расширять охват, обучать пользователей поэтапно и собирать обратную связь до момента полного cutover. Такой сценарий хорошо согласуется с рекомендациями по адаптации сотрудников к новому интранету: MVP, пилотный запуск, постепенное расширение и донастройка по реальному использованию работают лучше, чем попытка сразу включить весь функционал для всех сотрудников.

Кроме того, у компании появляется пространство для принятия решений. Не все списки нужно переносить одномоментно и не все вообще нужно сохранять в прежнем виде. Когда данные уже доступны в Инкоманд, можно спокойно решать, что переносить как есть, что переосмыслить в виде новых объектов, а что заменить более современными прикладными сервисами на российской платформе.

Что это даёт ИТ-команде

Для ИТ функция отображения списков SharePoint в Инкоманд — это не просто интеграционный сценарий, а способ выстроить контролируемую траекторию миграции. Команда может отдельно пройти этапы инвентаризации, маппинга полей, настройки модели доступа, пилотного переноса и делта-синхронизаций, не заставляя бизнес ждать «идеальной конечной системы».

Также снижается давление на разработку. Благодаря объектной модели Инкоманд и развитию no-code сценариев многие реестры, формы и прикладные интерфейсы можно собирать быстрее, чем при классическом подходе с кастомной доработкой каждого сервиса. Это особенно важно в проектах импортозамещения, где сроки часто жёсткие, а объем унаследованных процессов очень большой.

Отдельный плюс — технологическая независимость. Инкоманд развивается как российский корпоративный портал с ориентацией на отечественную инфраструктуру и российски-дружественный стек, включая OpenSearch вместо Elasticsearch. Поэтому миграция с SharePoint здесь решает не только UX- и интеграционную задачу, но и более широкую задачу снижения санкционных и эксплуатационных рисков.

Пошаговый сценарий: сначала интеграция, потом перенос

Если перевести этот подход в практическую схему проекта, он может выглядеть так.

1. Проводится инвентаризация текущего SharePoint-ландшафта: сайты, списки, библиотеки, поля, права, владельцы данных и частота использования.

2. В Инкоманд проектируется целевая структура портала, роли, сайты, разделы и модель объектов для тех сущностей, которые будут нужны пользователям в первую очередь.

3. Для критичных списков подключается внешний доступ через объектную модель Инкоманд: настраиваются соединение с SharePoint, ERC, представления и права.

4. Пользователи начинают работать в новом интерфейсе Инкоманд, а команда проекта наблюдает за использованием, корректирует модель и обучает подразделения.

5. После стабилизации сценария выполняется перенос данных в целевое хранилище там, где это необходимо, и SharePoint постепенно выводится из эксплуатации как пользовательская среда.

Такая траектория особенно подходит крупным российским организациям, где корпоративный портал — это не просто медиа-площадка, а слой ежедневной операционной работы. В этой логике Инкоманд выступает не только как альтернатива SharePoint, но и как инструмент достижения самой цели миграции: непрерывности бизнеса, управляемости проекта и перехода на российскую платформу без хаоса.

Где этот сценарий особенно полезен

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

• Когда нужно быстро запустить новый корпоративный портал на российской платформе, но ключевые списки SharePoint ещё не готовы к переносу.

• Когда важно сохранить единое пользовательское окно и не заставлять сотрудников переключаться между SharePoint и новым интранетом.

• Когда компания переносит систему поэтапно: сначала пилот, затем делта-миграции, затем окончательное отключение старой платформы.

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

На российском рынке есть и другие решения, которые рассматриваются в проектах замещения SharePoint, например Битрикс24 или корпоративные порталы на заказной разработке. Но именно Инкоманд в этом контексте интересен тем, что совмещает портал, объектную модель, сценарии no-code, работу с контентом и интеграционную архитектуру в одном продукте, ориентированном на российский контур и поэтапный переход с SharePoint.

Что важно предусмотреть заранее

Чтобы такой сценарий действительно работал, проект миграции лучше изначально строить не как «перенос страниц», а как работу с моделями данных, интерфейсами и ролями. Практически это означает несколько обязательных шагов.

Во-первых, нужно провести полноценную инвентаризацию списков и договориться, какие из них становятся объектами в Инкоманд, а какие будут архивироваться или пересматриваться. Во-вторых, необходимо явно описать сопоставление полей и справочников, чтобы не потерять смысл данных при переходе между системами. В-третьих, важно заранее определить, какие сценарии пользователи должны выполнять в новом портале уже на первом этапе: только просмотр, полноценное редактирование, создание новых записей, запуск связанных процессов.

Наконец, нельзя забывать про обучение и коммуникацию. Даже удачная техническая интеграция не даст эффекта, если сотрудники будут продолжать воспринимать SharePoint как «настоящее место работы», а Инкоманд — как ещё одну витрину рядом. Поэтому плавная миграция должна сочетать технический контур, пользовательский сценарий и программу адаптации персонала.

Почему этот сценарий хорошо ложится на стратегию импортозамещения

Для многих российских компаний вопрос уже не сводится только к удобству портала. Использование систем без вендорской поддержки в России создаёт эксплуатационные и санкционные риски, а значит, переход на российские платформы становится частью общей ИТ-стратегии. Но переход должен быть не просто «патриотичным», а технологически реалистичным.

Именно здесь сценарий с отображением списков SharePoint в Инкоманд особенно ценен. Он позволяет перевести пользователей в новый российский корпоративный портал без искусственного дедлайна на полный перенос всех данных за один этап. Инкоманд в такой модели становится не только конечной платформой импортозамещения, но и рабочим инструментом самой миграции — точкой, где бизнес уже получает пользу, пока ИТ ещё завершает переходный контур.

Что дальше

Если рассматривать опубликованное видео не как отдельную демонстрацию функции, а как часть общей архитектуры перехода, становится видно главное: Инкоманд позволяет не ждать завершения всей миграции, чтобы начать работать в новой среде. Списки SharePoint можно подключить к объектной модели портала, отобразить в привычных форматах, встроить в разделы нового интранета и использовать в операционной работе уже на первом этапе внедрения.

Для компаний, которые строят российский корпоративный портал как замену SharePoint и Viva, это один из самых практичных сценариев старта. Он снижает риски, упрощает адаптацию пользователей и создаёт основу для следующего шага — постепенного переноса данных, сервисов и процессов в собственный контур Инкоманд.