I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?

Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.

Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.

There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?

The FAQ: Moving a DNN installation essentially addresses this by saying "You can't" That's unreasonable.  How could we realistically tell our clients "once I build a web site for you somewhere, you can never move it.  Ever."

Looking for help.  Thanks!

The "noise" leftover in the database after such an operation is due to DNN lack of database referential integrity and database design best practice. Would be great to see this improved over time. I've always thought that this exact scenario would be a very popular commercial module if someone was willing to make it. - The "Reportaler"

I agree, there's lots of scope for developing modules that do clean up and optmisation  tasks for the database and file system. I'd walk over hot coals to get my hands on one that found orphan files in the file system!

However that sort of thing has to take second place to the front end functionality - it has ever been thus - the older shrink-wrapped software suffered from code bloat in version releases.

Would be good to see some simplification though. The level of knowledge a site admin has to have about configuring a DNN install (to get it running well) is getting a little alarming.  DNN's modular format is one of the reasons I love it, but it's easy to fall into the feature bloat trap.

Back to the topic ;-)

When deleting portals from a duplicate install to separate out a particular portal, I first delete any module not in use on the new single portal install, and then write a lot of SQL to explore the tables to find the leftover information in the db so I can then very carefully delete it. The overhead of leaving that 'noise' in there isn't that high, I guess it depends on how tidy you want/need to be. Although you should always go in to the portals you are about to delete and delete all the users first (as otherwise those usernames are 'taken' in the new single portal install despite not having being registered to a portal). I do this with SQL, but it's as easy (just slower) to do from the front end.