Cloud Migration and Certification at Lakeview Health Network
Lakeview Health Network is migrating 18 million documents from a 12-year-old ECM to a cloud platform. The legacy system has 247 metadata fields, 38 of which are used; 35% of documents lack a retention code. Audit trails are stored in a separate database that the vendor says 'can't be exported in full.' Clinicians need 24/7 access. The migration is 6 weeks from cutover; the vendor proposes lift-and-shift, then cleanup. The records manager must certify that migrated records remain authentic, reliable, and usable, and that disposition can still be executed. The CIO wants to decommission the legacy system 30 days after go-live to save $40,000 per month. Two departments have active legal holds. A prior migration lost 1,200 scanned consent forms.
1. What must the records manager validate before certifying the migration?
Read the worked answer
Certification requires evidence that migrated records remain complete, authentic, usable, and disposable. Before cutover, require a field-by-field mapping for the 38 used metadata fields, a record-class and retention mapping, and a rule for the 35% without retention codes. Validate the audit trail: if the vendor cannot export the full audit history, the migration design must preserve an immutable event log in the new platform or the records cannot be authenticated. Test by stratified samples by record class, age, department, format, and hold status, not a single random sample. Include the 1,200 consent-form failure as a known defect and verify that similar records are accounted for. Use checksums, count reconciliation, and an exception log. Test legal-hold identification and disposition freeze in the new system. Certification should be a signed validation report with acceptance criteria, not a verbal assurance at go-live. Critical errors must be remediated before certification, and noncritical errors need an owner and deadline.
2. Should the CIO's 30-day decommission plan be approved? What conditions would you set?
Read the worked answer
Do not approve decommissioning 30 days after go-live. That is a cost decision, not a records decision. The legacy system should remain read-only until migration completeness is reconciled, critical metadata and audit trails are validated, legal holds are confirmed in the new system, clinicians have completed a stabilization period, and disposition can be executed from the new platform. Set exit criteria in writing: zero unresolved critical errors, signed acceptance testing, verified hold coverage, tested disposition, and a rollback window. Negotiate a reduced read-only tail license if full licensing is expensive. Verify that decommissioning will not destroy the only copy of audit-trail data or the mapping documentation. The $40,000 monthly saving is small compared with the cost of losing consent forms, breaking audit trails, or releasing held records. Decommissioning is a records disposition event and needs documented approval.
3. Should the team clean all 247 metadata fields before migration, or migrate as-is and fix later?
Read the worked answer
Neither extreme is safe. Prioritize the fields that control access, retention, legal hold, and disposition; those must be remediated before migration. Fields with no business or legal use can be mapped to a note or retired under governance approval, but not silently dropped. The 35% missing retention codes should be assigned by record class using the schedule and business validation, not guessed document by document. Post-migration cleanup is acceptable for descriptive metadata, but not for retention events: if the new system cannot calculate disposition, the organization has migrated content without records management. Assign data stewards, define quality thresholds, and track remediation in the exception log. The goal is a controlled migration with known defects, not a perfect cleanup that delays cutover indefinitely or a lift-and-shift that transfers unmanaged risk into the cloud.