Как принять перенос данных: протокол сверки пользователей, записей, вложений, истории, комментариев и прав доступа

Что нужно проверить, прежде чем подписать акт о завершении миграции

Миграция данных технически заканчивается загрузкой, но принятой она становится только после сверки. Проверяют шесть блоков: пользователей и права входа, записи (сущности), вложения и файлы, историю изменений, комментарии и связанные сообщения, права доступа к объектам. Для каждого блока нужна не только количественная сверка (совпадает ли число записей), но и содержательная — по контрольным суммам, выборочной проверке значений и функциональному тестированию с участием бизнес-пользователей. В России дополнительно учитывают требования 152-ФЗ к месту хранения персональных данных и, для формализованных проектов, процедуру приёмочных испытаний по ГОСТ 34.603-92. Результат приёмки фиксируется отдельным документом — отчётом о сверке и актом, а не просто фактом «данные загружены».

Приёмка миграции — не то же самое, что сама миграция

Перенос данных из одной системы в другую — это техническая операция: выгрузка, трансформация, загрузка. Миграция в этом смысле не равна интеграции: интеграция поддерживает постоянный регулярный обмен, а миграция — разовый переход при смене системы, объединении источников данных или их очистке [1].

Именно вторая часть этого определения — «проверка качества и подтверждение результата» — на практике чаще всего пропускается. Команда переносит данные, видит, что интерфейс новой системы открывается, и считает проект закрытым. Но с точки зрения бизнеса миграция принята только тогда, когда есть отчёт сверки, список расхождений и исключений, подтверждение владельца данных о том, что перенесённый массив пригоден для работы, и понятное решение о судьбе исходной системы [1].

Логика здесь та же, что и в приёмке любого ИТ-проекта: комплект материалов должен позволять понять, что входило в объём работ, как это проверили, какие отклонения остались и как поддерживать результат дальше — иначе приёмка окажется спорной даже при внешне работающей системе [2]. Применительно к миграции это означает, что «отчёт о сверке» — не формальность, а часть комплекта, без которого нельзя доказать, что перенос выполнен полностью.

Без формальной приёмки расхождения обнаруживаются не в момент переноса, а спустя время в ходе обычной работы — когда менеджер не находит историю переписки по клиенту или сотрудник теряет доступ к нужной папке. По наблюдениям одного из отраслевых обзоров, значительная часть компаний сталкивается с ошибками миграции CRM не сразу, а через некоторое время после переноса — то есть уже после того, как старая система выключена и откат стал дорогим или невозможным [12].

Что входит в протокол сверки

Протокол сверки — это перечень объектов, которые проверяются после переноса, с описанием того, что именно считается совпадением, а что — расхождением, требующим исправления или отдельного решения.

Пользователи и учётные записи

При переносе учётных записей проверяют не только факт наличия пользователя в новой системе, но и сохранность его идентичности: единый идентификатор, привязку к ресурсам, к которым у него был доступ, и по возможности — непрерывность входа без принудительной смены пароля. Корректная миграция должна сохранять уникальный идентификатор безопасности пользователя, чтобы не терялся доступ к ресурсам, переносить учётные записи с сохранением паролей и одновременно обновлять права доступа к ресурсам [6].

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

Записи и сущности

Это ядро сверки — клиенты, сделки, заказы, документы, обращения и другие бизнес-объекты. Здесь недостаточно сравнить общее количество: нужно убедиться, что связи между сущностями не разорваны. Практика переноса данных между CRM показывает типичную проблему: сделка загружена, а привязанный к ней контакт потерян, потому что в выгрузке не было уникальных идентификаторов или порядок загрузки был нарушен — в результате запись «повисает» без понятной связи с клиентом или сотрудником [10]. Вторая типичная проблема — задвоение записей: при переносе нередко создаются повторяющиеся контакты и компании, особенно если в старой системе были небольшие расхождения в написании реквизитов [10].

Полноценный протокол сверки для CRM-данных начинается ещё до самого переноса — с аудита исходной базы: какие источники данных участвуют (таблицы, предыдущая CRM, учётные системы, почта, телефония), какие типы данных переносятся (контакты, компании, сделки, история коммуникаций) и какова доля дублей, пустых полей и записей с некорректным форматом [9]. Без этого исходного среза сверить результат после переноса намного сложнее — не с чем сравнивать.

