Как мигрировать с SharePoint на Инкоманд в крупной российской компании
Представьте себе компанию, где на SharePoint за десять с лишним лет «нарос» целый город из порталов, сайтов и библиотек: каждый департамент строил свой дом, иногда поверх чужого, иногда рядом, иногда вообще в другом конце карты. В какой‑то момент стало ясно: город надо не латать, а перестраивать — и делать это уже на российской платформе. Так началась история перехода на Инкоманд.
Как всё начиналось: SharePoint, который вырос из себя
Внутренний мир компании жил на Microsoft SharePoint:
- десятки, а по факту уже больше сотни сайтов и подсайтов;
- несогласованные дизайны и навигация от подразделения к подразделению;
- исторические решения, которые никто не решался трогать, «чтобы не сломать»;
- плотная завязка на экосистему Microsoft и растущие санкционные риски.
В какой‑то момент у руководства сложилась простая, но неприятная картина: ключевая внутренняя платформа завязана на зарубежного вендора, а бизнес‑процессы, знания и коммуникации живут в хрупкой конструкции, которую сложно развивать и ещё сложнее — защитить от внешних факторов.
Нужен был новый фундамент — российский, управляемый, с перспективой на годы вперёд. Здесь в роли главного претендента и появился Инкоманд: low‑code/no‑code платформа, которая умеет делать ровно то, ради чего когда‑то внедряли SharePoint, но уже на отечественном технологическом стеке, да ещё и с опытом миграции у крупных заказчиков.
Цель: не просто «переехать», а сделать единую Корпоративную Платформу
Команда не ограничилась задачей «перенести всё как есть». Решили сыграть по‑крупному — построить Корпоративную Платформу на базе Инкоманд и постепенно «переселить» туда весь портальный ландшафт.
Что это означало на практике:
- масштаб — перенос более сотни сайтов и десятков терабайт данных;
- амбиций — не дублировать старую архитектуру, а собрать более логичную, цельную картину;
- ответственности — портал теперь воспринимается как «цифровое рабочее место» для десятков тысяч сотрудников, а не просто «место, где лежат документы».
Инкоманд тут выступает как «конструктор города»:
- на бекенде — Jakarta EE, модульность через OSGI, процессы на Flowable (BPMN, CMMN, DMN), поиск на OpenSearch;
- на фронтенде — гибкие интерфейсы, виджеты и фрагменты страниц, из которых можно собирать и классический интранет, и витрины сервисов, и сложные личные кабинеты;
- внизу — поддержка отечественного стека: Astra Linux, Postgres Pro, AxiomJDK, российские Kubernetes‑платформы и т.п.
Шаг 1. Разобраться в «городе» SharePoint
Первое, что сделала команда — остановилась и внимательно посмотрела, чем именно стало решение на SharePoint.
Сюрпризов было немало:
- сайты, которые все считали «критичными», на деле почти не открывались;
- наоборот, маленькие «временные» решения превратились в ключевые сервисы;
- одни и те же функции реализованы по‑разному в разных филиалах;
- интеграции с внешними системами — от HR до документооборота — местами жили по неформальным договорённостям между командами.
На этом этапе сделали несколько важных вещей:
- составили карту всех порталов, их владельцев, аудиторий и интеграций;
- честно оценили, что нужно переносить «один в один», а что — проще и разумнее пересобрать с нуля;
- выделили настоящие «ядра» портальной жизни (новости, услуги, документы, витрины знаний, сервисы для сотрудников).
Шаг 2. Спроектировать новый дом на Инкоманд
Дальше начался самый интересный этап — проектирование. Если на SharePoint много решений росло снизу, то для Инкоманд архитектуру рисовали сверху:
- придумали общую концепцию Корпоративной Платформы: единый вход, единый поиск, общая дизайн‑система, понятная навигация;
- договорились, что платформу строят не только ИТ, но и HR, внутренние коммуникации и бизнес‑подразделения — именно тут Инкоманд удобно ложится как точка сборки HR, IT и коммуникаций на одной платформе;
- определили шаблоны: типовой сайт подразделения, витрина сервиса, лендинг проекта, база знаний, личный кабинет и т.д.
Инкоманд здесь хорошо играет роль «набор LEGO»:
- объектная модель и конструктор приложений позволяют быстро собирать сущности (документы, заявки, справочники, новости) и их связи;
- конструктор интерфейсов и фрагменты страниц помогают привести всё к единому стилю, но не убить гибкость;
- BPM‑движок и интеграционный слой дают возможность перенести сложные цепочки согласований и сервисных процессов.
Шаг 3. Подготовить площадку: инфраструктура и интеграции
Прежде чем переносить хоть один байт со старой платформы, команда развернула Инкоманд в боевой конфигурации:
- подняли кластеры в продуктивном и тестовом контурах, настроили отказоустойчивость;
- сконфигурировали доступ: SSO, интеграция с Active Directory/LDAP, Kerberos/NTLM, роли, группы, матрица прав;
- подключили ключевые системы — от кадрового контура и сервисов самообслуживания до документооборота, ITSM и BI‑решений.
Задача была простая по формулировке и сложная по реализации: пользователь не должен чувствовать, что «где‑то далеко» есть много разных систем. Он приходит на портал Инкоманд и видит одно цельное цифровое пространство.
Шаг 4. Миграция: как переносили сотни сайтов и десятки терабайт
Миграция шла волнами. И это важно: не было ночи, когда выключили SharePoint, включили Инкоманд и понадеялись, что всё будет хорошо.
Волна за волной
Сценарий выглядел примерно так:
- Выбирается группа сайтов на SharePoint, которые логично перенести вместе (например, порталы одного блока бизнеса).
- Команда делает аналитику: какие функции действительно нужны, что можно убрать, что объединить.
- В Инкоманд собирается целевой функционал — иногда «один в один», но чаще чуть лучше и проще, чем было.
- Документы и данные переносятся с сохранением структуры и прав; рабочие процессы переписываются на BPMN; формы — в конструктор интерфейсов.
- Пользователям дают время поработать в новом интерфейсе, собрать обратную связь, поправить шероховатости.
- Старый сайт переводят в read‑only, потом отключают.
Что переносили особенно осторожно
- Документы — критично сохранить не только сами файлы, но и метаданные, историю, права доступа.
- Согласования и процессы — многие бизнес‑процессы за годы работы успели обрасти нюансами; при переносе на BPM-движок Инкоманд часть логики было проще формализовать заново, избавившись от «случайных» костылей.
- Интеграции — не все внешние системы были готовы сразу переехать на новые API, поэтому часть связей приходилось переводить аккуратно, через промежуточные слои и адаптеры.
Шаг 5. Люди, обучение и «принятие» платформы
Любой портал живёт не на серверах, а в головах людей. Поэтому параллельно с техническими работами шла большая история про обучение и принятие.
Команда делала:
- понятные гайды и короткие видео о том, как теперь решать привычные задачи в новом интерфейсе;
- встречи с подразделениями, где показывали, как Инкоманд помогает быстрее «доставлять» до сотрудников сервисы, новости и документы;
- программы для редакторов контента и владельцев сервисов, чтобы они чувствовали себя не «заложниками ИТ», а полноправными создателями цифровой среды.
Low‑code‑подход Инкоманд здесь сыграл ключевую роль: многие вещи можно настроить силами продвинутых бизнес‑пользователей и команды портала, не включая тяжеловесный процесс разработки. Это сильно сокращает время между «есть идея» и «сотрудник уже видит новый сервис на экране».
Итог: одна платформа вместо зоопарка решений
Когда волны миграции прошли, а SharePoint остался в прошлом, внутри компании сложилась новая реальность:
- единая портальная экосистема вместо разрозненных островков;
- оцифрованный, предсказуемый путь сотрудника к основным сервисам, документам и знаниям;
- российская платформа в основе, без жесткой зависимости от зарубежного вендора и с поддержкой отечественной инфраструктуры.
Не случайно именно этот проект на базе Инкоманд стал для российской ИТ‑отрасли своеобразным маркером: крупная компания показала, что импортозамещение в портальной сфере — это не «компромисс с функционалом», а возможность сделать лучше, чем было.
Что полезно взять из кейса другим компаниям
Если упростить опыт до практических выводов, получится несколько тезисов:
- Миграция — это шанс на уборку и редизайн, а не только на смену платформы. Не жалейте старые решения, которые давно никому не нужны.
- Инкоманд и аналогичные российские платформы позволяют строить полноценные корпоративные порталы и цифровые рабочие места масштаба холдинга с импортонезависимым стеком и богатым набором конструкторов.
- Успех держится на триаде HR–IT–Коммуникации. Если проект ведёт только ИТ, будет «технически правильно, но неудобно». Инкоманд хорош именно там, где над платформой совместно работают ИТ, HR и внутренние коммуникации.
- Не пытайтесь перенести всё сразу. Волновой подход и живой диалог с пользователями сильно уменьшают сопротивление и повышают качество результата.