Most bad data can be recovered or corrected, but the recovery cost and success rate depend on what kind of bad data it is — structural problems are highly recoverable, while factually inaccurate or permanently deleted data may be unrecoverable without an external source.
The word "bad" covers very different problems. Formatting inconsistencies, duplicates, and missing fields that can be filled from another source are all highly recoverable. Data that was entered incorrectly, never captured, or deleted without a backup is a harder problem — and sometimes, the honest answer is that the data is gone.
The Recovery Spectrum
Easily recoverable:
- Formatting inconsistencies (phone numbers in different formats, dates formatted differently, inconsistent capitalization)
- Duplicates (can be merged or removed, with the right merge logic)
- Missing values that exist in another system (can be filled by cross-referencing or re-importing)
- Invalid values that follow a clear correction pattern (e.g., all emails missing the domain, all dates missing the year)
Sohovi automatically finds every duplicate in your dataset — including near-matches — and shows you exactly which rows are affected.
Recoverable with effort:
- Missing values that require individual research or enrichment service lookup
- Outdated values that need to be refreshed from an authoritative source
- Inconsistent categorical values that require a mapping table to standardize
Difficult or impossible to recover:
- Factually wrong values where the correct value is unknown and no source exists
- Data that was never captured (you cannot recover data that was never collected)
- Deleted records without a backup or audit log
- Data overwritten in a destructive import without a pre-import snapshot
How to Approach Recovery by Problem Type
Duplicates — Use a deduplication process to identify candidate pairs, define merge rules (which record to keep, how to combine field values), and execute the merge. Most CRM platforms have built-in deduplication. Custom deduplication can be done in spreadsheets or SQL.
Format problems — Apply transformation rules consistently to the affected field. Standardizing phone numbers to a single format, for example, can be done in a few lines of code or a spreadsheet formula applied to the entire column.
Missing values — Prioritize records where the missing field is critical for an upcoming use case. Use data enrichment services for contact data. Cross-reference against other internal systems that may have the missing value.
Wrong values — These are the hardest. If you have an authoritative external source to verify against, use it. If you do not, the choice is between accepting the bad value and flagging it as unverified, or manually researching and correcting it record by record.
Sohovi scores your dataset against your own accuracy standards and highlights the columns and rows where values fall outside expected ranges.
Frequently Asked Questions
Q: If data was deleted, can it be recovered? Deleted data can sometimes be recovered from database backups, audit logs, or transaction logs, depending on your system and backup policy. If no backup exists and the deletion was not logged, the data is permanently gone. This is a strong argument for maintaining regular backups and pre-operation snapshots.
Q: Can machine learning help recover bad data? Machine learning can help with certain recovery tasks: deduplication (identifying likely duplicates based on fuzzy matching), value imputation (predicting missing values based on patterns in other fields), and anomaly detection (flagging records that are likely wrong). It is a powerful tool for structural recovery but cannot create accurate factual data out of nothing.
Q: How do you recover from a bad data import? If you took a pre-import snapshot, roll back and re-import with corrected data. If no snapshot exists, identify the records that arrived in the bad import (usually via created date or import batch ID), assess the damage, and remediate record by record or in bulk using the import file as a reference.
Q: Is it better to delete bad records or try to fix them? Delete when the record is unrecoverable and unusable for any purpose. Fix when the record has partial good data worth preserving. Flag and quarantine when you are unsure — removing records permanently is a one-way action. When in doubt, archive rather than delete.
Q: Can you recover data quality after a major system migration? Yes, but it is easier to prevent migration data quality problems than to fix them after the fact. A pre-migration audit identifies what needs to be cleaned before migration. A post-migration validation confirms the migration was clean. If quality problems were introduced during migration, use the pre-migration snapshot to identify and correct them.
Q: What is the success rate of data recovery projects? It varies widely by problem type. Format and structural problems: 80-100% recovery rate. Missing values fillable from other sources: 50-80%, depending on source availability and coverage. Factually wrong values: highly variable, often below 60% for unverifiable fields without an authoritative source.
Q: How do you know if a data recovery effort is worth the investment? Calculate the business value of the recovered records. If recovering the email field for 2,000 incomplete records would enable an outreach campaign to 2,000 additional prospects, estimate the revenue value of that campaign. If it exceeds the recovery cost, it is worth pursuing.
Q: What should you do with data you cannot recover? Flag it as low-confidence or incomplete. In analytical workflows, exclude it from analyses that require complete data. Use it only where partial data is acceptable. Do not delete it unless you are certain it has no future value — archiving is usually a better choice.
Q: How does a backup policy affect data recoverability? A strong backup policy is the most powerful recovery tool. Daily incremental backups and weekly full backups, combined with a retention policy that keeps backups for 30-90 days, means that even significant data damage can be undone by restoring a recent backup. Without backups, recovery options are severely limited.
Q: What is the first step when you discover a data quality problem? Stop the bleeding first. Identify whether the problem is still actively being introduced (a broken import, a form bug, a sync error) and fix the source before beginning remediation. Cleaning data while the source of the problem is still running is a waste of effort.
Most bad data problems are more recoverable than they appear at first. The key is matching the recovery approach to the type of problem and investing remediation effort where the business value of recovery is highest.
Start with a clear picture of what you are working with. Sohovi profiles your dataset in under a minute, showing you exactly which records and fields are affected — so you can make a recovery plan based on facts, not guesswork.
