Changing cloud storage is not complete when files appear in a new folder. A defensible migration record shows what was supposed to move, what actually moved, whether important metadata and permissions survived, how restoration was tested, what exceptions remain, and when the old service can be retired. This evidence helps distinguish a verified transfer from an optimistic copy count.
Freeze scope and responsibilities
Record the source and destination services, account or tenant identifiers, authorized owner, migration window, included repositories, excluded repositories, retention obligations, and success criteria. Inventory files, folders, shared drives, versions, comments, shortcuts, links, ownership, permissions, timestamps, labels, and any application-specific objects. Do not assume every service represents these features the same way.
Classify the data before moving it. Identify personal, financial, regulated, contractual, secret, or irreplaceable material and apply the required handling rules. Record who may run exports, who can receive them, where temporary copies may exist, and who approves final retirement. Keep credentials, recovery codes, and encryption keys out of the general migration log.
Capture a source-side baseline
Create a dated inventory before the first transfer: object counts, total bytes, folder counts, shared items, owners, external collaborators, unavailable items, and quota status. Preserve configuration screenshots or exports for retention, sharing, versioning, and security settings when permitted. Hash a representative set or all files when feasible, but explain precisely which content the hashes cover.
For Google accounts, Google Takeout guidance documents selecting data and creating downloadable archives. Google also explains that downloading an archive does not delete the source data and that large exports may be split. Treat the archive manifest, requested products, creation time, delivery method, part count, and download completion as evidence. An archive request is not proof that every expected object was successfully restored elsewhere.
Record transfer and integrity results
Keep tool name and version, command or job identifier, start and finish times, operator, settings, encryption method, logs, warnings, retries, failures, and rate-limit interruptions. Save checksums produced by trusted tooling and compare them at the correct boundary. If a provider changes a document into another format, a binary hash cannot match; document the conversion and validate the resulting content separately.
NIST's storage security guidance treats confidentiality, integrity, and availability as connected storage concerns. Use that framing for the evidence packet: show that unauthorized people could not read the transfer, that content and metadata were checked for unintended change, and that authorized users can retrieve the result when needed.
Test destination behavior
Select a risk-based sample that includes large files, tiny files, long paths, unusual characters, nested folders, shared content, version history, externally linked items, and each important file type. Open files using the intended application, search for them, download them, restore a deleted test item, and verify sharing with test accounts. Reconcile source and destination counts, but investigate differences instead of forcing them to match by removing inconvenient categories.
Permission evidence deserves its own comparison. Record source principals and roles, the intended mapping, destination roles, inherited access, broken links, public links, external collaborators, and unresolved accounts. A successful content copy with an accidentally public destination is not a successful migration.
Control cutover and coexistence
Document the final synchronization boundary and the rule for edits during the move. If both services remain writable, identify how conflicts and late changes are detected. Record DNS, application, bookmark, shared-link, and integration changes only when they fall within authorized scope; changing account or security settings may require a separate owner approval.
Keep a rollback decision, not just a rollback hope. State which conditions pause cutover, how users return to the old service, how new destination changes are reconciled, and who can authorize the switch. Communicate known limitations such as lost comments or regenerated share links without presenting them as invisible success.
Retire the old service only after verification
Keep the old copy read-only for an approved validation period when policy and cost permit. Obtain acceptance from the responsible owner, close exception tickets, verify retention and legal holds, and confirm that destination backups are usable. Record any provider export expiration dates and remove temporary archives according to policy.
The final packet should contain the approved scope, baseline inventory, source exports, transfer logs, checksum or comparison results, permission mapping, restoration tests, exception register, acceptance, cutover record, rollback decision, retention decision, and retirement authorization. It should not contain passwords or unnecessary personal data. The goal is not to prove perfection; it is to show, with bounded evidence, what moved, what was tested, what changed, and what still requires action.
Sources
- How to download your Google data — Google
- NIST SP 800-209: Security Guidelines for Storage Infrastructure — National Institute of Standards and Technology