I should really learn to estimate networking and migration tasks better. The last time I upgraded my FogBugz instance on my local web server, it took about 20 minutes. This led me to estimate the time to migrate it to a Microsoft Azure Virtual Machine at 2 hours.
Well, 2½ hours later, I'm a little frustrated, but possibly closer to getting this accomplished.
The point of a virtual machine, of course, is that it should appear the same as any other machine anywhere. But using an Azure VM means either using an Azure SQL Database or installing SQL Server right on the VM. Obviously you'd want to do the former, unless you really like pain. Unfortunately, FogBugz doesn't make it easy to do this, and in fact puts up roadblocks you'll need to get around.
Here, then, are the steps I went through trying to get FogBugz moved to an Azure VM:
0. First, before anything else, I copied my FogBugz database in its entirety up to a new Azure SQL Database using the incredibly useful SQL Azure Migration Wizard tool.
1. Ran the FogBugz installer on the VM. It didn't accept my database connection because SQL in Azure doesn't have the xp_msver extended stored procedure that lets FogBugz know what version of SQL it uses.
2. Checked Fog Creek Software's support forum. They don't support FogBugz on Azure SQL Databases.
3. Attempted to create the xp_msver stored procedure on the SQL Azure master database; permission denied.
4. Installed SQL Server 2008 Express on the VM.
5. Re-ran the FogBugz installer. It can't connect to the IIS configuration file, and therefore thinks I don't have IIS on the machine.
6. Re-ran the FogBugz installer, this time just extracting the files to a folder under the VM's Web root.
7. Set up a new application in IIS pointing to the FogBugz folder.
That put me in the weeds, because the application has no configuration settings available. Opening the app in a browser gives me the error message: "The FogBugz database is down or could not be found." It further suggests that I need to change the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Fog Creek Software\FogBugz\{application folder}\sConnectionString. So I did, and I got the same error.
The reason is that on 64-bit servers, the FogBugz configuration keys aren't in HKLM\Software; they're really in HKLM\Wow6432Node. I figured this out because, remember, I have a running FogBugz installation, and I was able to search the server's registry directly.
All right, moving on:
8. Copied my existing server's FogBugz registry keys (from the right registry folder) to the VM.
Nope. FogBugz still gave me the same error. I also copied the connection string to the registry key FogBugz claimed it was looking in, with the same result.
OK, I'm going to now uninstall everything and reboot the VM, then try again to install FogBugz pointing to SQL Express. Back in a flash...
(20 minutes later...)
OK, FogBugz installed cleanly, but at the moment it's pointing to the local SQL Express database. So: change the connection string to SQL Azure...and bam! It works.
Excellent. Only two applications left to move...