I'm currently using SPExportSettings and SPImportSettings to migrate some content from an old 2007 environment.

The below code is all working fine, as designed, but not as I'd like. My document libraries need to retain their internal ID's after the migration.

Because I have RetainObjectIdentity = $true on the import, that seems to keep the libraries URL structure in tact, so it ignores my $_destWebUrl, for where to import to (they originate in the rootweb so they are being deployed to the new rootweb).

If I set RetainObjectIdentity = $false, then it's imported to the subsite as I'd like, but the ID's are all gone.

Desired Source: http://sharepoint/MigrationSource

Desired Target: http://sharepoint/MigrationTarget/SUBSITE

Relevant export code:

$settings = New-Object Microsoft.SharePoint.Deployment.SPExportSettings
$settings.SiteUrl = $_sourceSite
$settings.ExportMethod = [Microsoft.SharePoint.Deployment.SPExportMethodType]::ExportAll
$settings.IncludeSecurity = [Microsoft.SharePoint.Deployment.SPIncludeSecurity]::All
$settings.FileLocation = $_fileLocation
$settings.FileCompression = $true
$settings.BaseFileName = $_fileName
$settings.OverwriteExistingDataFile = $true
$settings.IncludeVersions = [Microsoft.SharePoint.Deployment.SPIncludeVersions]::All


foreach ($obj in $_exportObjs)
    # Create a new SPExportObject which contains the content to be exported
    $exportObject = New-Object Microsoft.SharePoint.Deployment.SPExportObject
    $exportObject.IncludeDescendants = [Microsoft.SharePoint.Deployment.SPIncludeDescendants]::All
    $exportObject.Type = [Microsoft.SharePoint.Deployment.SPDeploymentObjectType]::List
    $exportObject.Id = $_spweb.Lists.TryGetList($obj).ID
    Write-Host `t`t$obj" has been added"

And import code:

$settings = New-Object Microsoft.SharePoint.Deployment.SPImportSettings
$settings.SiteUrl = $_destSiteUrl
$settings.WebUrl = $_destWebUrl
$settings.FileLocation = $_fileLocation
$settings.BaseFileName = $_fileName
$settings.FileCompression = $true
$settings.RetainObjectIdentity = $true
$settings.UserInfoDateTime = [Microsoft.SharePoint.Deployment.SPImportUserInfoDateTimeOption]::ImportAll

If there is no way around this issue, is there a way to move a document library, within a site collection, while retaining all internal ID's?

  • I'll noodle on this a bit, but in the meantime can I ask why you want to retain the IDs?
    – Rob D'Oria
    Commented Sep 2, 2011 at 0:37
  • I'm assisting in a migration on an asp.net app that is living in SharePoint. The original developers made it a requirement. They use the ID's, in some way, in their custom DB. Commented Sep 2, 2011 at 1:09
  • We might be able to get away with allowing the library ID's to change, and attempt to keep the ListItem ID's (if possible). Commented Sep 2, 2011 at 1:10
  • That's what the RetainObjectIdentity property does...retains the list item's GUID. As far as I know it does not retain the ID of the list/library.
    – Rob D'Oria
    Commented Sep 2, 2011 at 1:18
  • I'm able to do either: 1) Migrate the entire library and list items, retain the ID's (but not in the desired location), or 2) Migrate the library to the desired location, but without the ID's. Commented Sep 2, 2011 at 12:39

1 Answer 1


Answering my own question here after I've had some time to look at it. This is expected functionality. If a List/Library exists in the Root web, in order to keep its identity, it can only be imported into the root web of the target site.

Of course, if you choose NOT to retain identities, you can subscribe to the SPImport's events and set their parents.

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.