When Your Platform Goes Away
Platform migrations in eDiscovery are rarely planned. They are typically forced by circumstances: your vendor gets acquired and the new owner announces end-of-life for the product you rely on, pricing increases make the platform economically unviable, the system cannot handle the data volumes your matters now require, or your contract simply expires and renewal terms are unacceptable. Whatever the trigger, you are suddenly facing the highest-risk operation in litigation technology — moving active matter data from one system to another without losing anything.
The risks are substantial and well-documented. Data loss during migration can compromise your ability to meet discovery obligations. Work product — coding decisions, search histories, privilege designations — represents hundreds or thousands of attorney hours that cannot be recreated from scratch. Production histories must be preserved to demonstrate what was produced, when, and to whom. And all of this must happen while your matters continue to move forward, with court deadlines that do not pause for technology transitions.
The Federal Production Remediation case that DecoverAI handled illustrates the worst-case scenario. When a platform was decommissioned mid-matter, the resulting production failures required complete remediation of over 360,000 documents. Bates numbering had to be corrected, privilege logs reconciled, metadata validated, and redactions reapplied — all because the original migration was not managed with sufficient care. The cost of that remediation dwarfed what a properly planned migration would have required.
This guide walks through the steps of a safe platform migration, from initial inventory through post-migration validation. The key principle throughout is simple: verify everything twice, and do not decommission your old platform until you are certain the migration is complete. The cost of maintaining access to your old system for an extra month is trivial compared to the cost of discovering, after decommissioning, that critical data was not transferred.
Step 1: Inventory Your Active Matters and Work Product
Before you export a single file, you need a complete inventory of what needs to be migrated. This is not simply a list of matter names — it is a detailed accounting of every piece of data and work product associated with each matter. The inventory serves as your migration checklist and, ultimately, your validation reference. Without it, you have no way to confirm that the migration is complete.
For each active matter, document the following: total document counts broken down by custodian and data source; Bates ranges for all productions that have been made; tagging and coding decisions, including relevance designations, issue codes, and any custom tags your review team has applied; and search term histories, including the terms themselves, the date each search was run, and the hit counts. These search histories may be needed to demonstrate the scope of your review to opposing counsel or the court.
Privilege designations deserve particular attention. Identify every document that has been designated as privileged, the specific privilege claimed, and the basis for the designation. If privilege logs have been generated and served, those logs must be preserved exactly as they were produced. Production histories — records of what was produced, to whom, on what date, and in what format — are equally critical. These records may be needed to respond to challenges about the completeness or timing of your productions.
Finally, document any pending discovery obligations: outstanding production deadlines, agreed-upon search terms that have not yet been run, depositions where specific documents are expected to be used, and any court orders governing document preservation or production. These obligations do not pause during a migration, and your new platform must be ready to support them immediately upon go-live.
Step 2: Export in Standard Load File Formats
The export format you choose determines how much of your work product survives the migration. Proprietary formats lock you into specific platforms and create dependencies that make future migrations even harder. Standard load file formats — Concordance DAT, Relativity load files, EDRM XML, and Ringtail — are supported by virtually every eDiscovery platform and provide the best chance of a lossless migration.
Concordance DAT is the most widely supported format and should be your default choice unless you have specific reasons to use another. It uses a delimited text file to carry metadata fields, with image and native file pointers that reference the actual document files. Relativity load files offer additional capabilities if you are migrating between Relativity workspaces, including support for coding and tagging data. EDRM XML provides a structured, standards-based format that is particularly well-suited for complex productions with extensive metadata.
When you run your exports, do not rely on the export completion message alone. Export processes can fail silently, producing partial exports that appear complete. After every export, count the documents in the export package and compare that count to your inventory. The numbers must match exactly. If they do not, investigate the discrepancy before proceeding — a "close enough" approach to document counts is never acceptable in litigation.
Most critically, do not decommission your old platform until the migration is fully validated. Maintain read access to the source system throughout the validation process. If your vendor is forcing a decommission date, negotiate for the latest possible date and begin your migration well in advance. The single biggest cause of migration failures is time pressure that forces teams to skip validation steps.
Step 3: Validate the Migration
Validation is the most important step in any platform migration, and it is the step most often shortchanged due to time pressure. A thorough validation protocol catches errors that would otherwise surface at the worst possible time — during a production, at a deposition, or in response to a motion to compel. Budget at least as much time for validation as you budgeted for the export and import themselves.
Start with a document count match. The total document count in the new platform should exactly match the count from your inventory. Any discrepancy, even a difference of one document, must be investigated and explained. Missing documents may indicate export failures, import errors, or deduplication settings that removed documents that should have been preserved. Excess documents may indicate duplicate imports or test data that was not cleaned up.
Spot-check coding decisions across a representative sample of documents. Pull a random sample of at least 100 documents from each matter and verify that their relevance designations, issue codes, privilege markings, and custom tags match the coding in the source system. Pay particular attention to privilege designations — a document that was marked privileged in the old system but is not marked privileged in the new system could be inadvertently produced.
Verify that Bates numbering has been preserved exactly as it existed in the source system. If you have previously produced documents with Bates stamps, those stamps must match exactly in the new system. Any change in Bates numbering will create confusion in the record and may require you to notify opposing counsel. Re-run key searches from your search history and compare hit counts between the old and new systems. Significant differences in hit counts may indicate missing documents, different search syntax, or indexing issues in the new platform. Finally, verify that family groups — parent-child relationships between emails and attachments, or between containers and their contents — have been preserved intact.
Step 4: Maintain Chain of Custody Documentation
A platform migration is a handling event in the chain of custody for your electronically stored information. If you are ever called upon to demonstrate the integrity of your ESI — in response to a spoliation motion, a challenge to the completeness of your productions, or a question about metadata authenticity — you will need to show that the migration did not alter or lose any data. Comprehensive documentation of the migration process is your defense.
Document the entire migration process in a memorandum that identifies who performed each step, when each step was completed, and what tools and methods were used. Include the names and versions of export and import utilities, the specific export formats used, and any configuration settings that were applied. Record the source platform name and version, the destination platform name and version, and the dates of the migration for each matter.
Retain a complete copy of the export files as a backup, independent of both the source and destination platforms. These export files serve as a snapshot of your data at the point of migration and can be used to verify the integrity of the migration if questions arise later. Store these backup files in a secure, documented location with appropriate access controls and retention policies.
If your matters are subject to litigation holds or preservation obligations, update your hold documentation to reflect the migration. The hold notice should still be in effect, and custodians should be informed that their data has been migrated to a new system. If you are a party to pending litigation, consider whether you have an obligation to notify opposing counsel of the platform change, particularly if the migration could affect the format or completeness of future productions.
How DecoverAI Simplifies Platform Migration
DecoverAI was built with platform portability as a core design principle. The platform ingests all standard load file formats — Concordance DAT, Relativity, EDRM XML, Ringtail, and others — so your data can be imported regardless of where it is coming from. There is no proprietary format requirement and no lock-in: your data can be exported from DecoverAI in the same standard formats at any time.
During import, DecoverAI preserves all existing work product: Bates numbering, coding decisions, privilege designations, metadata fields, and family group relationships are all maintained exactly as they existed in the source system. The platform runs automated validation during import, flagging any discrepancies between the load file metadata and the actual document files so they can be resolved before the migration is considered complete.
DecoverAI's pricing model eliminates one of the most common reasons for forced migrations: unexpected cost escalation. At $60 per gigabyte, pricing is transparent and predictable, with no per-user fees, no per-search charges, and no hidden costs for features that should be standard. You will never be forced into a migration because your vendor decided to double your hosting fees.
For teams evaluating a migration, DecoverAI offers a free trial that lets you import a sample of your data and validate the migration process before committing. You can run your own validation protocol — count documents, spot-check coding, re-run searches, verify Bates numbering — and confirm that everything transfers correctly before making the switch. There is no commitment and no pressure, because we believe the platform should prove itself before you trust it with your active matters.