When a Custodian Upgrades Their Phone Mid-Case

A mid-case device upgrade refers to the scenario in which an ESI custodian receives or purchases a new mobile phone while active litigation is pending, creating a preservation gap that standard litigation holds were not designed to close. Device-to-device transfers - whether through Apple Migration Assistant or a carrier backup service - are optimized for user continuity, not chain-of-custody documentation. Two categories of ESI disappear. The first is iMessage attachments, which Apple stores locally rather than server-side. The second is third-party app containers used by platforms like Signal and WhatsApp.

The consequence, in my experience, is concrete. I have reviewed collections where a custodian's Exchange mailbox and Microsoft Teams messages were fully preserved while the iMessage thread documenting the disputed conversation was simply absent - because no one imaged the handset before the trade-in. According to EDRM research, collection quality determines downstream review cost and defensibility above any other single variable. In our practice, every output must trace to its exact source exhibit - a standard that only holds if the original device was imaged first.

Why does a mid-case phone upgrade create a distinct preservation problem?

A device upgrade mid-litigation is not a general preservation failure - it is a specific operational gap that leaves two categories of ESI permanently unrecoverable.

The two-category gap is the lens I use to assess any device-refresh scenario: what data migrated to the new handset, and what stayed behind on the device that was surrendered. The two categories that consistently fail to cross - iMessage attachments stored locally on the device and third-party app data from platforms like Signal, WhatsApp, or locally-installed Teams - are also, increasingly, the categories where case-critical communications live. An analysis of current practitioner guidance and case law shows that these categories are absent from most legal hold designs and custodian interview templates, which still center on email and shared drives, as of August 2026.

The reason this matters now is not theoretical. According to eDiscovery Today, in Wilson Aerospace LLC v. Boeing Co. (W.D. Wash., July 2026), Magistrate Judge Michelle L. Peterson held that "a party cannot justify failing to collect obviously relevant documents on the ground that the relevant employee was not designated as an 'ESI custodian.'" The ruling addressed a different gap - a Boeing employee whose documents were not searched because he was not disclosed - but the logic extends directly to device-level gaps. Non-designation, whether of a person or of a device data category, does not constitute a safe harbor under Rule 34 or Rule 37(e).

From what I have seen in ESI collections, the failure happens not during collection but before it: no process routes a device-upgrade request through a litigation-hold check, so the device leaves before anyone knows it needs to be imaged. According to practitioners in the r/ITManagers eDiscovery thread, some legal teams retain physical devices indefinitely in a secure, logged enclosure for precisely this reason - cases run 15 or more years, and software-based recovery after a factory reset is unreliable at best. The operational lesson is blunt: the old handset is the evidence. The new one holds only what the transfer moved across.

What did not migrate is, for practical purposes, gone.

Defensibility in this scenario requires immutable originals with content hashing and an append-only audit trail before the device is surrendered - the process that holds up when opposing counsel challenges the collection, and the standard that a chain-of-custody argument depends on. That standard cannot be met retroactively once the handset has been factory-reset and returned to the carrier.

In summary: the device-upgrade scenario is legally distinct because it combines a specific data-category risk (iMessage attachments and third-party app data) with a process failure (no hold-check before trade-in) that no post-hoc recovery method reliably resolves.

What does a litigation hold actually require from a custodian who upgrades their device?

A legal hold notice establishes the preservation requirement. Custodian compliance determines whether that requirement is actually met - and for mobile devices, the gap between the two is where ESI disappears.

According to Casepoint's custodian compliance guidance, "even the most well-documented legal hold fails without custodian compliance," and custodian compliance is defined as the ability of designated individuals to understand, acknowledge, and consistently follow hold instructions to preserve relevant data and avoid spoliation. The practical problem with mobile devices is that a hold notice does not translate into any technical action on the device itself. The notice reaches the person. It does not intercept the phone.

This distinction matters because the two data categories most at risk in a device upgrade - iMessage attachments and third-party app data - exist entirely outside the compliance mechanisms that hold notices activate. Email accounts are cloud-synced and recoverable from the server. iMessage threads that were never backed up to iCloud, and Signal or WhatsApp history that is stored in the app's local container, are not. A custodian can acknowledge the hold notice sincerely, comply fully with every instruction they were given, and still surrender a device whose most relevant content has never been preserved. The hold notice failed not because the custodian was non-compliant, but because no one told the custodian - or IT - to intercept the device before the trade-in.

The economics of this failure are not abstract. Manual document review runs roughly $19,000 per gigabyte, and review accounts for approximately 73% of the total cost of producing electronic documents in litigation. A device-refresh gap that forces a re-review after an adverse inference motion, or that creates unresolvable sanctions exposure, compounds that cost many times over. In practice, the imaging of a mobile device before trade-in is a fraction of the downstream cost of not doing it.

According to Forensic Discovery, whose chain-of-custody guidance was substantively updated in June 2026, "when preservation waits until after accounts are changed or devices are reused, the same examiner may only be able to describe partial traces and uncertainty." The takeaway is precise: delayed collection does not produce partial evidence. It produces ambiguous evidence, and ambiguity in a chain-of-custody argument is as damaging as absence.

