Migrating a Lead Spreadsheet Into a Live CRM

Moving a defined, external dataset, a spreadsheet of leads bought from a data provider, an export from a CRM you are leaving, a list a founder has been keeping in a Google Sheet, into your live Salesforce or HubSpot backend. It is explicitly one of the six things a Mindlyft request can be: post-call CRM updates, follow-up drafts, cross-tool coordination, sales-to-CS handoffs, CRM hygiene, and data migration into a live backend. The common shape is a large lead spreadsheet that needs to become real, working CRM records rather than a file nobody opens again.

Mapping first, then a write. Mindlyft reads the spreadsheet's columns and maps each one to the correct object and field in your CRM, a "Company" column to the Account name, a "Stage" column to the actual pipeline stage your team uses rather than whatever label the source system used. Free-text or inconsistent values, a title written five different ways across five hundred rows, get normalized against your existing field values rather than imported as-is, because a migration that faithfully reproduces messy source data just moves the mess into a system you rely on more.

The same deduplication check used for ongoing CRM hygiene runs on every incoming row before it writes. Each record in the spreadsheet is checked against what already exists in Salesforce or HubSpot, by email, domain, and name, and a likely match is flagged rather than written as a new record. A genuine duplicate does not get merged silently mid-migration, it is surfaced the same way an ongoing hygiene merge is: drafted for a person to confirm. That is the same policy CRM hygiene automation applies day to day, applied once at the start instead of continuously after.

Yes, and for the same reason a deal-stage change does: it is not a reversible action with a low individual blast radius, it is a single write with a large one. ASTRA gates by consequence, not by category, and a bulk write into a system of record other decisions depend on is exactly the kind of action that waits for a person. In practice that means the field mapping and a representative sample of the mapped records are drafted and shown before the full batch runs, so a wrong mapping, a "Close Date" column landing in the wrong field, gets caught on ten rows instead of ten thousand. Once the mapping is approved, the full batch executes, and every record it creates is logged individually in the audit trail, with enough context to roll back a bad row without redoing the whole migration.

Yes. A migration is a fixed dataset moved once: the spreadsheet has an end, and once its records are in the CRM and deduplicated against what already existed, the job is done. CRM hygiene automation is the opposite shape, a continuous job with no defined endpoint, running deduplication, field enforcement, and activity capture on the records already in the system as they change. The two use the same underlying detection, the same dedup logic checks a migrating record against live data and checks a live record against every other live record, but a migration is scoped and finite where hygiene is ongoing.

They do not get forced in. A row missing a required field, or one where the source value cannot be confidently mapped to anything in your CRM's schema, is set aside as an exception rather than written with a guessed or blank value. Exceptions are reported back as their own reviewable list, what did not migrate and why, rather than silently dropped, so nothing from the source spreadsheet disappears without a record of why it did not land. A person can then correct the source data and re-run just the exceptions, instead of the whole migration.

A migration is sized the same way every request is: as work one GTM engineer can ship inside your stack in roughly a week, which is what one active slot in the subscription queue covers. A modest spreadsheet, a few hundred to a few thousand rows with a fairly clean structure, fits comfortably in that window. A very large or very messy dataset, many source systems, inconsistent formatting, thousands of likely duplicates to review, gets broken into shippable pieces and queued in order rather than stalled as one giant, unreviewable batch. Either way, the field mapping is scoped and agreed before the bulk write runs, not discovered partway through.

The same place any other drafted action gets reviewed: Slack or the inbox, wherever the accountable person already works, rather than a separate migration console you have to learn. The mapping is shown as a diff-like summary, this spreadsheet column becomes this CRM field, with the sample batch attached so the reviewer can see actual rows rather than an abstract schema. That keeps a migration consistent with everything else ASTRA drafts: one review surface, whether the action in front of you is a stage change from a call or a field mapping for a thousand incoming leads.

A migration is one request in the queue like any other, so it takes its turn behind whatever is already active rather than running in parallel with it. In practice migrations often sit at the front of a new customer's queue for a reason: onboarding automation and renewal-risk flagging both work from the records already in the CRM, so a clean migration first means the requests built after it are working from real data instead of a partially populated backend. A team switching CRMs, or consolidating a spreadsheet a founder has been keeping by hand, typically queues the migration before the workflows that depend on the data it brings in.