Key Takeaways
- eDiscovery TCO spans five cost categories - software licensing is usually thesmallestof them, and document review labor is typically the largest.
- Per-GB and per-document pricing models tie your costs to data volume, which you don't control - that's where budget surprises come from.
- A credible TCO model is built per matter, then annualized: this guide walks through the method and includes an interactive calculator.
- Consolidating disconnected tools changes the math by removing handoff costs, duplicate hosting, and idle-time between stages.
- Use the downloadable Excel calculator to build a defensible budget figure for your GC or CFO.
The Migration Objection: Why "Active Matters" Stops Platform Switches
The objection deserves respect: moving a matter mid-review is genuinely risky. Re-processing can shift document counts, work product can garble in translation, and a court will not accept "we were changing vendors" as an explanation for a production discrepancy. Anyone who waves this off hasn't done a migration.But notice what the objection actually forbids: moving active matters. It says nothing about where new matters open. That distinction is the entire playbook. A well-run platform switch is an attrition model - new matters open on the new platform from day one, active matters finish where they started, and the old platform winds down as its caseload naturally closes. Almost nothing moves mid-flight; the "migration" is mostly a change of default, plus a small number of deliberate cutovers you choose case by case.Framed that way, the risk profile inverts. The dangerous project is the big-bang cutover nobody is actually proposing. The attrition model's worst case is that a matter takes a few months longer on the old platform than you'd like - a scheduling cost, not a defensibility one.
Phase 1 - Audit and Preparation (Weeks 1–4)
Before anything moves, inventory what exists. The audit is half the migration — most surprises that derail transitions were visible in week two of a good audit.
| Inventory | What to Capture | Why It Matters |
|---|---|---|
| Matters, by state | Active (in review), active (pre-review), dormant, closing within 90 days, closed-but-hosted. | Each state gets a different disposition in Phase 3. |
| Data volumes & formats | GB per matter, source formats, load-file availability, imaging status. | Sizes the archive decision and any cutover effort. |
| Work product | Coding schemes, tags, redactions, privilege logs, saved searches, production history. | The list of what must survive any move - test against it. |
| Holds & obligations | Active legal holds, custodians, preservation obligations, protective orders. | Holds must transfer with zero gaps; obligations may constrain timing. |
| Contracts & renewal dates | Current platform's renewal date, notice period, data-export terms, hosting minimums. | The renewal date is your deadline; export terms are your leverage. |
Close the phase by testing the exit: export one real workspace from the old platform and have the new vendor ingest it - coding, tags, and redactions included - while you audit what survives. Do this before contracts are signed, on your data. It converts the vendor's migration claims into observed fact, and it rehearses the exact motion any later cutover will use.
Phase 2 - Parallel Running (Weeks 5–8)
Parallel running has a bad reputation because people imagine running every matter twice. That's not the model. The rules of the road are simpler:
- Every new matter opens on the new platform. No exceptions without a named approver — exceptions are how transitions quietly die.
- Active matters continue on the old platform, untouched, with the same teams and workflows.
- No matter exists on both platforms. One system of record per matter, always.
- The first two or three new matters get white-glove attention - vendor support on standby, and a documented retro after each.
The overlap window costs money - you're paying two platforms for a quarter or two. Budget it explicitly (the business-case math should already include it) and contain it by timing Phase 2 against the old platform's renewal date: start parallel running early enough that the caseload has thinned before you're asked to renew for another year.
Phase 3 - Matter Cutover (Weeks 9–12 and Beyond)
Most matters never migrate - they finish where they are. Cutover is a deliberate, per-matter decision, and the default answer is no. A matter earns a cutover only when the math clearly favors it:
- Long-running matters early in their life. A matter with two years left and review barely started repays the one-time move; a matter three months from closing never does.
- Dormant matters that may reactivate. Move them while nothing is in flight - a cutover with no active review is a data operation, not a litigation event.
- Matters trapped by cost. Where old-platform hosting fees on a large matter exceed the cost of moving it, the invoice makes the decision.
For each matter that does move, run the same runbook the Phase 1 test rehearsed: freeze, export, ingest, verify work product against the audit list, run a comparison report on document counts and coding, sign off with the matter team, then - and only then - retire the old workspace. Document each step; the runbook record is the defensibility answer if the move is ever questioned.
Data Migration: What Moves, What Doesn't, What to Archive
| Category | Disposition | Mechanics |
|---|---|---|
| New-matter data | Native to the new platform from day one. | No migration involved - this is most of your future volume. |
| Cutover matters | Move whole, with work product. | Load files (.DAT/.OPT), production sets, coding/tag maps; verify counts post-ingest. |
| Matters finishing in place | Don't move. Export final productions + work product at close. | Standard close-out exports; archive per policy. |
| Closed-but-hosted matters | Archive out of the old platform - don't pay hosting for storage. | Export to neutral formats (natives + load files + productions); store per retention policy. |
| Legal holds | Transfer with zero gap. | Recreate holds on the new platform before releasing anything on the old; overlap is fine, gaps are not. |
The quiet win in this table is the archive row: most organizations discover they've been paying active-hosting rates for closed matters no one has opened in a year. The migration is the forcing function that finally cleans it up - and the savings often fund the overlap window.
User Training and Adoption During a Transition
Platforms don't fail transitions; adoption does. Three practices keep the people side on schedule:
- Train by role, on real work. Reviewers, case managers, and admins need different two-hour sessions, not one generic day - and the training matter should be a copy of a real one, not vendor demo data.
- Name champions before go-live. One power user per team, trained first and thoroughly. Colleagues' questions go there sooner than to any help desk, so equip that person on purpose.
- Measure adoption weekly. New matters opened on the new platform, time-to-first-production, support tickets by category. When exceptions to the "all new matters" rule creep up, the transition is drifting - catch it in the weekly number, not the quarterly review.
A Sample 90-Day Migration Timeline
| Weeks | Workstream | Exit Criteria |
|---|---|---|
| 1–2 | Kickoff; matter/data/holds/contract audit; export terms confirmed. | Audit tables complete; renewal-date deadline set. |
| 3–4 | Platform setup: security model, matter templates, integrations; workspace-ingest test on real data; role-based training + champions. | Test workspace verified against work-product list; teams trained. |
| 5–8 | Parallel running: all new matters on the new platform; white-glove first matters; weekly adoption metrics. | 2–3 matters running end-to-end; zero unapproved exceptions. |
| 9–12 | First deliberate cutovers (dormant + long-running early-stage matters); archive closed-but-hosted matters; legacy wind-down plan against renewal date. | Cutover runbook proven; archive complete; wind-down dated. |
Beyond day 90, the old platform is in managed decline: no new work, a thinning caseload, and a diarized decision point at each renewal. Steady state typically arrives inside a year - without a single active matter ever having been disrupted.
Download the 90-Day Migration Plan
The full playbook as a working document - audit inventory checklist, phase plan with owners and dates, the week-by-week timeline, and the per-matter cutover runbook. Print it, assign it, run it.
At Venio, we're committed to your privacy. For details on how we process your data, please review our Privacy Policy.
How Venio Runs Migrations
Everything above is platform-neutral - it's how good transitions work wherever you land. Venio's job is making each phase smaller:
- The Phase 1 test is standard practice. Venio ingests a real workspace from your current platform pre-sale - load files, coding, tags, redactions - so the audit's "what survives" question is answered with your own data before you commit.
- Work product is retained. Load-file ingestion (.DAT/.OPT) with coding and tags preserved, production sets ingested as standard features.
- The overlap window costs less. Zero per-GB ingestion fees during migration, and fixed annual pricing means cutover and archive volumes don't add a meter to the transition budget.
- Matter templates compress Phase 2. Your intake path, security model, and workflows are templated in setup week, so matter fifty costs no more setup than matter five.
Related reading: for the data-mechanics layer - formats, chain of custody, integrity checks - see our post on eDiscovery data migration. This guide is the program; that post is the plumbing.
Frequently Asked Questions
Everything you need to know about Migration Guid
Do we have to move our active matters to a new platform?
No - and in a well-run transition, you shouldn't. New matters open on the new platform; active matters finish where they started; only a small set of long-running or dormant matters earn a deliberate, per-matter cutover. The "we can't disrupt active matters" objection argues against a big-bang cutover nobody should propose, not against switching platforms.
How long does an eDiscovery platform migration take?
The structured program runs about 90 days: audit and preparation in the first month, parallel running in the second, first cutovers and archiving in the third. Full steady state - old platform retired - typically lands inside a year, driven by how fast the legacy caseload closes and when the old contract renews.
What is typically the largest eDiscovery cost category?
Document review labor, in most matters. Human review hours are widely recognized as the dominant share of eDiscovery spend, which is why culling, early case assessment, and AI-assisted review are the highest-impact cost levers - they shrink the number of documents a person has to read.
What survives a migration - coding, tags, redactions?
With load-file-based migration done properly: coding, tags, redactions, and production history all transfer, and the post-ingest verification step proves it with document-count and coding comparison reports. The reliable way to know for your data is the Phase 1 test: have the new vendor ingest one of your real workspaces before you sign, and audit what arrives.
Won't we pay for two platforms during the transition?
For the overlap window, yes - budget it honestly rather than hiding it. Contain it by timing the transition against your current contract's renewal date, archiving closed-but-hosted matters out of the old platform early (often a significant hosting saving), and choosing a destination platform without per-GB ingestion fees so the move itself doesn't add a meter.
