How to Refresh 100,000+ B2B Records Without Rebuilding Your Database

You do not need to start over. With data decaying ~2.1% a month [1], a refresh strategy identifies which records need updating and re-collects current data in place — keyed on the stable profile URL — so you keep your IDs, history, and CRM links while the content becomes current again.

Facing a large, partially-stale database, the instinctive reaction is to rebuild: throw it out and re-source everything from scratch. At a few thousand records that is merely wasteful. At 100,000-plus it is a quarter-long project that discards years of institutional data to solve a problem that was never structural in the first place.

The problem is not that your records exist. It is that their content has drifted out of sync with reality — and content drift is fixable in place. A refresh updates the records you already have, keyed to a stable identifier, so your IDs, CRM associations, enrichment, and campaign history all survive while the fields that went stale are brought current. This is a tactical walkthrough of how to do that at six-figure scale, and an honest account of what the mechanism can and cannot do.

1. Refreshing is not rebuilding

Start with the distinction, because it drives every decision downstream. A rebuild re-sources the whole dataset as new records and then forces you to reconcile them against the old ones — matching, merging, and cleaning up the inevitable duplicates. A refresh re-collects current data for records you already own and writes the changed fields back onto those same records. Same rows, same primary keys, updated content.

The economic difference is large. A rebuild pays twice: once to re-collect everything, and again to reconcile everything. A refresh pays once, and only for the records that actually warrant it. At 100,000 records the reconciliation tax alone is reason enough to refresh rather than rebuild — reconciling two six-figure datasets by hand is its own multi-week project, and doing it badly creates exactly the duplication problem you were trying to fix.

2. The refresh pipeline, step by step

A refresh at scale is a sequence, not a single action. Each step narrows the work so you never spend effort on records that will not repay it.

3. Step one — prioritize; do not boil the ocean

Refreshing all 100,000 records blindly wastes effort on records nobody will ever use. Prioritize by two signals. Staleness: time since each record was last verified against source — not creation date, which tells you nothing about current accuracy. Value: segment importance, account tier, or active-campaign membership. Records that are both old and high-value get refreshed first, because that is where fresh data changes outcomes.

This matters more than it looks, because decay is value-weighted. The senior, in-demand contacts worth the most are also the ones most likely to have moved, so a priority-first refresh is not just efficient — it targets the exact records that decayed fastest. Low-value records nobody works can wait for a later cycle or drop out of scope entirely. The job-change math underneath makes the urgency concrete: with roughly a quarter of workers changing jobs in a year [2], a high-value segment left a year untouched is substantially wrong at the top.

4. Step two — re-collect against a stable key

The mechanics of the update are where "refresh" is won or lost. Re-collect current data keyed to something stable — the LinkedIn profile URL — so the new data maps cleanly onto the existing record instead of creating a second one. The profile URL is the right key precisely because it survives the changes you are trying to track: when a person switches companies and titles, their profile URL stays the same, so the refreshed title and company overwrite the right record rather than appearing as a brand-new contact.

This is the honest center of the whole piece, and it is worth being precise about. There is no mechanism that reaches into an arbitrary database and magically makes it current. What actually works is narrower and more reliable: for records that carry a resolvable profile URL, you re-collect what that public profile shows today and update the record in place. Records without a usable key — no profile URL, a dead link, or a URL that now resolves to a different person — cannot be refreshed this way and must be flagged for manual handling rather than silently guessed at. Collection keeps you in sync with what the source currently displays; it does not invent a title the person never updated, and it does not produce personal emails or phone numbers.

5. Step three — compare old versus current, update in place

With current data collected, diff it field by field against the stored record. Most records will show changes in the fast-decaying fields — title and company first, since those are the ones that move most [1][3] — while slow fields like location often hold. The diff is valuable in itself: it tells you your real decay rate on this dataset, which is usually higher than anyone guessed and worth reporting back as evidence for a standing refresh budget.

Then write the changed fields back onto the existing record and reset its "last verified" date. You preserve everything downstream — CRM associations, campaign history, notes, internal IDs — while the content becomes current. Because the update is keyed and in place, nothing is rebuilt and nothing is duplicated; the same record simply carries fresh content and a fresh verification timestamp.

6. Step four — flag exceptions and QA

Automation handles the clean majority; it must not handle the ambiguous minority silently. Route exceptions to a human: a profile URL that no longer resolves, a URL that now points to a different person, a record whose collected data conflicts with itself, or a contact who appears to have left the workforce entirely. These are judgment calls, and a pipeline that overwrites them automatically will quietly corrupt records it was supposed to protect.

Then QA the run before it touches the live system. Spot-check a random sample of updated records against the live source and confirm the updates are correct and the exceptions were caught. This is cheap insurance: a sampling check on a few hundred records out of 100,000 is enough to catch a systematic error before it propagates into every campaign built on the refreshed file.

7. Why this beats a rebuild

A rebuild discards your history, enrichment, and CRM wiring to solve a problem that was only ever about content freshness. A refresh solves the actual problem — stale content — while keeping the structure intact. It is faster, cheaper, and far less disruptive to the teams downstream who depend on stable record IDs and preserved campaign history.

There is also a scale argument. Because the collection work is mechanical and runs as an automated pipeline rather than a human copying fields, 100,000 records is a queue to be worked through, not a hiring decision. You add throughput by adding workers to the collection layer, not by onboarding and QA-ing another cohort of researchers. That is the structural reason refresh scales where manual re-verification does not: studies of sales-development teams find reps already lose around 40% of their time — roughly 16 hours a week — to prospect research before any selling happens [4], and doing six-figure re-verification by hand simply multiplies that tax.

8. Make it recurring

The last step is the one that keeps you from being back here in a year: turn the one-time refresh into recurring cycles. Decay does not stop after a cleanup — at ~2.1% a month [1] the records you just refreshed begin drifting again immediately — so the refresh has to repeat on a cadence tuned to value and volatility. High-value, high-movement segments re-collected more often; stable segments on a longer interval.

Done that way, the 100,000-record refresh stops being a heroic project and becomes a standing process: a bounded, prioritized, keyed update that keeps the database in sync with reality without ever rebuilding it. The asset you spent years accumulating stays intact; only its accuracy gets renewed.

Sources

1. Landbase — B2B contact-data decay rates (~2.1%/month; job title fastest-decaying).
2. Second Talent — US median employee tenure 3.9 years; ~24% change jobs per year (2026).
3. Cleanlist — State of B2B Data 2026 (job-title churn benchmarks).
4. Leadspace — SDRs spend ~40% of time (~16 hrs/week) researching accounts.