Переход с ДО 2.1 на ДО 3.0: как мигрировать без остановки документооборота

Переход с ДО 2.1 на ДО 3.0 — это не обновление релиза, а миграция данных в новую конфигурацию: создаётся пустая база 3.0, и данные из 2.1 переносятся в неё штатным механизмом миграции через обмен. Пока в 2.1 не завершены все процессы, обе базы работают параллельно. На средней базе проект занимает несколько месяцев, на крупной одна только загрузка может растянуться на месяцы. Основные риски — нехватка места на дисках, медленная загрузка рабочих групп, затирание настроек 3.0 данными из 2.1 и разрыв интеграций с ERP, ЗУП и БП.

Ниже — что важно решить и подготовить до старта, где проект обычно буксует и когда выгоднее внедрить 3.0 с нуля, а не тащить в неё всё из 2.1. Про отличия самих редакций я писал отдельно — в сравнении ДО 2.1 и 3.0 в блоге.

Почему это проект, а не «ночное обновление»

В 3.0 иначе устроены права доступа, работа с документами и файлами, процессы. Поэтому:

• нельзя запланировать переход на выходные и в понедельник работать в новой версии;
• нужно заранее решить, какие данные и процессы действительно нужны в 3.0;
• нужно готовить пользователей и ИТ, а не только технически переносить базу.

Если воспринимать миграцию как обычное обновление, высок риск остановить согласования на несколько дней или перенести в новую систему все старые проблемы вместе с техническим долгом.

Как устроена миграция данных

Перенос идёт в несколько этапов: сначала выгружаются исторические данные, потом изменения с момента старта миграции, затем изменения, которые пользователи вносят в 2.1, догружаются почти онлайн.

Что из этого следует на практике:

• Место на дисках. База 3.0 растёт сразу после включения миграции. База 2.1 тоже растёт: она запоминает, что уже выгружено и что изменилось после выгрузки (подсистема отметок времени). На больших объёмах рост 2.1 может быть кратным. Обе базы живут одновременно, плюс резервные копии — считайте место заранее.
• Сжатие таблиц. В процессе загрузки данные в 3.0 постоянно перезаписываются, а платформа физически освобождает место не сразу. Периодическое сжатие таблиц информационной базы помогает держать размер под контролем.
• Выгрузка быстрее загрузки. Пакеты копятся в очереди. Если объект меняли несколько раз, он выгрузится и загрузится несколько раз — с тем же итогом, что и от последнего пакета. Выгрузку изменений можно ставить на паузу, отключая регламентное задание, но держите в очереди небольшой запас пакетов, чтобы загрузка не простаивала.
• Оценка оставшегося времени обманчива. Миграция показывает прогноз по средней скорости, а разные типы данных грузятся с очень разной скоростью. Проекты, где закладывали неделю, а загрузка шла несколько месяцев, — не редкость.

Главный тормоз — рабочие группы

Больше всего времени при загрузке съедают рабочие группы — списки участников, определяющие доступ к объекту в 3.0. Загрузка устроена так, что при добавлении каждого следующего участника перезаписываются уже загруженные, и чем больше группа, тем медленнее идёт запись.

Самая неприятная ситуация — документы без заполненных рабочих групп, где доступ в 2.1 вычислялся по политикам. Если в политике указана группа «все пользователи», для 3.0 рабочая группа рассчитается со всеми пользователями базы. Для сотни пользователей это незаметно, для нескольких тысяч загрузка одного документа может занимать часы.

Что я рекомендую сделать до старта:

1. Проверить политики доступа и заранее заполнить рабочие группы для объектов доступа там, где расчёт даст огромные списки.
2. Найти и исправить «битые» документы, например с незаполненным видом документа. Регламентное задание, которое рассчитывает рабочие группы для перехода, обрабатывает документы порциями; если в порцию раз за разом попадают документы, для которых расчёт даёт пустой результат, задание фактически зацикливается.
3. Следить, что расчёт рабочих групп реально продвигается, а не крутится на одних и тех же объектах.

Ловушки, о которых узнают слишком поздно

Изменения, которые не попадают в выгрузку