Вложения и файлы

Файлы — договоры, сканы, изображения, письма с приложениями — нужно сверять не по названию, а по содержимому. Стандартный способ — сравнение контрольных сумм (хешей) исходного и перенесённого файла: контрольная сумма позволяет убедиться, что содержимое не было изменено при копировании, и для этого чаще всего применяют алгоритм SHA-256 как менее подверженный коллизиям по сравнению с устаревшим MD5 [18]. Отдельно проверяют: совпадает ли количество вложений по каждой записи, сохранились ли ссылки «запись → файл», не «потерялись» ли файлы большого размера при пакетной выгрузке.

История и журнал изменений

История изменений — кто, когда и что менял в записи — часто теряется при миграции первой, потому что многие системы хранят её не как обычные поля, а как отдельный технический журнал. Если история важна для бизнеса (например, для разбора спорных ситуаций с клиентом или для аудита), в протокол сверки закладывают отдельную проверку: сохранены ли даты создания и последнего изменения записей, а не заменены ли они датой самой миграции, и доступен ли журнал событий хотя бы в виде архива, если полный перенос истории технически невозможен.

Комментарии и связанные сообщения

Комментарии, внутренняя переписка и обращения клиентов — один из самых чувствительных участков, потому что именно в них хранится контекст работы с клиентом или проектом. Разбор реального случая внедрения CRM показывает: основная сложность обычно в том, чтобы сохранить не только структуру сделок, но и всю историю взаимодействия сотрудников — задачи, вложенные файлы, комментарии, — чтобы не потерять контекст и понимание хода работы [11]. В сверке проверяют: привязку комментария к правильной записи и автору, сохранность хронологического порядка и корректность дат — иначе переписка в новой системе будет выглядеть хаотично.

Права доступа

Права доступа проверяют отдельно от факта переноса самих данных, потому что ошибка здесь не всегда заметна сразу — сотрудник может продолжать работать, даже если фактически видит больше или меньше, чем должен. При переносе общих ресурсов ключевые риски таковы: лишние группы неожиданно получают доступ к конфиденциальным папкам; нужные группы теряют доступ из-за нарушенного наследования прав или утраченных идентификаторов безопасности; часть прав выглядит нормально, но отдельные вложенные папки после переноса «живут своей жизнью» [5]. Хорошая практика — до переноса зафиксировать матрицу «кто к чему имеет доступ» в исходной системе и после миграции сверить её построчно, а не полагаться на визуальный осмотр интерфейса [5].

Как технически устроена сверка

Количественная сверка

Первый и самый простой уровень проверки — сравнение количества записей в источнике и в целевой системе по каждому типу объектов. Это быстро обнаруживает грубые потери (не перенеслась целая категория записей), но не гарантирует, что содержимое записей корректно — совпадение чисел ничего не говорит о качестве самих данных.

Контрольные суммы и хеширование

Более строгий уровень — сравнение хеш-сумм файлов и наборов данных до и после переноса, что позволяет выявить не только пропажу данных, но и их незаметное искажение — например, обрезание длинных текстовых полей или потерю кодировки в отдельных символах. Важно разделять два разных вопроса: полноту данных (ничего не потерялось) и их точность (значения в целевой системе действительно совпадают с исходными, а не просто присутствуют) — это разные проверки, и контрольная сумма закрывает в первую очередь вопрос полноты и целостности, а не смысловой корректности [15].

Сверка по бизнес-правилам и выборочная проверка

Полная построчная сверка миллионов записей не всегда возможна по времени и стоимости, поэтому применяют выборочную проверку — случайную статистическую выборку записей с детальным сравнением полей [13]. Отдельно проверяют не только техническую целостность, но и содержательное качество: соответствуют ли данные в целевой системе бизнес-логике — суммы совпадают с ожидаемыми итогами, статусы соответствуют реальному состоянию сделки или заявки [14].

Приёмочное тестирование (UAT) и параллельный прогон

