Large Transaction Database Migration from Azure VM to Azure SQL MI With Almost Zero Down Time

Problem Statement- Migrate Large Database (>500 GB) from Azure VM to Azure SQL MI with in the following constraints & challenges 

• Almost zero down time since ecommerce biz never stop as during the day first & last mile operations happen whereas during the night long haul & warehouse operations happen 
• Daily Data Volume is > 2 GB, hence Operation scale is so big that it is impossible to handle operations manually for short duration 
• Azure VM Storage was almost full ( only 10 GB Remaining). Neither new disk can be added or partition size can be increased due to large down time
• By chance if migration fails , it would be nightmare for tech team and operation team to go back to earlier Azure VM situation hence there is no scope for failure
• No migration experience in past and No experience of Azure Sql managed instance 

How did we achieve it-

Thorough Preparation:-

• Follow line by line instruction as per Azure Tutorial.
• Instruction on creating Azure SQL Managed Instance failover group.

Simulate Dry Run:-

We replicated the exact scenario of database migration from same Azure VM to Azure SQL Managed Instance using a small database (26GB) with same schema.

1. Did 4 dry run to understand impact of different setting like taking backup with checksum, checking LSN sequence for log backups taken at different time interval
2. Compute Timeline for each activity like Full Backup, DMS (Database Migration Service) Activity Configuration, subsequent log back up before Cutover

Immaculate Planning for Each Activity,

The below image describe it well

Actual Migration:-

We were allotted 2 hours of down time during wee-hours on Sunday - Here is the list of activities with timeline

Post Successful Migration Challenges:-

Yes Indeed it was a very tight rope walk but all went well and it was as per planning despite of all perfect rehearsal, planning & execution , we faced a lot of complaints of reports “not downloading”  the next day when load was high and it led to disruption in operations . So what was the reason

• As per Azure VM Billing and Its Performance Structure we opted for General Purpose service tier and 4 vCore CPU setting
• Changing it to 8 vCore, did not sort out the problem since It increased only CPU which was already in normal state but not having impact on IOPS.

Finally we overcame the challenge after we changed the pricing tier to business critical which took 3 hours of time with our database size and our server cost went up 4x

Hoping our experience might help the folks whosoever want to do it in the near future.