Migration API: Files with exactly 2 versions imported with incorrect version numbers and dates

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

Linux

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• Target: SharePoint Online (multiple tenants tested)
• Authentication: App-based (Application permissions)
• Migration method: CreateMigrationJob via CSOM
• Noticed in GCC High Sharepoint.

Describe the bug / error

When using the SharePoint Migration API (CreateMigrationJob) to import a file with exactly 2 versions (one historical version and the current version), the resulting file in SharePoint Online displays both versions as v1.0 with identical modified dates (using the latest version's date). This does not occur for files with 3 or more versions.

The actual result is the Version history displays:

• Version 1.0 — with v2.0's modified date
• Version 1.0 — with v2.0's modified date

Both entries show as v1.0 and both reflect the latest version's timestamp. If a user opens a file and a new version is saved, one of the v1 versions disappears and cannot be recovered.

Some Additional Notes:

• Files with 3 or more versions in the same migration batch import correctly with proper version numbers and dates
• Sometimes, files do come through as V1 and V2, but more often than not we get the V1 V1 issue.
• Each version entry in the manifest has a unique GUID (Id), unique FileValue blob reference, and distinct timestamps
• The <ListItem> element uses Version="1.0" as expected
• This has been reproduced across multiple SPO environments
• Possibly related to #6720, which reports version modified dates defaulting to the last version's date. This issue additionally affects version numbering and appears to be isolated to the 2-version case

Steps to reproduce

1. Create a migration manifest with a file containing 2 versions
2. The outer <File> element has Version="2.0" with appropriate metadata
3. The <Versions> node contains two <File> entries:
   • v1.0 with its own Id, FileValue, TimeLastModified, Author, ModifiedBy
   • v2.0 (current) with its own Id, FileValue, TimeLastModified, Author, ModifiedBy
4. Submit the migration job via CreateMigrationJob
5. Check version history on the migrated file in SharePoint Online

Expected behavior

Version history displays:

• Version 1.0 — with v1.0's original modified date
• Version 2.0 — with v2.0's original modified date