Финальный уровень — тестирование с участием реальных бизнес-пользователей, которые выполняют типовые рабочие сценарии и подтверждают, что перенесённые данные пригодны для работы; их подписанное согласование становится итоговой контрольной точкой проверки [13]. Дополнительно применяют параллельный прогон: старую и новую систему запускают одновременно на ограниченный период и сравнивают результаты по реальным операциям [13]. Это единственный уровень проверки, который может обнаружить проблемы, невидимые для автоматических скриптов — например, что перенесённые комментарии технически на месте, но потеряли читаемую связь с контекстом обращения.

Российская специфика

152-ФЗ, локализация и трансграничная передача

Если миграция связана с переносом персональных данных клиентов или сотрудников в облачную или зарубежную систему, нужно отдельно проверить требование локализации. С 1 июля 2025 года действует обновлённая редакция части 5 статьи 18 закона о персональных данных: установлен прямой запрет на сбор, хранение, обновление и извлечение персональных данных граждан РФ с использованием баз данных, расположенных за пределами территории России, — раньше это было обязанностью оператора, теперь требование распространено и на обработчиков, действующих по его поручению [7].

При этом само требование не запрещает трансграничную передачу данных, которые уже были собраны и хранятся в базах на территории России: по разъяснениям Роскомнадзора и Минцифры 2025 года, обновлённая норма ограничивает именно первичный сбор и хранение, а не последующую передачу ранее локализованных данных за рубеж [8]. Для миграции это означает, что выбор целевой платформы (в частности, зарубежного облачного сервиса для первичного хранения) стоит сверять с этим требованием заранее, а не после переноса.

ГОСТ 34.601/34.603 — приёмочные испытания

Для государственных информационных систем и в проектах, где заказчик требует формальной процедуры приёмки, применяется отраслевой стандарт: испытания автоматизированной системы проводятся на стадии ввода в действие с целью проверки соответствия требованиям технического задания [3]. Протоколы испытаний по всей программе обобщаются в едином протоколе, на основании которого делают заключение о соответствии системы требованиям и оформляют акт приёмки в постоянную эксплуатацию [3]. Для миграции данных как части такого проекта это означает, что протокол сверки логично оформлять как один из протоколов испытаний, а не как неформальный технический отчёт «для своих».

Акт приёма-передачи данных

Отдельного законодательно утверждённого бланка для акта о приёмке перенесённых данных не существует — унифицированной и обязательной к применению формы акта приёма-передачи в целом нет, если только её применение не закреплено договором между сторонами [19]. На практике это значит, что форму акта — с перечнем сверенных объектов, зафиксированными расхождениями и подписью ответственного за приёмку — стоит согласовать до начала миграции, а не придумывать по факту завершения работ.

Варианты организации приёмки

• Полная автоматизированная сверка. Скрипты сравнивают количество записей, контрольные суммы и ключевые поля по всем объектам без выборки. Подходит, когда данных немного или система позволяет быстро прогнать сверку без остановки работы.
• Гибридная сверка (автоматика + выборка + UAT). Автоматическая проверка закрывает количественный и структурный уровень, выборочная проверка — содержательный, а бизнес-пользователи подтверждают пригодность данных для реальной работы. Наиболее сбалансированный вариант для большинства проектов.
• Параллельный прогон (parallel run). Старая и новая система работают одновременно ограниченный период, результаты сравниваются на реальных операциях [13]. Даёт максимальную уверенность в идентичности поведения систем, но требует дополнительных ресурсов на поддержку двух систем сразу.
• Поэтапная приёмка по частям. Данные и права переносятся и принимаются блоками (например, сначала пользователи и права, затем записи, затем вложения), что снижает риск на каждом шаге, но растягивает проект по времени.

Практические этапы протокола сверки

