First post ever, I had similar issues to what others have encountered during testing, namely a stall/hang during the migration step for the free edition. I didnt want to impact our current help desk (v9.102) so I copied our derby db to test (very small db). I followed Michael's (usname: slabodnick) suggested steps, and I was able to complete the process as follows:
Virtualbox VM of MS Server 2008R2 x64
Started with 9.05 free edition derby embedded, upgraded to 9.102 free. Stopped the SA service so that I could replace our production derby db in the appropriate directory. Restarted the service, localhost to the portal to ensure I could see our tickets/config. Stopped the service once verified.
Proceeded with the 14.1 patch and like others it hung on migration.
At this point I installed SQL Studio, and then cancelled the patch. It rolled back the SQL install but left Studio intact. I brought up Studio and re-executed the patch and it gave me almost a 1-2minute window in which to create an "sysaid" db with owner "sa" (as Michael posted) under the newly created instance. The migration step proceeded and began migrating our Derby db to SQL successfully
The installer then began to patch SA up to 14.1 and actually hung installing other files. Could have been a variety of issues so I cancelled the installer (this actually prevented me from patching again on this VM) and copied the newly SQL db and placed it on a fresh install of 9.102 with SQL embedded on our Hyper-V dev server (others can use a similar setup in another Vbox instance). All I had to do was replace the default SQL "sysaid" and "sysaidlog" db's and I was able to bring up our help desk on v9.102 SQL embedded. I was able to see all of my tickets, and all the configuration came with it. Currently testing on a new VM to see if any issues appear with the 14.1 patch beyond the derby migration, but having a SQL db to play around with is miles ahead of where we were previously.
IMO, seems like the best step for R&D would be to split the steps into two different installers, one to migrate with a pause in between installing SQL and migrating the DB, and one to patch to 14.1.
The only other notable thing is what all IT admins should do, which is to make back-ups of everything (zips are priceless). SysAid makes it extremely easy to revert changes you make by just having a backup of the directory or changed files. Renaming default items to "_ORIG" while placing your test files can save you alot of time, and gives you the option to delete what you replaced and simply rename back to what you had to revert back to default.
TLDR; SysAid is an amazing product and while this migration might be initially daunting, what I have gotten out of the free version has convinced my superiors to push into buying the enterprise edition software not only for internal use, but external client and project use. Many thanks to Michael, and I hope others are able to have the same experience I had by following his steps.