I certainly understand that it's been two months, but nevertheless, I can share the experience. In the official manual migration this process is somehow dull described, so by trial and error I developed my own.
\r
Briefly, the sequence of actions is this:
1. Put on a new SharePoint server (WSS or MOSS) and Project Server. Updated to the same versions as on the current server (up to and including hot-fixes). Run the configuration wizard run the service. Web applications for content, NOT create.
2. Becaem farm on the old server using a standard utility stsadm (stsadm-o backup -directory-backupmethod full). This can also be done via the Central administration. Put the backup in a network ball, open full access for accounts which will be restored.
3. On the new server, restoring a backup through stsadm (you can try using the admin Center, but I don't test). I have changed the server name and the number of servers, so a whole farm restore was impossible. In this case, it is necessary to consistently recover the web app and SSP (stsadm-o restore -directory-backupid -item <where web prilojeniya> -restoremethod new). In the process of recovery need to specify the new server names and URLS. If you have migration 1:1 — i.e. a single server and his name will be the same, you can try to recover the entire farm as a whole (without the-item). To preview objects backup/restore, use the option (-showtree).
4. After this workspaces projects Project and can fall off from SharePoint. For linking you can use the
Project Workspace Site Relinker tool.
\r
In fact, using the standard backup/restore will recapata the same database + some additional data. Therefore, disappears the extra fuss with acedamy and access rights in SQL and other things.
