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

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

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

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

Что забирать в свою воронку/продуктовый процесс:
— не считать cutover бинарным событием;
— заранее проектировать двустороннюю работу с данными;
— вводить метрики рассинхрона: % конфликтов, latency синка, число ручных правок;
— ограничивать параллельный режим по сроку и по владельцу данных.

Миграция без метрик расхождений — это не релиз, а лотерея 🎯