Зачем думать о «бесшовном» переходе заранее

Миграция с SharePoint — это всегда вмешательство в ядро корпоративной цифровой среды: структуру контента, права доступа, интеграции, автоматизацию процессов. Ошибки здесь приводят не только к неудобствам, но и к юридическим рискам, потере истории и нарушению ИБ. Российские компании все чаще переводят свои корпоративные системы с SharePoint на отечественные решения (такие как Инкоманд) именно из‑за санкционных ограничений, отсутствия поддержки и рисков с хранением данных за рубежом.

Что именно надо сохранить при миграции

При проектировании миграции важно явно описать целевой «контракт» на уровне данных и API: что именно считается сохранённым, а что допустимо изменить.

Ключевые сущности SharePoint, которые нужно учитывать:

• Структура сайтов:
  • Site Collection, под-сайты (subsites), HUB-сайты (в SharePoint Online).
  • Навигация (top navigation, quick launch).
• Структура контента:
  • Библиотеки документов и списки.
  • Фолдеры, наборы документов (Document Sets).
  • Контент-типы (Content Types) и сайты-коллекции контент-типов.
• Метаданные и схемы:
  • Столбцы (site columns, list columns), типы данных, lookup-поля.
  • Управляемые метаданные (Managed Metadata), term sets, taxonomy.
  • Версионность, статусы публикации, черновики.
• Безопасность и доступы:
  • Группы SharePoint, группы и роли Active Directory / Azure AD.
  • Наследование прав, уникальные ACL на уровне сайтов, списков, элементов.
  • Модели доступа: «по проекту», «по отделу», «по роли», «по документу».
• Процессы и интеграции:
  • Workflows (Classic, Power Automate), события списков.
  • Интеграции с внешними системами (CRM, 1С, Service Desk).
• Аудит и история:
  • Журнал версий элементов.
  • Логи аудита (кто и что менял, кто скачивал, кто открывал).

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

Техническая модель миграции: уровни и API

1. Модель данных: сопоставление сущностей

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

Пример базового сопоставления:

Задачей архитектора является формализовать эту карту в виде таблиц и конфигурации миграционного инструмента, чтобы выгрузка через SharePoint API и загрузка через API целевой системы были строго детерминированы.

2. API-слой: чтение из SharePoint

Для чтения структур и данных SharePoint используются несколько основных наборов API:

• REST API (/_api/web/...) или Microsoft Graph:
  • Структура сайтов и списков.
  • Метаданные (site fields, content types, columns).
  • Элементы списков, файлы и версии.
• CSOM/PowerShell (Pnp.PowerShell и др.):
  • Глубокий аудит структуры, нестандартные настройки.
  • Bulk-выгрузки, обход лимитов по размеру, пакетные операции.
• Migration API:
  • Для массовой передачи файлов и их свойств (но чаще используется для миграций в SharePoint, а не «из него»).

Практический подход для миграции «из SharePoint» в Инкоманд:

1. Метаданные и схемы — через REST/Graph и PowerShell-скрипты.
2. Структура сайтов — через REST (/_api/web/webs, /_api/web/navigation).
3. Контент — через REST/CSOM с постраничной выборкой и фильтрами по ID или по времени изменения.
4. Права — через REST/CSOM, выгрузка RoleAssignments и групп.

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

3. API-слой: загрузка в Инкоманд

Инкоманд предоставляет API/SDK для:

• Создания типовых объектов (справочники, документы, задачи).
• Управления полями, представлениями и таксономиями.
• Загрузки файлов и версий.
• Управления пользователями, группами, ролями и ACL.
• Запуска и переноса процессов.

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

Как сохранить структуру данных

Шаг 1. Инвентаризация объектов и метаданных

Рекомендуется сделать отдельный «инвентаризационный» проход по SharePoint:

• Собрать список всех Site Collections и сайтов с признаками активности (последняя дата изменения).
• Выгрузить перечень списков и библиотек, их типов, столбцов и контент-типов.
• Оценить объем данных (количество элементов, суммарный размер в ГБ).
• Выделить критичные области:
  • Документы с юридической значимостью.
  • Проектные пространства.
  • Регламенты и политики.
  • Архивные разделы (для отдельной обработки).

Результат — технический каталог: что, где и в каком объеме хранится. Он станет основой для картирования в целевой портал.

Шаг 2. Проектирование целевой модели (target schema)

Затем проектируется целевая модель данных:

• Группировка списков и библиотек по бизнес-сущностям:
  • Например, из нескольких списков SharePoint формируется один комплексный объект «Заявка» в Инкоманд.
• Унификация полей:
  • Приведение типов данных (Single line → String, Choice → enum, Lookup → связь).
  • Выделение общих справочников (организационная структура, проекты, контрагенты).
• Дизайн таксономии:
  • Перенос управляемых метаданных в дерево категорий целевой платформы.
  • Привязка документов к этим категориям.

В Инкоманд это соответствует проектированию «объектов» и их связей в no-code конструкторе, что позволяет потом использовать эти же сущности и в интерфейсах, и в бизнес-процессах, и в BI-отчетности.

Шаг 3. Миграция контента с сохранением связей

Ключевые технические приёмы:

• Стабильные идентификаторы:
  • Сохраните исходный ID SharePoint-элемента в отдельном поле целевой системы (например, sp_item_id).
  • Аналогично — UniqueId файла и ListId/WebId для возможных перекрестных ссылок.
• Оригинальные пути:
  • Храните исходный URL (sp_source_url) и относительный путь (server_relative_url) для последующей трассируемости.
• Связи списков:
  • Lookup-поля в SharePoint мигрируйте в связи объект–объект (через сохранённые идентификаторы).
