Большинство статей о миграции с SharePoint описывают её как проект с двумя чёткими состояниями: «до» и «после». Вот вы работаете в SharePoint — вот уже в новой системе. На практике это не так. Между «до» и «после» существует третье состояние, которое может длиться месяцами: обе системы работают в проде одновременно, пользователи работают в обеих, а данные могут меняться в любой из них.
Именно это третье состояние и создаёт самый неприятный класс проблем. И именно о нём — эта статья.
Реальная хронология миграции
Классический план «перенести всё за выходные» ломается об одну простую вещь: списки SharePoint — это не контент, который можно скопировать и забыть. Это живые данные. Пока вы переносите список контрагентов, кто-то уже добавил нового клиента. Пока вы тестируете новый портал с пилотной группой, остальные сотрудники продолжают обновлять заявки, реестры и справочники в старой системе.
В итоге типичная хронология выглядит примерно так:
-
Месяц 1–2: новый портал разворачивается, настраивается базовая структура
-
Месяц 2–4: пилотная группа работает в новом портале, остальные — в SharePoint
-
Месяц 4–8: постепенное расширение охвата по подразделениям
-
В какой-то момент: «окончательный» cutover и отключение SharePoint
На этапах 2–4 живёт главная боль: данные в SharePoint меняются, пользователи нового портала должны их видеть — и желательно в нём же их редактировать, не возвращаясь в старую систему.
Список «Контрагенты» в Microsoft SharePoint Online. Данные физически хранятся здесь — пока.
Есть и второй момент, про который думают меньше: что происходит с данными в момент отключения SharePoint? Если новый портал до этого работал только как витрина поверх старых данных — в день cutover вы получаете пустую систему. Все данные остались там, куда больше нет доступа.
Proxy как мост — и его ограничения
Раньше я писал о технической реализации Proxy Object Storage в Инкоманд: как с помощью кастомного ObjectEntryManager и Microsoft Graph API мы научили объектную модель портала прозрачно читать и писать данные из списков SharePoint.
Настройка маппинга списка SharePoint на объект Инкоманд.
Здесь не повторяю — только то, что из этого следует на практике.
Те же данные в интерфейсе Инкоманд. Источник пока внешний. CRUD работают напрямую через Graph API.
Proxy — это мост, а не конечное состояние. Его задача — снять боль параллельной работы двух систем. Но когда SharePoint уходит, данные должны уже находиться в собственном хранилище нового портала — иначе в день cutover получаем пустую систему.
Это означает, что архитектура миграции должна изначально закладывать три этапа:
[Фаза 1] SharePoint как источник истины → прокси-объекты в новом портале
[Фаза 2] Дельта-миграция → данные переносятся в нативное хранилище
[Фаза 3] SharePoint отключается → объекты переключаются на внутреннее хранилище
Архитектура двусторонней работы: UI-виджеты в Инкоманд → ObjectEntryManager → Microsoft Graph API → списки SharePoint. После дельта-миграции объект переключается на нативное хранилище без изменения UX.
Если пропустить фазу 2 или сделать её в последний момент — получаем то самое «окно риска», которого хочется избежать.
UI — это не косметика: почему важен выбор формата отображения
Когда список SharePoint появляется в новом портале через прокси, перед аналитиком встаёт вопрос, который кажется второстепенным: в каком формате его отображать? На самом деле от этого выбора зависит, станет ли новый портал рабочим инструментом или останется «ещё одной витриной». В демонстрационном кейсе видно три основных варианта:
Таблица — оптимальна для реестров, справочников и журналов, где важна плотность информации и возможность быстрой сортировки/фильтрации. Список контрагентов, реестр договоров, журнал проверок — сюда.
Коллекция (карточки) — работает там, где важна карточка объекта как единица восприятия, а не строка таблицы. Каталог продуктов, список сотрудников с фото и контактами, база знаний — карточный формат.
Канбан — нужен, когда у объектов есть состояния и важен workflow. Заявки, задачи, этапы согласования — канбан даёт сразу видеть распределение по статусам и перемещать записи через drag-and-drop.
Ключевой момент: эти форматы работают не только для просмотра. Пользователь может переместить заявку на другой столбец канбана — и это изменение напрямую запишется в SharePoint через Graph API. Открыть карточку в коллекции и отредактировать поле — тоже запись в источник.
Именно это отличает настоящую двустороннюю интеграцию от витрины данных.
Канбан-представление списков SharePoint в Incomand (данные те же)
Почему read-only не работает для миграции
На первый взгляд кажется, что для переходного периода достаточно просто отобразить данные из SharePoint в новом портале — пусть даже read-only. Пользователи привыкнут к новому интерфейсу, а редактировать пока будут в старой системе.
На практике это убивает adoption нового портала.
Если за любым изменением нужно переключаться обратно в SharePoint — у пользователя не формируется привычка работать в новой системе. SharePoint остаётся «настоящим местом работы», а новый портал воспринимается как дополнительная нагрузка. Пилотный запуск затягивается, обратная связь по UX не накапливается, сроки cutover сдвигаются.
Полноценная двусторонняя работа решает это: с первого дня пользователи выполняют реальные рабочие операции в новом интерфейсе. Создают записи, редактируют поля, меняют статусы. При этом источником истины остаётся SharePoint — изменения сразу попадают туда. Это убирает страх «потерять данные» при переходе и даёт команде проекта время спокойно готовить фазу 2.
Что важно для enterprise: безопасность, производительность, переиспользуемость
Proxy-интеграция с SharePoint — не учебный прототип. Чтобы она работала в корпоративном контексте, нужно пройти несколько обязательных требований.
Безопасность и права доступа
OAuth 2.0 client_credentials даёт серверный доступ к SharePoint от имени приложения — это значит, что проверка прав конкретного пользователя лежит целиком на стороне нового портала. Каждая CRUD-операция проходит через модель доступа Инкоманд: пользователь без прав на объект не получит данные из SharePoint, даже если в самом SharePoint доступ у него есть. На переходном этапе, когда роли в двух системах ещё не синхронизированы — это важный контрольный рубеж.
Производительность
Два основных bottleneck — аутентификация и разрешение ID сайта — решаются стандартным кешированием (детали в предыдущей статье). Из нестандартного: Graph API для list items не поддерживает $skip, поэтому общий счётчик записей в списке недоступен точно — только оценка «не менее N». Для рабочих сценариев переходного периода это приемлемо.
Переиспользуемость и настраиваемость
Архитектура через ObjectEntryManager и ERC даёт важное свойство: один коннектор — множество объектов. Подключили SharePoint-сайт один раз в настройках — дальше каждый новый список просто создаётся как объект в UI, без кода. Администратор заполняет ERC для объекта (имя списка) и для каждого поля (имя колонки) — и прокси работает.
Scope конфигурации GROUP позволяет разным сайтам портала подключаться к разным SharePoint-сайтам. Это важно для организаций, где у разных подразделений — разные SharePoint-окружения.
Если завтра понадобится аналогичный прокси для другой внешней системы — структура остаётся той же: новый ObjectEntryManager с новым storage.type, новая фабрика фильтров. Модель данных портала не меняется.
Финальный шаг: как данные покидают прокси
Когда портал стабилизирован, пользователи работают в новом интерфейсе, а команда проекта готовится к отключению SharePoint — нужно завершить фазу 2: перенести данные из SharePoint в нативное хранилище Инкоманд.
Это делается через дельта-миграцию: читаем все записи из прокси-объекта, создаём их как нативные объекты, затем переключаем тип хранилища с sharepoint на default. Поскольку модель данных объекта уже описана (те же поля, те же типы, тот же маппинг через ERC) — перенос сводится к итерации по записям и записи их в новое хранилище.
В момент переключения пользователи не видят разницы: те же виджеты, те же форматы отображения, те же права. Меняется только то, куда уходят запросы — в базу портала вместо Graph API.
После этого SharePoint можно отключать. Данные уже здесь.
Что в итоге
Proxy Object Storage — не серебряная пуля и не вечное решение. Это инструмент, который закрывает конкретную задачу: дать пользователям единую точку входа с первого дня нового портала, не требуя переносить все данные до запуска.
Рабочая схема выглядит так:
-
Прокси запускается рано — пользователи привыкают к новому интерфейсу, работая с реальными данными
-
Двусторонняя запись обеспечивает, что SharePoint остаётся актуальным без ручной синхронизации
-
Дельта-миграция делается поздно, но до cutover — когда модель данных уже стабилизирована
-
Cutover становится административным событием, а не техническим
Для команды, которая управляет таким проектом, это означает, что «день икс» отключения SharePoint перестаёт быть страшным дедлайном. К тому моменту данные уже давно живут там, где должны.
Технические детали реализации Proxy Object Storage — OAuth, CRUD через Graph API, конвертация фильтров и работа с пагинацией — я описывал в предыдущей статье. Видео с демонстрацией сценария — в блоге Инкоманд.
ссылка на оригинал статьи https://habr.com/ru/articles/1045925/