Миграция с SharePoint без окна риска: двусторонняя работа с данными в новом портале, пока старый ещё живёт

Вот важная новость с фронта ИИ: akakunin 2 минуты назад Миграция с SharePoint без окна риска: двусторонняя работа с данными в новом портале, пока старый ещё живёт Средний 6 мин 13 SharePoint * CMS * Java * ECM/СЭД * Веб-разработка * Обзор Большинство статей о миграции с SharePoint описывают её как проект с двумя чёткими состояниями: «до» и «после». Вот вы работаете в SharePoint — вот уже в новой системе. На практике это не так.

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

Технические детали

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

В итоге типичная хронология выглядит примерно так:Месяц 1–2: новый портал разворачивается, настраивается базовая структураМесяц 2–4: пилотная группа работает в новом портале, остальные — в SharePointМесяц 4–8: постепенное расширение охвата по подразделениямВ какой-то момент: «окончательный» cutover и отключение SharePointНа этапах 2–4 живёт главная боль: данные в SharePoint меняются, пользователи нового портала должны их видеть — и желательно в нём же их редактировать, не возвращаясь в старую систему. Список «Контрагенты» в Microsoft SharePoint OnlineСписок «Контрагенты» в Microsoft SharePoint Online. Данные физически хранятся здесь — пока.

Есть и второй момент, про который думают меньше: что происходит с данными в момент отключения SharePoint? Если новый портал до этого работал только как витрина поверх старых данных — в день cutover вы получаете пустую систему. Все данные остались там, куда больше нет доступа.

Отраслевые последствия

Proxy как мост — и его ограниченияРаньше я писал о технической реализации Proxy Object Storage в Инкоманд: как с помощью кастомного ObjectEntryManager и Microsoft Graph API мы научили объектную модель портала прозрачно читать и писать данные из списков SharePoint. Настройка маппинга списка SharePoint на объект ИнкомандНастройка маппинга списка SharePoint на объект Инкоманд. Здесь не повторяю — только то, что из этого следует на практике.

Те же данные в интерфейсе ИнкомандТе же данные в интерфейсе Инкоманд. Источник пока внешний. CRUD работают напрямую через Graph API.

Proxy — это мост, а не конечное состояние. Его задача — снять боль параллельной работы двух систем. Но когда SharePoint уходит, данные должны уже находиться в собственном хранилище нового портала — иначе в день cutover получаем пустую систему.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.