A lot of posts in the Install It! forum are from people wonder how to move their DNN installation from their development environment to production. In a nutshell, this is the process:

1. in your dev environment add a new http alias for the production environment. You can do this in Admin > Site Settings, but only when logged on as host. For instance, if your dev site runs under http://localhost/dotnetnuke, and your production site will run under http://www.mydomain.com, you should add www.mydomain.com as http alias. Why is this important? Always, when DNN receives the first page request, a lookup against the defined portal aliases is done. If the hostname that is used to request pages from DNN is not found in the list of portal aliases, DNN will redirect to the first available portal alias of the first portal. Quite often this will be your dev environment. A common mistake is to not add the portal alias, and thus be redirected to your devsite when browsing to your production site for the first time
2. Move your database to the production database server. There are a couple of ways of doing this. You can do a backup of your dev DB, and restore it (or have your provider restore it) on your production db server. The problem i have with this approach is twofold: if the db collation of the production server is different than the collation of your dev db server, you could get into troubles when using modules that use temporary tables. The collation of TempDB is always the same as the server collation, while the collation of the database is copied over from the dev db during the restore. The other problem you might run into with this approach is the fact that although usernames might match on both servers, in reality they are not the same. The security id (SID) will be different, so you will not be able to use the same user, and also, you will have an orphaned user in your production database.
   Alternatively, you can simply detach your db from your dev sql server and attach it to the production server. This might also cause issues with collation and user id's.
   The method i like myself is a bit more expensive: database comparison, but works very good. I almost always use the tools from Red-Gate, SQL Compare and SQL Data Compare. These tools automate the comparison between to databases to a very high degree. A great plus of these tools is that you can use them to keep your development database and your production database in sync as well. Just run Data Compare, and the contents of the 2 db's will be the same again.
3. Move all the files in your dnn application folder to the production folder. This can be done by ftp or any other method you use to copy files.
4. Make the appropriate changes to web.config. At the very least you should change the sql connection string, to have dnn look at your production db
5. Browse to your production site... done

I found a couple third party blog posts about moving DNN and moving databases:

• Moving DotNetNuke Sites from Dev. To Prod (Ventrian, Scott McCulloch)
• Moving DotNetNuke to Production (Venexus, Jeff Smith)
• Recipe: Deploying a SQL Database to a Remote Hosting Environment (Part 1) (Scott Guthrie)
• Tip/Trick: How to upload a .SQL file to a Hoster and Execute it to Deploy a SQL Database (Scott Guthrie)

(this is a cross post from my blog on dotnetnuke.com)