SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've created a console application to migrate files from legacy SharePoint servers to a new server utilizing SharePoint Foundation 2010. I'm using Lists.asmx to get list information and update three fields on the source lists: Migrated (boolean), MigrationStatus (multi-row text), and MigrationDate (DateTime).

I am using the WCF data services to upload the file to the new platform. The process is simple: (1) get certain number of items from source list; (2) check data to see if it meets standards for new platform; (3) if passes validation, upload to new SP2010 library, otherwise, update source library on WSS or MOSS to indicate why the data does not meet standards. Everything is working well with one huge caveat.

The content database's log files for the source content database are growing at an alarming rate. It appears that the log file is growing at a rate equal to the file size that is migrated. In other words, if I migrate 20 files that are 6MB each, the log will grow approximately 120MB. For such few files that is way TOO much. I have to migrate 45000 files.

No columns are indexed for this particular library. Versioning was on, but it has been turned off. With versioning off, the log files are still growing out of control during the migration. I am migrating approximately 50GB, and space is an issue.

So, my question....

What am I missing? By updating three fields, is a new version also being created without my knowledge, or is something else occurring?

The update code is below:

    public void SetMigrationStatus(string sourceList, int itemId, bool migratedSuccessfully, string migrationMessage, DateTime migrationDate) {
        var xmlDoc = new XmlDocument();
        var updateElem = xmlDoc.CreateElement("Batch");
        var updateXmlText = new StringBuilder();           

        updateXmlText.Append("<Method ID='1' Cmd='Update'>");
        updateXmlText.Append(string.Format("<Field Name='ID'>{0}</Field>", itemId));
        updateXmlText.Append(string.Format("<Field Name='Migrated'>{0}</Field>", migratedSuccessfully));
        updateXmlText.Append(string.Format("<Field Name='MigrationStatus'>{0}</Field>", migrationMessage));

        if (migratedSuccessfully) {                
            updateXmlText.Append(string.Format("<Field Name='MigrationDate'>{0}</Field>",
                string.Format("{0} {1}",


        updateElem.SetAttribute("OnError", "Continue");
        updateElem.SetAttribute("ListVersion", "1");
        updateElem.InnerXml = updateXmlText.ToString();

        var results = ListsServiceProxy.UpdateListItems(sourceList, updateElem);
share|improve this question
up vote 1 down vote accepted

Are you permitted to switch the SQL logging option on your source database to "simple" for the duration of the migration? This should resolve the immediate issue.

(I guess it will depend on your backup strategy and SLAs.)

share|improve this answer
Argh! This resolves my problem, but I was hoping there was going to be a magic property that I may have been missing on the web service or on the document library. Thanks! – Alban Oct 4 '11 at 16:26
I'll up-vote your answer once I have enough reputation points. – Alban Oct 4 '11 at 16:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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