Data migration, the carrying of electronic data and metadata between systems or the move of data from one state into another, in-place upgrades, conversions, platform moves including to the cloud and consolidations, concentrates on what matters most for patients, product quality and the integrity of data, scaled by risk, complexity and novelty, and governed by a migration plan and report, or by an existing procedure, with the system life cycle defining the migration process, roles, records, controls and oversight, ideally in a standard procedure. Risk management evaluates the inherent quality and compliance risk of the data, incomplete source data, business unavailability, complexity, technology and the use of vendors and contractors. Migration is performed under change control with unrelated system changes prohibited during the project and communication to affected business areas of timeline, scope, entry and completion criteria, pre-migration cleanup, unavailability and post-migration monitoring; a staging area is used with source, staging and target under configuration management and a rollback strategy including a full source backup. Migration tools, whether category 1 infrastructure tools or category 5 scripts, are fit for intended use with rigor by risk, addressing the risks of incorrect or incomplete transfer, harm to target data and effects on residual source data, with data verification allowing reduced tool verification but an approved data mapping table still required. Data is verified each time it is moved or transformed, in a test environment with a small fully verified set and in the operational environment where automated tools may verify all data, with completeness confirmed by techniques such as checksums and objective evidence retained; the reliability of source data is established by reference to the source system's controls, with unverifiable migrated data distinguished or documented; usability in the target is considered including functionality, completeness, separate migration of metadata such as access rights and sequential version migrations; audit trails are migrated where feasible or archived retrievably, the start of auditing on load is documented, a migration audit trail is generated and any switch-off justified; vendors and contractors are assessed and bound by agreements defining oversight, procedures, tools and training. The plan covers purpose and scope including waves, system descriptions, roles, deliverables, risk, configuration and tool strategies, steps, mapping and modelling, transformation rules, verification strategy and acceptance standards, cutover with communications and rollback, is approved by the process and system owners, the quality unit and subject experts, may be reused with a report per execution, and the report states the outcome as full success, partial success or failure with anomalies and verification results, approved by the same roles.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.