• Версионность:
  • При наличии требования по версийности:
    • Либо переносите только последнюю версию, но сохраняйте метаданные об истории.
    • Либо проигрывайте версии последовательно через API целевой системы (если она поддерживает версионирование документов, как Инкоманд), применяя даты и авторов изменений.

Чтобы избежать коллизий и «обрыва связей», миграцию удобнее выполнять в два этапа:

1. Основной массив данных (без заполнения lookup-ссылок).
2. Постобработка: проход для восстановления ссылок и зависимостей по сохраненным ID.

Как сохранить модель доступов и безопасность

Проблема «уникальных прав» в SharePoint

SharePoint позволяет легко «порвать наследование прав» на любом уровне: сайт, список, папка, элемент. На больших инсталляциях это приводит к десяткам тысяч уникальных ACL, которые сложно переносить и поддерживать. Microsoft сама рекомендует ограничивать число уникальных ACL на сайте, иначе страдает производительность и управляемость.

Если перенести эту «хаотичную» модель прав в новую систему, получится также дорогое и слабоуправляемое решение. Поэтому в миграционном проекте важно:

• Проанализировать структуру ACL:
  • Сколько уникальных ACL на сайтах, списках, элементах.
  • Какие группы и роли реально используются.
• Выделить повторяющиеся паттерны:
  • «Отдел → раздел портала → одинаковые права».
  • «Проект → проектный сайт → однотипная роль модели».
• Сформировать целевую модель:
  • Роли и группы (Business Owner, Editor, Reader, External).

Технический подход к переносу прав

API SharePoint позволяет выгружать назначения ролей (RoleAssignments) и группы, к которым они применяются. В целевой системе (Инкоманд) важно:

1. Сначала перенести и объединить пользователей / группы:
   • Сопоставить учетные записи AD/Azure AD со справочником пользователей целевой системы.
   • Создать (или переиспользовать) роли и группы, аналогичные по смыслу SharePoint-группам.
2. Затем перенести модель доступа на уровне объектов:
   • Определить правила, какие ACL в SharePoint переводятся в какие ACL в новой системе.
   • Преобразовать «уникальные» права в наследуемые права по роли/группе.
3. Исключить использование индивидуальных прав «на пользователя»:
   • Заменять их назначением на роли, чтобы снизить фрагментацию модели доступа.

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

Пошаговый технический гайд по миграции API/данных SharePoint

Этап 1. Предпроектный аудит и архитектура

• Соберите мультидисциплинарную команду:
  • Архитектор ИТ-систем.
  • Представители ИБ и комплаенса.
  • Владелец бизнес-портала.
  • Представитель подрядчика или вендора (например, команды Инкоманд).
• Проведите архитектурную сессию:
  • Определите объекты миграции (какие сайты и разделы).
  • Набросайте целевую архитектуру портала (структура разделов, основных объектов, процессов).
  • Согласуйте требования к доступности и окнам простоя.

Этап 2. Инвентаризация SharePoint через API

• Разработайте или используйте готовый скрипт-инвентаризатор:
  • Обходит все Site Collections.
  • Выгружает списки, библиотеки, количество элементов, набор полей и контент-типов.
  • Фиксирует последний доступ и изменения.
• Формируйте результаты в структурированном виде:
  • CSV/JSON для последующей загрузки в аналитические инструменты.
  • В идеале — отдельное временное хранилище/базу для работы с моделью.

Этап 3. Дизайн целевой модели и маппинг

• На основе инвентаризации:
  • Определите типы объектов в целевой системе (Incomand «Объекты», сущности в других платформах).
  • Опишите сопоставление полей, типов данных, справочников.
• Заложите будущие интеграции:
  • Если SharePoint был связан с 1С, CRM или другими системами, продумайте точки интеграции с новой платформой, чтобы не потерять связность процессов.

Этап 4. Подготовка целевой платформы

• Разверните целевую систему в требуемом контуре:
• Настройте базовую структуру:
  • Сайты, разделы, навигация.
  • Типы объектов, поля, справочники.
  • Базовую модель ролей и групп.
• Реализуйте API-шлюз для миграции:
  • Набор скриптов/микросервис, который принимает выгруженные данные и создаёт объекты/документы в портале.
  • Логи и мониторинг для отслеживания ошибок.

Этап 5. Разработка и тестирование миграционного «конвейера»

• Соберите конвейер миграции:

1. Экспорт из SharePoint: - Скрипты/утилиты выгружают данные и файлы в промежуточное хранилище (файловое, BLOB, БД).
2. Трансформация: - Скрипты маппинга конвертируют структуры, поля, значения справочников.
3. Импорт в целевой портал: - API целевой системы создаёт объекты, загружает файлы, назначает права.

• Проведите пилотный перенос:
  • Выберите один типовой сайт или отдел.
  • Протестируйте полный цикл: данные, интерфейсы, права, процессы.
  • Исправьте выявленные проблемы до масштабирования.

Этап 6. Основная миграция и «делта»

• Выполните основную миграцию по плану:
  • Поэтапно переносите группы сайтов/разделов.
  • Контролируйте производительность и влияние на пользователей.
• Реализуйте делта-миграции:
  • Перенос изменений, сделанных в SharePoint в период между основным переносом и «днём X».
  • Возможен режим «контент-фриз» на финальной фазе (запрет изменений).

Этап 7. Верификация, обучение и вывод из эксплуатации

• Проверка:
  • Автоматические тесты целостности (количество объектов, наличие файлов, значения ключевых полей).
  • Ручная приемка от ключевых бизнес-подразделений.
• Обучение:
  • Гайды, инструкции, вебинары по работе в новом портале.
• Деактивация SharePoint:
  • После успешного запуска — перевод SharePoint в режим «только чтение» и дальнейшая консервация/вывод из эксплуатации.

Типовые ошибки и как их избежать

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