Moving Lists from Hosted WSS 3.0 to Office365 – The Manual Way
It’s a long holiday weekend here in the U.S., I’ve been sick with some sort of flu for all of it, and it’s really nice and sunny outside. So what am I doing? Trying to migrate my Sympraxis Consulting demo site from my FPWeb-hosted WSS 3.0 site (yeah, I’m a little behind) to my Office365 SharePoint 2010 site. Call me crazy. I’ve been avoiding doing this because I knew that somehow it would be a bit of a nightmare, and it is, of course. But it’s going to happen today, darn it.
This should be an easy thing, but of course it’s not. When I try to do things like this, I try first to be an end user. Can I do what I want simply by using the options I have through the UI? I always want to understand how a “real person” would do what I want to do. If that doesn’t work, then I think about writing code of some sort. If coding doesn’t seem worth it, I look at third party tool. In this case, it’s a one-time activity, so it doesn’t really seem to merit writing code *or* looking at third party tools, so let’s start with the UI.
The site is fairly large, if you consider over 10Mb large. That’s the limit on saving the site as a template with its content. No one list is all that big, so I just figured I’d move each list manually. It’s no problem to save each one of them as a template with its content.
Unfortunately, when you save a list as a template in SharePoint 2007, upload the resulting STP file to SharePoint 2010 and attempt to instantiate a new list based on that template, you get this error:
Erg. I poked around the Web a bit and found a post entitled Moving a list template from MOSS 2007 to SharePoint 2010, which sounded like exactly what I wanted. It didn’t sound too “end user” to me, though. After some more searching and whining on Twitter, I decided to try the approach in the post anyway.
It does work, but it feels a bit too manual and frumpy. Here are the steps that work.
First, save your list as a template with the content like usual. If you need to understand how to do that, there are lots of instructions out there. Next, save the resulting STP file to a local repository somewhere. I created a folder on my desktop and just poked all the STPs into it.
Here’s where it gets messy. Rename the STP file you want to work with to a CAB extension. Ignore the Windows warning about making the file unusable, of course. Then open the file with WinZIP or your compression program of choice. One of the problems with this approach is that most compression programs (I checked WinZIp, 7Zip, and WinRAR) will read a CAB file, but won’t write to one.
Next, extract the manifest.xml file from the CAB file. You can then edit the manifest.xml file in any program you choose – I love SharePoint Designer, so that’s what I’m using. Near the top of the file, you’ll see where the SharePoint version is specified:
You want to simply change the “3” to a “4”.
Yup, that’s enough right there to trick SharePoint 2010 into liking the list template.
Now, we have to repackage the manifest.xml file back into a CAB file. To do this, you’ll need MAKECAB.EXE file. I have it on my system, probably because I have Visual Studio installed. If you don’t have it, I’m sure you can find it on the Web somewhere.
To repackage a CAB file which only has a manifest.xml file, you type something like:
makecab manifest.xml SalesOpportunities.cab
In some cases, I only see the manifest.xml file in the original CAB file to start, and in others I’ve got some files with 000 extensions. The 000 files look like they are the custom list forms I’ve created, and I found that I need to add them to my CAB files as well. However, SharePoint 2010 doesn’t seem like those custom forms once I’ve instantiated the list, so there’s a little more cleanup required on the back end. Without including them, though, I can’t access the list settings page through the UI.
Since I had to add multiple files to the CAB, I needed to create a directive file, as explained in this post.
Here’s an example of a DDF file (in this case, SalesOpportunities.ddf):
.OPTION EXPLICIT .Set CabinetNameTemplate=SalesOpportunities.CAB .Set Cabinet=on .Set Compress=on "manifest.xml" "00000000.000" "40000000.000"
If you need a directive file, then you type something like this:
makecab /F SalesOpportunities.ddf
Now rename the CAB file that you just created to have an STP extension and upload it to your SharePoint 2010 List Template Gallery in the root of your Site Collection.
You should now be able to create a new list based on the template you just uploaded without any problems. I’ve done 4 lists so far with no bad side effects that I can discern. Note that you will need to reconnect any Lookup columns, though, so if you are using a lot of them (like I am), then this isn’t such a great method.
With one of my larger lists, I got this error, but as far as I can tell, the list is totally fine.
With all of this, your mileage may vary, of course, and it’s definitely a hack. A hack that seems to work, but a hack just the same. Boy, doesn’t it seem like this should be something that you can do more simply? I don’t want to get an admin involved (I’m my own admin), I can’t touch the back end on the source system or the destination system, and I only need to do this once. Well at least I’ve gotten a good blog post out of it and I’ve learned a few things.
All in all, it probably would have been easier to simply create the lists manually in SharePoint 2010 (remember that I have no WSPs to work from – this is all ad hoc stuff), go into Datasheet view, and paste the items from 2007 into the 2010 list. But what fun would that have been?
But wait, there’s more! Ben Niaulin (@bniaulin) at ShareGate saw my whining on Twitter and pointed out that as an MVP, I can have a free version of their tool, which ought to help with this whole exercise. While I’m well on the way to making this happen manually using the steps above, I’ll give ShareGate a try and add an update in a follow up post.
[important]The follow up post which explains my experience doing similar things with the Sharegate tool is here: Moving Lists from Hosted WSS 3.0 to Office365 – The ShareGate Way[/important]
For the sake of the ‘how would an end-user do this’ I would say that you probably had another option for this one-time migration.
Export your list to Excel on the 2007 site and then Create a new list by importing the spreadsheet in 2010.
I think that would have been easier. And maybe faster? ;-)
I hope you don’t have the flu-or-whatever-it-is that I had. It took 6 weeks and 2 rounds of antibiotics to get rid of it …and I wouldn’t have wanted to migrate my site while that was going on. Kudo’s for your extra effort while sick!
tony
Tony:
Doh! Sometimes you have to “think different” in this business. Excel might have been a good way to go. Someone else suggested Access, which would probably have been similar. Moving the structures to me was the bigger pain, rather than the data. Datasheet view is my friend.
I did a bunch of it with ShareGate once I got a copy. I’ll be doing a post about how that worked next.
M.
So How Did ShareGate Work Out?
Bob:
I did a follow up post which explained my experience doing similar things with the Sharegate tool: Moving Lists from Hosted WSS 3.0 to Office365 – The ShareGate Way. I’ve just added a link in this post; thanks for reminding me to do it!
M.