In line with Microsoft's recommendation to keep content databases on SharePoint 2007 under 100Gb, we often move site collections to different content databases to balance the load. However, we have noticed a problem - after we move the site collection to a new content database, the entries in the search index for everything in the site collection disappear.

This seems strange as the paths are all maintained exactly as they were before so they should all still searchable in the exact same way. Alternatively, if the crawler wants to kick out these entries it should re-create entries for the "new" data that was relocated to another content database.

This is a big problem for us as part of our system architecture is to "archive" finished site collections to archive content databases on bigger, slower hard drives so the content is still on-line and searchable, just not on the super-fast disks that the live content is on.

Is there any way to stop this happening or to force the site to be re-crawled in its new content database? We don't want to do a full crawl as the last one we did took more than eight days and in any case we would still have the same problem after the full crawl when we next move site collections.

2 Answers 2


We raised a support issue with Microsoft and they confirmed that sites disappear from the search results when using STSADM -o mergecontentdbs to move the site collections, as we were doing.

If you move the sites using the BatchSiteManager from the SharePoint Administration Toolkit then the sites don't disappear from search. Unfortunately, we require an automated system so this workaround isn't appropriate for us but maybe this will work for you.

It has to do with the events that are logged when a site is moved. The incremental crawler uses the EventCache to work out what needs to be crawled. STSADM only puts one entry in this table whereas the toolkit puts in more than ten entries. Accordingly, when using STSADM the incremental crawler thinks the site has been deleted whereas with the toolkit it knows it has been moved.

Using Powershell with SharePoint 2010 doesn't have this problem.


I don't know that there is anyway around this.

  • While this post may answer the question, we prefer more details such as why. Can you please edit your post with additional details?
    – Alex Angas
    Commented Jul 12, 2011 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.