Salesforce Einstein lead scoring shows inaccurate predictions after a CRM data migration mainly because the model was trained on your old data patterns and the migration broke field mappings, wiped historical timestamps, or introduced duplicate and null values. Einstein scores leads using statistical patterns from past Won/Lost records, so when those records change shape, the predictions drift until you retrain the model.

Why migration breaks Einstein predictions

Einstein Lead Scoring isn't reading your data live in some smart way. It builds a machine learning model from a historical snapshot of converted versus unconverted leads, then applies that model to new records. A migration changes the underlying data the model depends on, and that mismatch is what tanks accuracy.

Most teams get this wrong by assuming the score updates itself instantly. It doesn't. Einstein refreshes models on a schedule (typically every 10 days), so you're often looking at predictions built on data that no longer exists in the form the model expects.

Common root causes

  • Lost conversion history. Einstein needs at least 1,000 leads and 120 conversions in the trailing period. If your migration didn't carry over ConvertedDate, IsConverted, or Status correctly, the model retrains on garbage.
  • Broken field mappings. Custom fields that fed predictive signals (industry, employee count, lead source) may have remapped to the wrong API names or data types.
  • Null and default value flooding. Migrations often dump blank or placeholder values into required fields, which Einstein reads as legitimate signal.
  • Duplicate records. Re-imported leads inflate certain segments and skew the probability distribution.
  • Timestamp corruption. CreatedDate resetting to the migration date destroys Einstein's velocity and recency features.
Diagram showing Salesforce Einstein lead scoring pipeline with data flowing from CRM records through field mapping into a machine learning model, with a red break point at the migration stage

How to diagnose the problem

Work from the data backward to the model. Don't start by retraining blindly.

  1. Check the model status page. In Setup, open Einstein Lead Scoring and look at the model health and last refresh date. A warning here usually points straight at insufficient or malformed data.
  2. Audit conversion counts. Run a report on leads created in the last 90 days segmented by IsConverted. If conversions dropped to near zero post-migration, the timestamps reset.
  3. Validate field mappings. Compare the source schema against the destination. Pay attention to picklist values that silently became free text.
  4. Scan for nulls and duplicates. Use a duplicate matching rule and a report filtering on blank key fields. High null rates on scoring-relevant fields are a red flag.
  5. Review the predictor insights. Einstein shows which fields drive scores. If a previously strong predictor vanished or a junk field jumped to the top, you've found your mapping issue.

Generate Proposals with AI in seconds.

Try now
Proposal album preview

Fixing the inaccurate scores

Repair the data first

Einstein is a garbage-in, garbage-out system. Clean before you retrain.

  • Restore correct CreatedDate and ConvertedDate values where the migration tool overwrote them. Many tools let you preserve audit fields if you enable that setting before import.
  • Deduplicate leads and contacts so the conversion ratio reflects reality.
  • Backfill nulls in fields Einstein uses as predictors, or exclude those fields if backfill isn't possible.
  • Normalize picklist values so Tech, Technology, and IT don't fragment a single segment.

Force a model rebuild

Once data is clean, you can't always wait the full refresh cycle. Toggle Einstein Lead Scoring off and back on in Setup to trigger a fresh model build, or use the manual refresh option in newer Sales Cloud releases. Confirm the new model trained on the corrected dataset by checking the refresh timestamp afterward.

Re-baseline expectations

If your business changed during the migration (new segments, new products), the old model may be obsolete regardless of data quality. A clean rebuild establishes a new baseline. Give reps a few weeks before judging accuracy, and pair the scores with a qualification framework so they aren't relying on the number alone. Teams comparing MEDDIC, BANT, and SPIN methodologies often layer human qualification on top of Einstein scores for complex deals.

Preventing this in future migrations

The cleanest fix is avoiding the breakage. Before any CRM data migration:

  • Document every field Einstein uses as a predictor and verify each one in the mapping spec.
  • Preserve system audit fields (CreatedDate, LastModifiedDate) using your migration tool's audit-field setting.
  • Migrate in a sandbox first and let Einstein train there to spot prediction drift early.
  • Run pre- and post-migration reports on conversion counts and null rates as a sanity check.

This discipline matters more if you're evaluating platforms during the move. Teams weighing HubSpot versus Salesforce for B2B should test scoring continuity as part of the decision, since rebuilding predictive models is a hidden migration cost.

Checklist graphic for validating Salesforce data migration with items like preserve audit fields, deduplicate records, validate field mappings, and confirm conversion counts

Key takeaways

  • Einstein scores come from a model trained on historical data, not live evaluation, so migrations that alter that history break predictions.
  • The usual culprits are reset timestamps, broken field mappings, null flooding, and duplicate records.
  • Diagnose by checking model status, conversion counts, field mappings, and predictor insights before retraining.
  • Clean the data, force a model rebuild, then re-baseline accuracy expectations over a few weeks.
  • Prevent recurrence by preserving audit fields and testing Einstein in a sandbox before the production cutover.