A cloud move can look simple on a project plan: copy the data, point users to the new location, and retire the old system. The difficult questions appear between those steps. Which files are still changing? Will shared folders keep the right permissions? How will anyone prove that every important record arrived intact?
This cloud migration checklist focuses on preparing data before transfer day. It turns cloud migration planning into decisions, tests, and sign-offs rather than a last-minute file copy. Use it alongside your cloud migration process guide to keep the technical move and business handover aligned.
Build an inventory of what actually needs to move
Start by identifying data stores, not just servers. Include shared drives, databases, object storage, application uploads, archived records, and exports managed by individual teams. For each source, record its owner, approximate size, format, sensitivity, retention requirements, dependencies, and intended destination.
Ask the people who use the data how it behaves. An inactive-looking folder may feed a monthly report. A database table may depend on an application that must migrate at the same time. Document these relationships before deciding transfer order.
Separate move, archive, and delete decisions
Not everything belongs in the destination. Flag duplicate files, obsolete temporary exports, and records eligible for deletion under your retention policy. Archive material that must be retained but rarely accessed. Get owner approval before deleting anything; cleanup is not permission to discard regulated or business-critical records.
Check data quality and destination compatibility
A useful data transfer checklist looks beyond volume. Identify unsupported file names, path lengths, unusual characters, corrupt files, database schema differences, and formats that require conversion. Test whether the destination supports metadata your teams rely on, including creation dates, version history, labels, and links between records.
Decide what successful conversion means beforehand. If a legacy database field changes type, document the mapping and how you will spot truncated values. Keep an exception log showing the affected item, owner, chosen fix, and whether it blocks migration.
Map identities, permissions, and sensitive information
Access problems can be more damaging than a missing file. Export existing users, groups, service accounts, sharing rules, and privileged roles. Map them to destination identities, then confirm what the migration tool actually preserves. Some tools handle folder-level permissions differently from individual file permissions.
Test with representative users: an editor, a read-only colleague, an external collaborator, and an administrator. Each should see only what their role permits. Review publicly shared links and inherited permissions instead of assuming they will remain safe.
Classify sensitive datasets and confirm encryption in transit and at rest, key ownership, residency requirements, logging, and retention controls. Your cloud storage security checklist should cover these settings before production data is uploaded.
Take a recoverable migration backup
Make a migration backup before changing the source, and ensure it is independent of the transfer process. A synchronization job that propagates deletions is not a substitute for a protected, restorable backup. Record the backup time, scope, encryption method, storage location, and restore owner.
Perform a sample restore to a separate location. Verify that you can open restored files or query restored records, not merely that the backup job reports success. For live databases, choose a consistent snapshot or backup method appropriate to the application so related transactions are captured coherently.
Select the transfer method and run a pilot
Choose among managed migration services, application-aware database replication, bulk transfer utilities, and offline transfer based on size, network capacity, downtime tolerance, and change rate. Check throughput with a test rather than assuming theoretical connection speed is guaranteed performance.
Write down the operational settings
For each source, specify the transfer tool, destination, credentials, bandwidth limits, encryption, retry policy, logging, and person responsible for exceptions. Decide whether the move will be a single copy or an initial transfer followed by incremental synchronization. Frequently updated datasets need a plan for changes made during copying.
Run a pilot with realistic samples, including large files, deeply nested folders, restricted records, and recently modified items. Note how long the transfer takes and which metadata or permissions fail to carry over. Correct those problems before expanding the migration wave.
Define migration validation before cutover
Migration validation needs evidence, not a reassuring dashboard percentage. Compare source and destination item counts, total sizes, folder structures, database row counts where appropriate, and transfer error logs. For files copied without transformation, use checksums or hashes where supported. For transformed data, compare agreed business fields and test application behavior instead.
Have data owners open representative documents, run key reports, search for records, and verify access from ordinary accounts. Keep a record of the test, expected result, actual result, and approver. Specify which failures must be fixed before anyone switches to the new system.
Set a change freeze, cutover window, and rollback trigger
Agree on how new writes will be handled during final synchronization. Depending on the workload, that may require a brief read-only period, a controlled application freeze, or continuous replication with a managed switchover. Announce the window to affected teams and name one person empowered to approve the cutover.
Write a rollback plan with clear triggers: missing critical records, failed access tests, unacceptable application errors, or an exceeded outage window. Identify the last known-good source, restoration steps, routing changes, and decision deadline. Rolling back after users start writing new data to the cloud is harder, because those changes need reconciliation. Rehearse the plan and retain the source until validation and retention requirements permit retirement.
A practical example: moving a shared finance folder
Suppose a finance team is migrating a shared folder containing invoices, spreadsheets, and quarterly close files. Inventory the folder, identify who can approve payments, and mark spreadsheets with links to other files. Take and test a backup. Then migrate a sample folder and ask a finance analyst and an auditor to confirm their different access levels.
During the final move, temporarily restrict source edits, synchronize recent changes, compare file counts, and open linked spreadsheets. If an auditor unexpectedly gains editing access, the permission test fails even if every file transferred. Fix that mapping before cutover. Data is ready only when it is complete, usable, and appropriately protected.
Frequently asked questions
What should be checked first in a cloud migration?
Confirm the inventory, data owners, dependencies, destination compatibility, and retention requirements. Those findings determine what to move, the transfer order, and the tests needed afterward.
Is a cloud synchronization tool enough for backup?
No. Synchronization can copy accidental deletions or unwanted changes. Maintain an independent, recoverable backup and test restoration before the cutover.
How do you confirm data transferred correctly?
Review transfer errors, compare counts and metadata, verify integrity where possible, test permissions, and have users perform real tasks in the destination. No single measure proves a complete migration.
When can the old system be switched off?
Only after agreed migration validation passes, owners sign off, rollback needs are addressed, and legal or operational retention obligations are satisfied.
Finish with evidence, not assumptions
A reliable cloud migration checklist ends with a clear decision: the data has been inventoried, protected, transferred, checked, and accepted by its owners. Keep the records of exceptions, validation, and rollback readiness with your project documentation.