I'm an old fox developer, and here's the way I use for migrating VFP to SQL (in addition to Charles, who is also an old fox).
First of all, migrate structure.
I use VFP9 Upsizing Wizard to migrate structure, because my dbfs are allways referenced in a dbc, and RI is implemented with its triggers - I had corrected a few bugs in its sources in order to manage varchar(max), and varbinary(max), but it seems that Rick Schummer's version is now without bug.
Upsizing wizard allows to add Timestamp fields (they are usefull for a good concurency management), and creates referential integrity in a declarative way (creates constraints, and not triggers).
Then, I use DDT on the new structure, on SQL server. I'found that way more simple than importing VFP structure from within DDT, but it is probably because I use VFP upsizing wizard for many years (and DDT only 2 years).
once your structure is ok in SQL, let you migrate data. Never use VFP uspizing wizard for that! never!
Before data transfer, check and check again the quality of your data, never forget that VFP is a lazzy language and a fuzzy storage (that's why VFP developpers may not be lazzy or fuzzy, and I love VFP 
, but I know its bugs). For exemple, in VFP, a field N(5,2) should hold nothing larger than 99.99 Try it, and you will see that you can store whatever bigger value you want, and the fox will not raise any error.
But when you try to transfer this row in a SQL table, you'll get a splendid crash 
(I still remember the first time I got it: more than a week in debugging to find it, and write this tiny prg to detect it in all dbfs)
With my customers, I use 2 ways to transfer data. Some prefers to push data from VFP into SQL, using remote views in Fox. Others use importing wizard in SSMS (wich in fact uses SSIS). I've tried using dbfs as a linked server in SQL, it runs without problem, but is slower than SSIS.
Don't worry about null, but check VFP specific syntax in default values and validation rules in dbf.
And enjoy SQL and StrataFrame !