What a week! Believe it or not, my job isn’t one as a SharePoint administrator, although sometimes it feels like it is (and recent blog posts might suggest otherwise)!

The thing about SharePoint is that even non-developers like me can string together a few webparts and lists to create something reasonably useful. Last week, one of the sites that I’m managing as part of my day job was migrated from its incubation location as a subsite of my team’s portal, to join some related content on another site. It should have been fairly straightforward, but sadly that wasn’t the case…

Updating hyperlinks

I knew that I needed to edit the hyperlinks on some of my pages but I forgot that the webparts showing views of my lists would also need to be changed, meaning that the data was actually being displayed from the old site (still left in place until I knew that the migration had been a success). I couldn’t find a way to just edit a link to the list, so I had to replace each webpart with a new version, picking up the appropriate list (and view).  That was issue number 1 sorted.

Corrupted lists with orphaned columns

Most of the lists in my site came across without issue but the largest one (30-odd columns and around 350 items) was generating an error, with the expected data replaced by “One or more field types are not installed properly. Go to the list settings page to delete these fields”. I found various articles about this, but they all seemed to relate to migrations from SharePoint 2007 to 2010.

Then, as I was digging around in the site, I found a “hidden” column that wasn’t visible in the list settings but could be seen when editing list views. The name of the column was familiar though – it matched a workflow that someone had created on the original (source) site but which wasn’t attached to the list. Apparently, when SharePoint starts a workflow on a list for the first time, it adds a workflow status column to the default view of the list  and it seems that “orphaned” workflow status columns are not unheard of. I tried creating another column with the same name (to then delete it again) but, predictably, that wasn’t possible (although creating a new workflow with the same name did create a duplicate column, which was deleted when the workflow was removed).

A little more research turned up “official” advice from Microsoft that suggested these orphaned columns couldn’t be deleted but, as is often the case, there is a way to do it with third party software and a bit of coding, as described by Nik Patel at his SharePoint World. Unfortunately, the SharePoint Manager tool that Nik used needs to be run on the server – there’s no chance of me being able to do that – but our SharePoint admins were not convinced that the orphaned column was causing the issue anyway and found some columns using lookups that were not correctly linked following the list migration. These couldn’t be edited (at least not through the SharePoint web interface), so they were deleted and recreated, before I copied the data back into them. A page refresh later and the list was displayed as expected (so the orphaned column was not the cause), although there was still one final problem…

Broken New and Edit forms

I still had an issue in that attempting to add a new item to the list resulted in “an unexpected error has occurred” messages, which are far from helpful!

A colleague had spotted that the NewForm.aspx and EditForm.aspx forms were incorrectly linked (the list had been renamed at some point and for some reason the original list name was still being used in the path to the forms) but that was easily corrected in SharePoint Designer. Even so, adding or editing an item in the list was generating errors and I was running out of ideas (as were my colleagues).

I thought that I had spotted all of the differences between the two copies of the list (source and target sites) so, I conceded defeat and started to recreate the list from scratch (before copying in the data in data sheet view – I know I can import/export via Excel, but that sometimes results in incorrect column types that can’t be edited). That’s when I found some more corrupted lookup columns. I couldn’t edit them (at least not through the SharePoint web interface) so, again, I deleted and recreated them, before repopulating the data. All of a sudden, my site was working as it should have been – hooray!

Wrap-up

All of the problems I had were avoidable, with the benefit of hindsight, but I’m hoping not to have to migrate too many SharePoint sites in future. I expect I won’t be the last person to go through this process though and hopefully the experiences I’ve written about here will come up on a search when others are looking for help…