Stop Collecting Links, Start Preserving Versions

You've preserved the email. You've captured the link. You think you're done.

You're not. The document behind that link is changing, right now, while you read this sentence. When opposing counsel asks you to produce the spreadsheet your CFO shared in March, you'll retrieve whatever version exists today, not the version your CFO actually sent. And you won't know the difference until it's too late.

This isn't a theoretical problem anymore. Recent data from Microsoft Graph shows that 75.3% of linked documents no longer carry the same version identifier months after being sent. For Office files specifically, that number climbs to 81.9%.

Your legal hold process assumes document stability. That assumption is wrong.

The Problem: Version Drift Is Now the Default State

Traditional eDiscovery workflows were built for attachments: static files that travel with the email and stay frozen in time. When you preserve the message, you preserve the file.

Cloud collaboration broke that model. Modern users share links, not attachments. The link points to a living document that multiple people can edit simultaneously. The platform tracks versions, but it doesn't freeze them. SharePoint and OneDrive will eventually age out old versions according to their retention policies. By the time you need to produce that document for discovery, the send-time version may no longer exist in the version history at all.

Consider what happens during a typical legal hold. You issue the hold notice. Your custodians stop deleting files. But they don't stop editing them. The collaborative spreadsheet tracking settlement negotiations continues to evolve. The briefing deck your team shared with outside counsel gets revised seventeen more times. The version you can retrieve six months later bears little resemblance to what was actually sent.

The data shows this isn't edge-case behavior. More than half of the modified links reached their current version state within 30 days of being sent. Thirty percent changed within one week. The median Office document that changed post-send accumulated 16 to 20 version increments. Some files showed version differences exceeding 100.

What You Need Before Starting

Platform access:

• Microsoft Graph API credentials with Sites.Read.All and Files.Read.All permissions
• Admin consent for your tenant

Preservation infrastructure:

• Email journaling or equivalent capture system that can intercept messages at send time
• Storage for version metadata (not file contents, just identifiers and timestamps)
• Scheduled job capability for periodic version reconciliation

Legal and compliance alignment:

• Documented Records Control Schedule that addresses linked documents
• Legal Hold procedures that explicitly cover version preservation
• Records Control Schedule that specifies version-history preservation periods in SharePoint

Skills:

• PowerShell or Python scripting for Graph API calls
• Understanding of SharePoint version numbering (major vs. major.minor schemes)
• Familiarity with your organization's file-sharing patterns

You don't need to preserve every version of every file. You need to preserve the versions that matter for compliance and discovery, starting with the versions that were actually transmitted.

Step-by-Step Implementation

Phase 1: Capture send-time version state

Configure your email preservation system to extract and store three data points for every link in outbound and inbound messages:

1. The Microsoft version identifier at send time
2. The sharing URL
3. The send timestamp

If you're using a custom journaling solution, add a parser that recognizes SharePoint and OneDrive URLs in message bodies. Extract the site ID, drive ID, and item ID from each URL. Call Microsoft Graph immediately:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{item-id}

Store the eTag value (Microsoft's version identifier) alongside the link and timestamp. Do not retrieve file contents at this stage; you're capturing version state, not creating a secondary copy.

Phase 2: Schedule periodic version reconciliation

Set up a scheduled job that queries Microsoft Graph for current version state on previously captured links. Start with a 30-day interval based on the velocity data, half of all modifications occur within the first month.

For each stored link:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{item-id}

Compare the current eTag to your stored send-time eTag. If they differ, retrieve the versions collection:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{item-id}/versions

Check whether the send-time version still exists in the history. If it does, record its position. If it doesn't, flag the link for preservation escalation.

Phase 3: Preserve at-risk versions

When your reconciliation job identifies a send-time version that's about to age out of SharePoint's version history, trigger content preservation:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{item-id}/versions/{version-id}/content

Store the file contents in your preservation repository with metadata linking it back to the original email event. Tag it with the send timestamp, sender, recipients, and version identifier.

This is selective preservation, not wholesale backup. You're capturing the specific versions that were transmitted or referenced in business communications.

Phase 4: Integrate with Legal Hold

Update your Legal Hold procedures to include version-preservation instructions:

When issuing a hold, query your version-tracking database for all links sent or received by custodians during the relevant period. Generate a preservation report showing:

• Links where the send-time version no longer matches current state
• Links where the send-time version has aged out of platform history
• Links requiring immediate content capture

Provide this report to counsel alongside the traditional custodian list.

Validation: How to Verify It Works

Test the capture pipeline: Send yourself an email containing a SharePoint link. Verify that your system captured the version identifier within seconds of sending. Edit the linked document. Wait for your reconciliation job to run. Confirm it detected the version change.

Measure coverage: Query your version-tracking database for the past 90 days. Calculate what percentage of outbound links have version metadata. If you're below 95%, you have a capture gap, investigate journaling delays or parser failures.

Audit version availability: Select 100 random links from 6+ months ago. For each link where the version changed post-send, check whether the send-time version still exists in SharePoint's version history. If fewer than 80% are still retrievable, your SharePoint version-Records Control Schedule is too aggressive, extend it or accelerate your preservation trigger.

Validate against discovery: During your next document production, compare the versions you preserved at send time to the versions you would have collected using traditional "preserve the current state" methods. Quantify the difference. Share the results with counsel.

Maintenance and Ongoing Tasks

Monthly:

• Review version-drift statistics by department and file type
• Identify custodians whose shared documents show unusually high modification rates
• Update Legal Hold training materials with real examples from your data

Quarterly:

• Audit preservation storage growth, are you capturing more versions than your Records Control Schedule requires?
• Test recovery: can you retrieve and produce a send-time version from six months ago in under 24 hours?
• Review SharePoint version-retention policies against your actual drift patterns

Annually:

• Recalibrate your reconciliation frequency based on observed velocity
• Update your Records Control Schedule to reflect measured version-lifecycle data
• Train new custodians on the difference between "I shared the file" and "I preserved the version I shared"

When legal holds are issued: Query your version database immediately for in-scope links. Don't wait for the next scheduled reconciliation. Preserve at-risk versions within 48 hours of hold notice.

When holds are released: Review disposition authority before deleting preserved versions. Some jurisdictions require you to retain the version you produced, even after the underlying matter closes.

The era of static attachments is over. Your preservation strategy needs to account for the reality that shared documents are living artifacts. Start capturing version state at send time, or accept that you're collecting evidence that may not reflect what was actually communicated.