Запись данных в режиме ОбменДанными.Загрузка = Истина (обработки загрузки, обмены, часть доработок) не регистрируется как изменение для миграции. Такие данные молча не доедут до 3.0. Решение — регистрировать отметки времени вручную в доработках или снять запрет регистрации в подписках на события. Я придерживаюсь правила: любое изменение в 2.1 во время миграции должно быть зарегистрировано и загружено в 3.0.

Настройки 3.0 затираются данными из 2.1

Схемы процессов, шаблоны файлов, дополнительные реквизиты, скрипты почти всегда приходится адаптировать под 3.0. Если в это время продолжается перенос изменений этих объектов из 2.1, любая правка в старой базе перезапишет вашу работу в новой. Как только начинается адаптация, отключайте миграцию изменений по соответствующим метаданным.

Зависшие процессы

Отключить миграцию можно только после завершения всех процессов, запущенных в 2.1. Старые «вечные» задачи, про которые все забыли, держат проект. Ревизию незавершённых процессов делайте до старта, а не в конце.

Интеграции с ERP, ЗУП, БП

Здесь сюрпризов больше всего, и их стоит обсудить с владельцами учётных систем заранее.

• Нельзя редактировать документы ДО из интегрированной базы. В 2.1 это было возможно, в 3.0 из ERP или БП можно перейти по ссылке в документооборот и прикладывать файлы, а правки делаются уже в ДО.
• Теряются связи со старыми документами. В обмене объект внутреннего документа в 2.1 и 3.0 описан под разными именами (DMInternalDocument и DMDocument), поэтому интеграция с 3.0 «не видит» связей, созданных при работе с 2.1, хотя сами данные в учётной базе сохранились. Варианты решения: создать копии записей о связях с новым идентификатором (сохраняется возможность вернуться к 2.1), исправить идентификатор в существующих записях или доработать интеграцию в каждой учётной системе, чтобы она понимала оба имени.
• Интеграция рассчитана на одну базу ДО. Учётная система работает либо с 2.1, либо с 3.0. Пока миграция не завершена, часть объектов, пришедших из 2.1, нельзя изменить из интегрированной системы.

Если интеграций много, имеет смысл вынести их в отдельный подпроект с собственным тестированием — это то, что я делаю в рамках интеграции 1С с СЭД.

Пять ошибок, которые затягивают переход

1. Перенос всего подряд. Неиспользуемые виды документов, старые маршруты, мёртвые сценарии переезжают в 3.0 и усложняют её.
2. Работа в 3.0 «как в 2.1». Без перепроектирования прав, ролей и хранения файлов новые возможности остаются невостребованными, а система работает не лучше старой.
3. Слепой перенос доработок. Вместе с ними переезжает технический долг, а обновлять 3.0 снова становится тяжело.
4. Запуск для всех сразу, без пилота. Ошибки проявляются у всей компании одновременно.
5. Выбор метода переноса по удобству ИТ. Без учёта объёма архива, важности истории согласований и интеграций.

Пошаговый план перехода

Обновлять 2.1 до последнего релиза перед стартом стоит обязательно: в каждом релизе исправляют ошибки механизма миграции. Рассылку уведомлений об ошибках загрузки настройте сразу — ошибки надо разбирать в тот же день, а не копить.

Миграция или внедрение 3.0 с нуля

Иногда выгоднее не переносить логику 2.1, а внедрить 3.0 как новую систему и перенести только критичные документы.

Сроки и бюджет зависят от объёма базы, количества доработок и интеграций, поэтому честная оценка возможна только после диагностики. Для ориентира: диагностику и пробную миграцию я оцениваю по почасовой ставке 2 500 ₽/ч, а дальнейший план строится уже на реальных замерах скорости загрузки. Подробнее о формате работ — на странице перехода на 1С:Документооборот 3.0.

Самая дорогая ошибка при переходе на ДО 3.0 — поверить, что это обновление. Это проект с пилотом, замерами и решением о том, что оставить в прошлом.

Коротко

• ДО 2.1 не обновляется до 3.0: данные мигрируют в новую базу, обе работают параллельно.
• Заранее посчитайте место, подготовьте рабочие группы и закройте старые процессы.
• Изменения в режиме загрузки не попадают в миграцию — регистрируйте их явно.
• Интеграции с ERP, ЗУП, БП требуют перенастройки и восстановления старых связей.
• Пробная миграция и пилот дают реальный срок; без них план — догадка.