Чек-лист миграции EDMS

Чек-лист перед миграцией для переноса архива технических документов с общих дисков или устаревшей EDMS без потери целостности версий — сбоя, который превращает миграцию в новый источник замечаний аудита вместо исправления старого.

До начала миграции

• [ ] Статус текущей версии каждого документа подтверждён в исходной системе до экспорта — миграция неоднозначной проблемы «какая версия текущая» просто переносит её на новое место.
• [ ] Полная история ревизий (не только последняя версия) включена в объём экспорта по каждому документу — миграция, сохраняющая только последнюю ревизию, разрушает прослеживаемость.
• [ ] Метаданные (тип документа, дисциплина, класс хранения, история утверждений) сопоставлены поле за полем с новой системой до переноса первого файла — а не восстанавливаются потом из имён файлов.
• [ ] Явно принято решение об объёме перехода: новые и активно редактируемые документы переносятся первыми; исторический архив мигрирует поэтапно, по модулям. Миграция всего архива «одним махом» не требуется для начала контроля новых документов.

Во время миграции

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

После миграции

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

Почему это важно

Плохое качество данных — самая часто называемая причина провала проектов миграции: 84% организаций сообщают, что оно повлияло на недавнюю миграцию, а 23% сообщают о прямой потере данных во время миграции системы; 64% сообщают о превышении первоначального бюджета, а 46% — о срыве графика (Kanerika, 2025). Каждый пункт чек-листа выше нацелен на одну из этих конкретных точек сбоя: сопоставление метаданных и сверка количества ревизий устраняют потерю данных; явное определение объёма перехода устраняет риск графика; устранение параллельного процесса устраняет самую частую причину того, почему «завершённая» миграция незаметно таковой не является.

Ссылка на механизм

Гарантии целостности версий системы назначения — строгое версионирование (ISO 15489-1 / MoReq2010), четырёхстатусный жизненный цикл выпуска плюс терминальный статус «аннулирован» и хранение на основе матрицы метаданных — это то, во что должна встроиться миграция; см. 02_Products_and_SaaS/e_edms.md.

Источники

• Kanerika, 2025 — влияние плохого качества данных 84%, потеря данных 23%, превышение бюджета/графика 64%/46% при миграциях систем.
• Основа стандартов: ISO 15489-1, MoReq2010.