1. Провести аудит исходных данных. Определить источники, типы данных и объём по каждому типу, оценить долю дублей и некорректных значений ещё до начала переноса [9].
2. Зафиксировать состав объектов и права доступа. Матрица «пользователь — роль — доступ», перечень типов записей, количество вложений, наличие истории и комментариев — исходная точка сравнения, без которой сверка превращается в догадки.
3. Согласовать критерии совпадения. Что считается расхождением: любое несовпадение поля или только критичные поля; допустима ли потеря части истории при документированном ограничении.
4. Выполнить тестовый перенос на копии. Сверка на тестовом контуре до переноса «в бою» позволяет обнаружить системные ошибки заранее, а не после отключения исходной системы.
5. Провести количественную и хеш-сверку. Сравнить число записей и контрольные суммы файлов и наборов данных по каждому типу объектов.
6. Провести выборочную содержательную проверку. Случайная выборка записей вручную или скриптом — на совпадение значений полей, связей и дат.
7. Провести приёмочное тестирование с бизнес-пользователями. Реальные сотрудники выполняют типовые операции и фиксируют замечания.
8. Проверить права доступа построчно. Сверить матрицу доступа «до» с фактическим доступом «после» — не только у себя, но выборочно у пользователей с расширенными правами.
9. Оформить отчёт о расхождениях и акт приёмки. Зафиксировать, что перенесено полностью, что перенесено с ограничениями и что не подтверждено, с подписью ответственного лица.
10. Принять решение о судьбе исходной системы. Хранить в режиме архива, отключить или удалить — с учётом требований к срокам хранения, если данные персональные.

Ограничения, ошибки и риски

• Отсутствие плана отката. Хороший план миграции определяется тем, что он переживает первую реальную проблему без необходимости переписывать процесс с нуля, а контрольные точки и проверку целостности данных нужно фиксировать заранее, до переноса [16]. План отката — не то же самое, что резервная копия: он должен заранее описывать, кто принимает решение об откате и по каким критериям, иначе на практике откат почти никогда не бывает быстрым и спокойным [17].
• Ручная дообработка исключений. По оценке одного из отраслевых материалов, ни одна автоматизированная миграция не обходится без исключений: около 0,5–2% записей с аномалиями обычно приходится обрабатывать вручную по логам [4]. Это единичная оценка, а не подтверждённый двумя независимыми источниками показатель, поэтому её стоит воспринимать как ориентир, а не норматив.
• Разрыв связей между сущностями и дубли. Частая причина — отсутствие уникальных идентификаторов в выгрузке или нарушенный порядок загрузки объектов [10].
• Потеря контекста истории и комментариев. Технически данные «на месте», но без правильной привязки к автору, дате и записи они теряют практическую ценность [11].
• Незаметные ошибки прав доступа. Пользователь может продолжать работать месяцами, не замечая, что видит чужие данные или, наоборот, не видит нужные — если сверка прав не проводилась построчно [5].
• Формальная приёмка без содержательной проверки. Подписанный акт при непроверенных данных не защищает бизнес — расхождения обнаруживаются позже, когда исходная система уже выключена.

Как выбрать подход к приёмке

Объём и глубина протокола сверки зависят от того, насколько критичны данные для бизнеса и насколько формализован проект. Для внутреннего переноса небольшой базы в CRM может быть достаточно автоматической количественной и выборочной сверки силами штатного администратора. Для миграции с персональными данными, финансовыми записями или в рамках проекта с заказчиком, требующим формальной приёмки, целесообразны отдельный протокол сверки, приёмочные испытания и акт с подписью ответственного за данные лица. Единого правильного ответа нет: решение зависит от объёма данных, требований регуляторов к конкретной отрасли и от того, насколько критична для бизнеса непрерывность истории и прав доступа.

Как может помочь «Пятый фактор»

Проектирование протокола сверки, техническая реализация выгрузки, сопоставления и загрузки данных, а также настройка сверки по контрольным суммам и бизнес-правилам — это задачи, требующие понимания структуры конкретных систем-источника и назначения. Команда «Пятого фактора» может изучить состав переносимых данных, оценить возможные варианты переноса и сверки и помочь с разработкой скриптов сопоставления, интеграцией между системами или технической консультацией по протоколу приёмки.

Если задача связана с переносом сайта на другую платформу, в практике компании есть кейс такого переноса без потери позиций в поиске — решение о полноценном переносе принималось в ситуации, когда текущая платформа была принципиально не способна закрыть бизнес-задачи [20]. А в интеграционных проектах компании применяется отдельный протокол сверки данных и журнал загрузок как часть контроля качества обмена, включающий журнал загрузок, протокол сверки рейсов и инструкцию по контролю данных и повторной обработке [21].

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

Вывод

