I have a GoDaddy Hosted Exchange Server running SharePoint 3.0 and I'm looking to migrate to a server running SharePoint 2010.
Since the originating server is the GoDaddy server, I don't have access to anything on the back end of the SharePoint site, like the configuration page and the database. On the host, we have paid for 61gb of space on the server, and we are storing 60gb of data already.
One suggested solution is to back SharePoint up with the SharePoint Designer, which seems like it would work, except it has to back up the data to a file on the same SharePoint server, or another server running the same version of SharePoint, and as before mentioned, the source SharePoint server is near capacity. I'm thinking of setting up a computer that has the available space with a Trial Version of Windows Small Business Server 2008, the last version compatible with the version of SharePoint I'm trying to install and migrate to, but I was wondering if there's a better solution for this than going through the motions of creating the virtual machine to host the SharePoint so I can back up the SharePoint to download the backup file to upload to the new SharePoint so it can be unpacked.
This sounds ridiculous, and it is, but there's a specific reason why I'm trying to do it this way. The company didn't have much experience with SharePoint when it was first set up, and the users didn't have much of an idea about how the Windows file and folder tree works. While creating the folder structure, they were able to ignore the path+filename length limit because SharePoint is stored in a SQL database. Since then, they've been using a well structured file tree that is unfortunately long in the character length department. I tried setting up two SharePoint shares side-by-side as mapped drives, and using a system like WinMerge or even command-line xcopy to move data from the one to the other, but the filename length limit strikes me down every time.
I don't want to have to re-mount each sub-folder separately in order to copy the data over, as that would be time-prohibitive and would require working on it exclusively on a weekend without regard to possible changes during the process, and without a way to compare differences.
I'm looking for a creative solution I haven't tried yet, but I'm feeling a little stuck. We're looking to migrate our SharePoint server local to cut costs, and our connection here is more than able to handle the amount of traffic that will come of bringing it locally. The only problem is moving the data from place to place.
If anyone has any insight, I'd love to hear it. I've been working on this for two weeks!