Migration Wizard vs Data Sync

May 12, 2010 at 3:47 PM

I've been playing with the Migration Wizard with a view to getting an initial dump of my Sql Server data uploaded into Sql Azure.   I had then planned to use "Sql Azure Data Sync" to maintain ongoing data consistency between my on site DB with my Azure DB until such point as I am ready to completely "swap over" my onsite web application to Azure.  However, while looking at Data Sync, I see that it has the capability of creating tables and (of course) syncing data.  In short, it seems that both the Migration Wizard and Data Sync can do the same job for seeding my DB, but Data Sync is better for me longer term.  

Having not looked into the actual mechanisms that Data Sync uses to maintain row versions (and which instance has which data), I'm wondering if I am going to run into trouble if I seed my DB using the migration wizard, and then want to setup on going syncing with the Data Sync tool.  I guess I'm concerned that I'm gonna have to dump the tables that I've just created with the migration wizard in favour of ones that Data Sync is going to create- and thus getting charged for the same data being uploaded twice to Sql Azure!

Any comments?

Coordinator
May 17, 2010 at 2:46 PM

Hi,

I talked to a couple of people and here is their response:

I don't believe the Data Sync Powerpack has the ability to sync with existing data on azure. The data will go over twice and there might be unnecessary conflicts. The main difference between using migration and DataSync will be with database objects and schema. Data Sync only pulls over the schema for tables that are synchronizing and even with those the schem is created on Azure based on the dataset that is coming over the wire. Take a look at the schema and see if the difference is of concern. If not then it might make sense to use Data Sync for both actions.

Regards,
George

May 17, 2010 at 3:13 PM

Hey George,

Thanks for getting back to me on this.  I did look at Data Sync wizard and tried to get it to run, but it is currently busted in that it insists on creating the DB before even attempting the sync.  Also, it has some bug with a 30sec timeout so, that large tables can cause it to complain.  

They are targeting Q4 for a production release, and that is just too far away for my migration plans, so I'll stick with your Migration Wizard to do an initial dump-and-upload of our current production DB and some change-tracking SQL that will detect rows that have changed between the initial dump and cut-over.

Thanks again!