Ensuring Data Consistency in Cross‑Cloud Migration: Cleaning, Cut‑over & Validation

Data Cleaning Phase

During testing of the new platform, real data is used to verify application behavior, which often leaves dirty data that must be addressed. Two main approaches are used: rolling back to a backup point (e.g., MySQL binlog or cloud backup) or re‑synchronizing changed files based on change logs. Either method can be chosen depending on data volume.

Ensuring Data Consistency

After the cut‑over preparation, the synchronized data becomes the production data, so it must remain unchanged. Several methods are recommended:

Database read‑only accounts: create a dedicated sync account with full privileges for migration tools, and a separate application account limited to SELECT only.

Terminate application processes: stop all programs that could modify data during the cut‑over, ensuring no unexpected writes.

Network ACL isolation: configure ACL rules to allow only the synchronization service to reach storage components, blocking all other hosts.

Each method has trade‑offs; read‑only works well for MySQL with few instances, process termination is universal but requires accurate inventory of all scripts, and ACL isolation needs clear subnet segmentation.

Cut‑over Phase

The cut‑over window is limited, so data validation should start right after the cleaning phase. Validation includes entity‑level checks with tools like sync_diff_inspector and metadata checks such as SELECT MAX(id) or COUNT(*). Early validation reduces pressure on the cut‑over window.

Rollback considerations: if inconsistencies are detected during the window, a rollback to the pre‑cut‑over state is required, which relies on having clean data beforehand.

Summary

The article presents practical experiences for maintaining data consistency during cross‑cloud migration, covering dirty data handling, read‑only database configurations, process termination, and ACL network isolation, with case studies illustrating combined use of these techniques.