Миграция с SharePoint ломается не на финальном cutover, а в «третьем состоянии» — когда старый и новый портал

Миграция с SharePoint ломается не на финальном cutover, а в «третьем состоянии» — когда старый и новый портал живут параллельно.

Что там происходит:
1) Пользователь правит документ в старом контуре.
2) Через 5 минут другой человек меняет ту же сущность в новом.
3) Репликация, очереди, коллизии, разные timestamps — и у вас уже не миграция, а гонка состояний.

Технически это проблема не интерфейса, а консистентности данных:
- источник истины становится неочевидным;
- delta-sync начинает конфликтовать с ручными правками;
- audit trail распадается между системами;
- rollback без правил дедупликации превращается в лотерею.

Нормальный план миграции должен закрывать не «до/после», а overlap-window:
- фиксировать, где write-master;
- считать лаг синхронизации;
- логировать конфликтные записи;
- заранее определить, что делаем при дублях и расхождениях 🧩

Если этого нет, портал можно поднять быстро. Данные — нет.