What this means for practice is straightforward. Processing under conditions where privileged evidence never leaves the client's control - running single-tenant or inside the client's own AWS account, with no vendor retention and no model training - ensures that the chain of custody survives challenge at deposition. The trust posture that in-account deployment provides is one that almost no small-firm tool and no consumer AI product can match. The collection process has to be as defensible as the evidence itself.

In summary: a litigation hold establishes the duty; custodian compliance addresses acknowledgment; but neither mechanism automatically preserves what is stored only on a local device. The device-intercept step must be built into the upgrade workflow, not left to the hold notice.

How Does Forensic Mobile Collection Fit Into the EDRM Identification and Preservation Stages?

Forensic mobile collection bridges the identification and preservation stages of the EDRM framework by creating a complete, immutable copy of device contents before the original is released for trade-in.

The collection workflow follows the same discipline as any defensible ESI preservation: the device is isolated from the network to prevent remote wipe, a forensic imaging tool creates a bit-for-bit copy verified against a SHA-256 hash, and an append-only chain-of-custody log records every handler and every transition point. The output is a forensic image that can be interrogated years later without touching the original - with every answer traceable to the exact exhibit it came from.

Where mobile collection differs from server-side preservation is the reliance on the physical device rather than a server connection. eDiscovery cost research has documented in detail how decisions made during identification and preservation compound cost at every downstream stage of the EDRM pipeline. A gap at preservation does not correct itself at review; it becomes more expensive to explain - or impossible to repair - by the time the matter reaches production.

What is the chain-of-custody standard courts apply to mobile device evidence - and where does the device-upgrade scenario fail it?

Courts do not require a perfect chain of custody. They require a defensible one - and the device-upgrade scenario fails that test at the moment the handset is released without documentation.

According to Everlaw's chain-of-custody guide, the standard is defined as "the chronological, documented record of everyone who has handled, accessed, or stored a piece of evidence," and courts evaluate custody against a single question: whether evidence was managed in a "reasonably reliable and defensible manner, not whether handling was perfect." The operative words are documented and defensible. A device surrendered to a carrier without an imaging log, without a hash verification, and without a chain-of-custody transfer record does not meet that standard - not because the handling was malicious, but because it was undocumented. The gap is fatal to admissibility arguments before the evidence question is ever reached.

Everlaw identifies five key transition points that require documentation: collection, handling and access, storage and preservation, transfers between custodians or platforms, and presentation or production. A device trade-in fails at transition point one. Everything that follows is speculation about what the device contained.

The shadow IT dimension compounds this. According to Casepoint's analysis by Oliver Silva, Vice President of Product, as much as 80 percent of company employees use shadow IT platforms for business communications - platforms that legal teams neither monitor nor include in standard custodian interview templates. Signal, WhatsApp, Telegram, and industry-specific messaging tools are the likeliest hosts of case-critical communications, and they are precisely the apps whose data does not cross in a standard device-to-device transfer. In my experience working through ESI collections, the pattern repeats: email and shared drive data is collected on day one, and the attorney learns about the Signal thread at deposition. By then, the old phone is gone.

The takeaway is blunt. Shadow IT is not an edge case; it is the norm. The custodian interview template must be updated before the device leaves.

What changes the risk picture at small-matter scale is defensibility at an accessible price point. Enterprise eDiscovery platforms price out the solo practitioner and the small firm on a single-matter dispute - the exact segment most likely to face a device-refresh gap without a procedure in place, and least likely to have a forensic imaging protocol on the shelf. The answer is not to skip the imaging; it is to have a process that is operable for a solo practitioner on a messy collection. A "bring a real collection and a hard question" approach - where the attorney can evaluate the output against their own evidence before committing - is what I'd recommend before engaging any forensic provider. You learn more from running one hard question through your actual collection than from reading any case study.

In summary: the chain-of-custody standard is achievable for mobile devices, but only if the device is intercepted and imaged before it leaves. Shadow IT data is both the most legally significant category and the one most commonly missing from custodian interview protocols. Those two facts together define the device-refresh risk picture.

The EDRM positions collection as the step that most determines downstream defensibility and cost. Before any device trade-in:

1. FREEZE - Issue hold addendum naming the specific device
2. IMAGE - EnCase forensic capture; generate SHA-256 hash
3. LOG - Record handler, date, and chain-of-custody path
4. ARCHIVE - Single-tenant vault, client-controlled encryption keys
5. RELEASE - Authorize trade-in only after steps 1-4 verified

Why doesn't a standard litigation hold protect mobile data when a phone is traded in?

A litigation hold preserves server-side data and synchronized accounts - it cannot reach data stored only on the device itself unless the handset is imaged before it leaves custody.

