Миграция с SharePoint редко выглядит как «выключили старое — включили новое».

Миграция с SharePoint редко выглядит как «выключили старое — включили новое».

Реальный сценарий: старый портал ещё жив, новый уже в проде, а пользователи пишут и там, и там.
Это не этап перехода. Это окно риска.

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

Что нужно было сделать:
1. Ввести правило: где создаётся запись, там и считается master-источник.
2. Ограничить типы изменений в старой системе.
3. Настроить двустороннюю синхронизацию только для критичных полей.
4. Зафиксировать SLA на обновление данных и эскалацию расхождений.
5. Отдельно прописать сценарий, что делать при конфликте версий.

Результат простой: миграция перестаёт быть бинарной.
Управляем не «переездом», а периодом, где обе системы живут параллельно без потери контроля. 🧭