Migrated Files Lose Created By Metadata: Root Cause and Fix

When you migrate files to SharePoint, the Created By column often shows the migration account instead of the original author. This happens because the migration tool does not preserve the original author identity by default. The Modified By column may also show the migration date rather than the original modification date. This article explains why this metadata loss occurs and provides two reliable methods to preserve the original author and date information during migration.

Why Migrated Files Lose the Original Created By Metadata

When you migrate files from an on-premises file share, a third-party cloud service, or another SharePoint environment, the destination system assigns the migration account as the creator. The underlying cause is that SharePoint treats the migration process as a new file creation event. The file content and structure are copied, but the metadata fields Created By, Created Date, Modified By, and Modified Date are overwritten with current user and timestamp values. This happens because the SharePoint API does not allow setting these system fields directly through standard upload operations. Most migration tools, including SharePoint Migration Tool (SPMT), require explicit configuration to preserve this metadata. Without that configuration, the original author identity is lost.

How SharePoint Stores Created By and Modified By

SharePoint stores Created By and Modified By in the Author and Editor fields of the list item. These fields are read-only for most users and can only be modified through the object model or by an account with elevated permissions. When a file is uploaded or migrated, SharePoint sets these fields to the account performing the action. The only way to retain the original values is to use a method that directly writes to these fields during or after the migration.

Steps to Preserve Created By and Modified By During Migration

You have two main approaches: configure user mapping in the migration tool before migration, or use PowerShell to correct metadata after migration. The first method is cleaner and requires less effort. The second method is a fallback if you already completed the migration without preserving metadata.

Method 1: Use SharePoint Migration Tool with User Mapping

1. Download and install SharePoint Migration Tool
   Go to the Microsoft 365 admin center and download SPMT. Install it on a machine with access to both the source files and the target SharePoint site.
2. Create a new migration job
   Open SPMT and select Start your first migration. Choose File shares or the appropriate source type. Enter the source path and the target SharePoint site URL.
3. Enable user mapping
   In the migration settings, scroll to User mapping. Select Map users. Download the user mapping template CSV file. Open the CSV in Excel. In the first column, enter the source user principal name (UPN). In the second column, enter the target UPN. For example: olddomain\jsmith maps to jsmith@contoso.com. Save the CSV and upload it back into SPMT.
4. Configure date preservation
   In the same settings area, expand Advanced settings. Check the box Preserve file creation and modification dates. This tells SPMT to write the original timestamps into the Created and Modified fields.
5. Run the migration
   Click Start. Monitor the progress. After completion, verify that the Created By column shows the original author and the Created Date shows the original timestamp.

Method 2: Correct Metadata After Migration Using PowerShell

If you already migrated files and the metadata is incorrect, use PnP PowerShell to update the Author and Editor fields. This method requires the SharePoint Administrator role or site collection owner permissions.

1. Install PnP PowerShell module
   Open Windows PowerShell as an administrator. Run Install-Module PnP.PowerShell -Scope CurrentUser. Press Y to confirm installation.
2. Connect to your SharePoint site
   Run Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/yoursite -Interactive. Sign in with an account that has site collection admin permissions.
3. Get the target user
   Run $user = Get-PnPUser -Identity "originalauthor@contoso.com". This retrieves the user object for the person who should be the original author.
4. Update the Author field on a specific file
   Run Set-PnPListItem -List "Documents" -Identity 1 -Values @{"Author" = $user.Id; "Editor" = $user.Id} -UpdateType UpdateOverwriteVersion. Replace 1 with the list item ID of the file. The UpdateOverwriteVersion parameter writes directly to the current version without creating a new version entry, which preserves the original author in the version history.
5. Update multiple files using a CSV
   Create a CSV file with columns ItemID, AuthorEmail, and EditorEmail. Run a loop: Import-Csv "C:\metadata.csv" | ForEach-Object { $author = Get-PnPUser -Identity $_.AuthorEmail; $editor = Get-PnPUser -Identity $_.EditorEmail; Set-PnPListItem -List "Documents" -Identity $_.ItemID -Values @{"Author" = $author.Id; "Editor" = $editor.Id} -UpdateType UpdateOverwriteVersion }.

Common Issues When Metadata Is Not Preserved

Migration Tool Shows User Mapping But Created By Still Shows Migration Account

This usually means the user mapping CSV file was not uploaded correctly or the source user names do not match. Verify that the source UPN in the CSV matches exactly what appears in the source file system. For file shares, the source identity is typically the user’s Windows login name in the format DOMAIN\username. If the CSV is correct, re-run the migration job with the Overwrite option enabled.

PowerShell Script Returns Permission Denied Error

The account running the PowerShell commands must have site collection administrator permissions. If you are using a tenant admin account, you still need to grant explicit site collection admin access. Go to SharePoint admin center > Active sites > select the site > Members > Site admins > Add your account. Wait 10 minutes for permissions to propagate, then run the script again.

Version History Shows Migration Account as Creator Even After Update

The UpdateOverwriteVersion parameter updates the current version’s metadata but does not retroactively change previous versions. If you need to fix all versions, you must delete or overwrite the entire version history. This is not recommended for compliance reasons. Instead, accept that only the current version shows the correct author. Future edits will preserve the corrected metadata.

Comparison of Metadata Preservation Methods

Item	SPMT with User Mapping	PowerShell After Migration
When to use	Before migration starts	After migration is complete
Effort	Low — configure once in the tool	Medium — requires scripting per file
Preserves Created By	Yes, when user mapping is correct	Yes, for current version only
Preserves Created Date	Yes, when date preservation is enabled	No — date fields are read-only after creation
Permissions needed	Site member with contribute rights	Site collection administrator
Supports bulk operations	Yes, by default	Yes, with CSV import

Migrated files lose the original Created By metadata because SharePoint treats each upload as a new creation event. To prevent this, use SPMT with user mapping and date preservation enabled before running the migration. If the migration is already complete, use PnP PowerShell with the UpdateOverwriteVersion parameter to correct the Author and Editor fields on the current version. For future migrations, always test a small batch first and verify the metadata in the target library before scaling up. Consider using the SharePoint Migration Assessment Tool to identify all files that need metadata correction.