In my experience, this is where well-prepared legal teams encounter the gap they were not expecting. The hold notice has been drafted. Custodians confirmed receipt. The matter is properly docketed. Everyone proceeds as if the data is secured, because in the ways they can measure it, everything appears to be in order. What the hold actually preserves is what lives on servers - Exchange and Microsoft 365 mailboxes, shared drives, calendar entries that synchronize upward to managed infrastructure. What it cannot reach is what exists only on the device: iMessage attachments that Apple does not store server-side, and the local containers maintained by third-party applications that were never designed to replicate their contents to corporate infrastructure.

According to practitioners in the Microsoft 365 administrator community, a litigation hold and a retention policy operate on fundamentally different mechanics. Litigation holds are immutable and apply to mailbox data at the server level. Retention policies govern how long that data persists before deletion eligibility. Neither mechanism touches local device storage. A custodian's Exchange mailbox can be fully preserved under a hold while that same custodian's iMessage threads and Signal conversations remain unprotected the moment the phone is traded in.

There is a definitional problem that compounds the operational one. The word "custodian" carries entirely different obligations depending on legal context. In trust and estate law, a custodian holds assets on behalf of a beneficiary - an administrative function with no obligation to preserve personal documents. In eDiscovery, an ESI custodian is anyone who created, used, or stored potentially relevant electronically stored information. That definition reaches far beyond what most employees expect when they receive a legal hold notice. It can include a field technician who documented a site condition in a third-party application, or a junior employee whose text thread referenced a disputed contract term. An employee who reads "custodian" on a hold notice without further guidance may understand it in the financial or administrative sense - not as a preservation obligation that extends to the phone in their pocket.

Hold notices that do not explicitly name personal mobile devices and third-party applications leave this gap open. The failure is not purely technical. It is also instructional.

Every answer in litigation must trace to its source and link back to the exact exhibit it came from. When the source - the original device - has been traded in without imaging, that standard becomes impossible to meet, and the incomplete record that remains is the one opposing counsel will examine.

How do you protect mobile ESI when a custodian needs to upgrade their phone mid-case?

The answer is to image the old handset before it leaves custody - forensic imaging captures what device-to-device transfers miss, and the original capture stays under your control.

Device transfer is not device preservation. When a custodian moves to a new phone - through Apple's migration flow, a carrier-assisted transfer, or a manual backup restore - the process is optimized for the user. Contacts, photos, and application credentials carry over. What does not carry over are the forensic artifacts: file system metadata, deleted-but-recoverable fragments, timestamp records, and the locally-stored attachment data that distinguishes a defensible collection from an incomplete one. The migration was never designed to satisfy opposing counsel's authentication requirements. It was designed to get the user back to work.

The practical resolution is a forensic image of the original device, taken before the trade-in, processed in an environment where the evidence stays under the client's control at every stage. In our ESI collection work, privileged evidence never leaves the client's environment: processing runs single-tenant in the client's own infrastructure, no data is retained by the vendor after the engagement, and nothing is used to train models. That last point is more consequential than it first appears. When a collection is processed through pooled third-party infrastructure, the client cannot always account for where their data resided during processing or who had access to it. A single-tenant, client-controlled environment closes that gap by design.

In financial and estate law, when a custodial relationship transfers to a successor, there is a formal handoff: assets are documented, accounted for, and transferred under record. The eDiscovery analog to that formalization is the device imaging step - a required precondition before the old phone changes hands, not an optional step taken if someone on the legal team remembers to ask.

According to eDiscovery cost research, technology-assisted review can reduce document review time by as much as 80 percent. In practice, that efficiency is only available when the underlying collection is complete. A forensic image of the original device, paired with AI-assisted review, makes the phone-upgrade scenario manageable. The obstacle is not the data volume. It is whether the image was taken.

According to exchange server administrators who manage litigation hold configurations, a litigation hold is immutable once applied - it cannot be modified or deleted. That immutability is the legal structure. The forensic image is the physical structure that gives the hold meaning for device-local data. One without the other leaves the device-upgrade gap exactly where it started.

What Will Shape How Courts and Legal Teams Handle Mid-Case Phone Upgrades Over the Next Two Years?

Three converging forces will make the device-upgrade scenario far more legally consequential over the next two years than most litigation teams currently treat it.

What most legal and IT teams miss is the assumption embedded in "migration is preservation." Device-to-device transfer tooling was designed for consumer convenience, not litigation defensibility - and courts are not extending it that grace. The organizations carrying the greatest exposure are not the ones that lack forensic capability; they are the ones that upgraded a custodian's device, assumed the data moved, and never verified what the transfer left behind.

In my view, the device-upgrade scenario grows more consequential as AI-assisted review becomes standard practice - not easier. The gap is specific: iMessage attachments and third-party app containers disappear from device transfers in a way that no server-side preservation can recover. The fix is equally specific: a forensic image of the original device, taken before trade-in, is the source that every downstream output traces back to its exact exhibit.

The forward-looking claim I would make is this: as AI review tools become faster and cheaper, the cost advantage shifts entirely to the collection phase. According to EDRM research, front-end collection quality is already the dominant driver of total litigation cost. In our practice, every collection is processed single-tenant in the client's own infrastructure, with immutable originals and hash verification that make the record defensible on its face before the first attorney opens a document for review.