Миграция обычно рисуется как флажок: старую систему выключили, новую включили. В жизни так не бывает. Чаще ест

Миграция обычно рисуется как флажок: старую систему выключили, новую включили. В жизни так не бывает. Чаще есть третье состояние: SharePoint ещё жив, новый портал уже в проде, и люди шлют изменения туда, где им удобнее.

Для агентства это не «техническая особенность». Это прямой риск по срокам, марже и допработам.

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

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

Если этого нет в бюджете, миграция почти всегда съест маржу. Не потому что «сложный проект», а потому что никто не посчитал третье состояние.