Fixing Data Migration Assistant timeouts
2December 8, 2016 by Kenneth Fisher
I’ve been really excited about the new Data Migration Assistant (DMA) since I first heard about it. One of the things I like best about it is that unlike the old Upgrade Advisor it doesn’t have to be run on the server being upgraded. You can run it against any number of instances from a single workstation. The other day I was working from home and tried running the DMA against a couple of moderate size databases (about 1.25tb total) and I consistently got timeout errors.
Well, that’s a pain. It at least partially negates one of my favorite improvements. So I started asking around if anyone else had had the same problem, or maybe knew a solution. And I got one!
Which leads me to my next favorite thing about the DMA. It has a configuration file!
%ProgramFiles%\Microsoft Data Migration Assistant\dma.exe.config
The blog post gives instructions on a number of different configurations. How many databases to work with in parallel, how many rows before recommending stretch databases, command and connection timeouts and a few others. So now with a simple change to the config file to go from 15 seconds to 60 seconds:
<appSettings> <add key="ConnectionTimeout" value="60" /> </appSettings>
I was easily able to pull the data I wanted.
SQL Studies 
The database I manage uses almost 100% middle-tier generated T-SQL. I know, I hate it, but it’s what it is. So how can I test my SQL Server 2014 application’s readiness to move to SQL Server 2016 when there’s no “code” in the database? I expected to be able to run a workload trace file through the Migration Assistant but that feature is surprisingly absent. Any ideas?
Unfortunately the best I’ve been able to find so far was a suggestion to use the 2014 upgrade adviser for any trace files you need to process. It’s not the best option but it’s certainly better than nothing.