Migrating portal(s) from an existing to new DotNetNuke installation using export/import and templates is not really a viable solution as . . .

1. User accounts, permissions, etc. cannot be exported/imported without using 3rd party solutions for user management.
2. Not all modules (including several core modules) implement IPortable and thus cannot export or import their contents.
3. Site files (in Portals child folders) do not get exported/imported and even after moving them manually will need to be re-synched to the DNN file system with loss of folder permission and changes in FolderID and FileID's referenced in many module's data.
4. I could keep going with other reasons "why not" but I think you get the picture.

Instead I would follow this route to upgrade:

1. Backup all folders and files of the installation and backup the installation's MS SQL Server 2005 database.
2. Create a clone of the installation on a local system which has the pre-requisites for DNN 5.6.1 installed - ASP.Net 3.5 SP 1 (and 4.0 if you will also be upgrading .Net versions), MS SQL Server 2005 or 2008 (standard or express), and IIS 6, 7 or 7.5. Don't forget to create additional local portal aliases in the PortalAlias table for each portal that you wish to test on the cloned system. Do a Google search on "moving DotNetNuke from production to local" for details on this step.
3. Verify that the cloned installation is working properly on localhost.
4. Upgrade the cloned installation to DotNetNuke 4.9.5, verify operation and if necessary fix any upgrade issues.
5. Create backups of filesystem and database for the upgraded localhost installation.
6. Contact 3rd party module vendors and review "core" module forums here to determine compatibility of all installed modules with DNN 5.6.1. For example, the Xml, Events, Gallery, Chat "core" modules will need upgrading or uninstalling either before or after upgrading past certain DNN 5.x versions.
7. Upgrade the localhost installation to DotNetNuke 5.4.4 and again verify all operation and fix any upgrade issues.
8. Create backups  of the now 5.4.4 installation.
9. Upgrade to DotNetNuke 5.6.1 or preferably to 5.6.2 which should be released around mid-March and again verify and fix any upgrade issues.
10. Create backups of the now 5.6.1 or 5.6.2 installation and restore to the production server.

An alternative to #10 in case your production server host will not permit restoration of a database backup created outside of their system (GoDaddy for example) or if you are concerned about new or modified content or new or modified user accounts that have occured between steps 1 and 10 is to repeat the above upgrade process on the live production site using your notes of what went wrong and what had to be corrected on the "test" upgrade to avoid them on the live upgrades. I've worked with both approaches including taking a few installations from 3.3.7 to 5.x but have in a couple of cases that while an upgrade went well on the localhost "test" upgrade have had a failure on the live site upgrade - usually due to a file system permissions error, full database, or timeout during the upgrade.  Make sure that you have make backups at the end of each successful upgrade step so that you can roll back if necessary.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner