2

I'm aware I can now do this through the portal in the storage blade however the account I need to migrate is a production account. It's just blobs, tables and queues, no VMs.

I can stomach some downtime (say an hour or 2) but am unsure how long it would take to migrate approx 750GB, does anyone have experience with the migration and an idea on the time it takes based on a similar volume size?

I also assume once migrated all my storage keys will change so I will need to update all the references in my app settings.

Simon
  • 1,613
  • 1
  • 12
  • 27
  • i dont think its doing anything to the storage account itself, it just starts to use arm to manage it, thats it – 4c74356b41 Aug 19 '19 at 14:23
  • @4c74356b41 So that would mean there is minimal migration downtime and no configuration changes required? Any way I can validate this officially, I see in the Commit step it says the existing Classic resource(s) will be deleted which is what makes me think it does migrate data but obviously it's not 100% clear – Simon Aug 19 '19 at 14:43

1 Answers1

2

For anyone else wondering about this what @4c74356b41 said appears to be true.

Thanks to this post and the PowerShell command, couldn't get the ARM template to dpeloy at least not from VS, I was able to create a classic storage account. Didn't think this was still possible!

I then kicked off a 50k files container copy from another storage account in the Azure Storage Explorer container into this new classic resource and then while that was running ran the full migration including commit and the file copy carried on regardless.

Final step was to move the new resource (file copy is still ongoing at this point) from the migrated resource group back into the same resource group as the original classic storage account.

Once the move was complete the file copy was still going smoothly and all the Keys remained unchanged so this does seem to be truly seamless.

Simon
  • 1,613
  • 1
  • 12
  • 27