Перенос данных и приёмка переноса — разные события. Технически завершённая миграция без протокола сверки — это риск, который проявится не сразу, а спустя время в ходе обычной работы, когда откатить изменения будет уже дорого или невозможно. Рабочий протокол сверки закрывает шесть предметных областей — пользователей, записи, вложения, историю, комментарии и права доступа — и опирается на несколько уровней проверки: от простого сравнения количества записей до контрольных сумм, выборочной содержательной проверки и приёмочного тестирования с участием бизнес-пользователей. В российском контексте к этому добавляются требования 152-ФЗ к месту хранения персональных данных и, для формализованных проектов, процедура приёмочных испытаний по ГОСТ. Итог приёмки должен быть зафиксирован документально — отчётом о расхождениях и актом, а не только фактом, что интерфейс новой системы открылся.

Источники

[1] robotbull.com — Миграция данных между системами: план, проверка и подтверждение результата — https://robotbull.com/handbook/infrastruktura-i-avtomatizatsiya/migratsiya-dannyh-mezhdu-sistemami

[2] robotbull.com — Проверка комплектности документации перед приемкой ИТ-проекта — https://robotbull.com/handbook/proektirovanie-i-otsenka/proverka-komplektnosti-dokumentatsii-pered-priemkoy

[3] docs.cntd.ru — ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем» — http://docs.cntd.ru/document/1200008642

[4] puzzle-rpa.ru — Миграция данных: что такое миграции в программировании и в БД — https://puzzle-rpa.ru/blog/migraciya-dannyh-chto-takoe-migracii-v-programmirovanii-i-v-bd

[5] gse.kz — Миграция общих папок: план переноса и контроль прав — https://gse.kz/blog/migraciya-obshchih-papok-acl-plan

[6] docs.inno.tech — Миграция данных между доменами — https://docs.inno.tech/ru/directory-service/latest/description/migration/

[7] law.ru — Новые правила хранения персональных данных за рубежом с 1 июля 2025 года — https://www.law.ru/article/28545-zapret-na-hranenie-personalnyh-dannyh-za-granitsey-s-1-iyulya-2025-goda

[8] comply.ru — Локализация и трансграничная передача персональных данных. Что изменилось с 1 июля 2025 года? — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[9] d7-crm.ru — Как перенести данные в CRM — миграция без потерь — https://d7-crm.ru/migratsiya-dannyh-v-crm/

[10] intervolga.ru — Как перенести данные в Битрикс24: миграция из другой CRM — https://www.intervolga.ru/faq/bitrix24/migratsiya-na-bitriks24-kak-perenesti-dannye-iz-drugoy-crm/

[11] completo.ru — Основные ошибки при внедрении CRM и как их избежать — https://www.completo.ru/blog/articles/osnovnye-oshibki-pri-vnedrenii-crm-i-kak-ikh-izbezhat-razbiraem-realnyy-keys/

[12] project-a2.ru — Миграция данных: 5 типичных ошибок, которые теряют деньги и время — https://project-a2.ru/blog/data-migration-5-common-mistakes/

[13] quinnox.com — Data Migration Validation Best Practices for 2026 — https://www.quinnox.com/blogs/data-migration-validation-best-practices/

[14] quinnox.com — Data Reconciliation: Best Practices, Challenges & Use Cases — https://www.quinnox.com/blogs/data-reconciliation/

[15] datafold.com — Data reconciliation: Technical best practices — https://www.datafold.com/blog/data-reconciliation-best-practices/

[16] habr.com — Непосредственно миграция: искусство безболезненного переезда — https://habr.com/ru/companies/icore/articles/994416/

[17] hirehi.ru — План отката релиза: что DevOps готовит до выкладки в прод — https://hirehi.ru/blog/plan-otkata-reliza-chto-dolzhen-podgotovit-devops-do-vykladki-v-prod

[18] winitpro.ru — Проверка контрольной (хеш) суммы файла в Windows — https://winitpro.ru/index.php/2024/09/24/proveit-hash-summu-fajla-windows/

[19] sekretariat.ru — Образец акта приема-передачи документов — https://www.sekretariat.ru/article/211032-qqq-17-m8-akt-priema-peredachi-dokumentov

[20] 5factor.ru — Перенос сайта на другую CMS без потери SEO — https://5factor.ru/resources/perenos-sayta-na-druguyu-cms-bez-poteri-seo

[21] 5factor.ru — Интеграция Wialon с 1С или TMS — https://5factor.ru/uslugi/integracii-i-avtomatizaciya/integraciya-wialon-1c-tms/