Lead Generation Software Migration Checklist: Move Without Losing Attribution or Consent

The direct answer: migrate the operating record, not the contact list

A safe lead generation software migration preserves identity keys, field definitions, provenance, permission state, suppression, acquisition source, answers, scores, outcomes, owners, workflow state, and historical timestamps. Moving names and email addresses is not a migration if the receiving team can no longer explain why a lead exists, what the person declared, whether follow-up is allowed, or what should happen next.

Run a reversible pilot before cutover. Keep the old system read-only until source and destination counts reconcile, critical workflows complete a full operating cycle, and every material difference has a reason code. Do not activate outbound automation merely because imported records meet a fit rule.

Write a migration contract before exporting anything

Define the business outcome, in-scope systems, source cutoff, destination objects, record owners, migration unit, acceptance tests, rollback trigger, and retention plan. The contract should name which system remains authoritative for identity, permission, qualification, attribution, ownership, and reporting at every stage.

Classify every source object as migrate, reconstruct, archive, or retire. A record with no destination owner or downstream decision should not move by default. An archived item still needs a stable key, readable format, access owner, retention rule, and deletion path.

Audit export coverage before choosing the transfer method

Do not assume a vendor export contains the complete operating model. Test whether the export includes stable response IDs, timestamps, hidden fields, variables, scores, outcomes, tags, file references, partial submissions, deleted-field history, permission evidence, and workflow state. Record what is absent and decide whether it must be reconstructed, separately exported, archived, or explicitly retired.

Typeform currently documents response exports in CSV or XLSX. It notes that filtered or selected exports contain only that subset, multiple-selection answers can appear as separate columns, file uploads use a separate download, and response data can include hidden fields, variables, scores, start and submit dates, and response type. Its documentation also warns that deleting questions can remove associated results and recommends exporting before deleting an old form. These are useful examples of why export behavior needs a field-level test, not a checkbox.

Build a versioned field migration register

For every field, record the source object, source key, business definition, data type, allowed values, source of truth, destination object, destination key, transformation, null behavior, unique-key role, permission purpose, retention rule, and validation owner. Freeze schema changes during cutover and store the exact mapping version with every import or API batch.

Keep raw source values when a transformation is lossy. Treat missing, empty, false, zero, unknown, and not applicable as distinct states unless the destination contract intentionally combines them. A migration should not convert unknown to no or a missing permission value to permission denied merely to satisfy a required field.

Protect identity with explicit match rules and a crosswalk

Preserve every legacy record ID and create an immutable crosswalk to the destination ID. Separate person, account, relationship, channel, and participation identities. Email can be useful for a deterministic contact match, but it is mutable, can be shared, and does not identify every participation or account relationship.

HubSpot currently documents email, company domain, Record ID, and supported custom unique-value properties as import identifiers. It also documents automatic contact deduplication by email and company deduplication by domain, while noting that company records created through APIs are not deduplicated by domain. These rules are product-specific test inputs. They do not establish a universal identity model.

• Existing contact matched by the intended unique key
• New contact with no destination record
• Secondary email and changed primary email
• Shared inbox and shared company domain
• One person with multiple employers or accounts
• One person with multiple submissions or buying motions
• Duplicate source records with conflicting values
• Missing key, invalid key, and reused legacy ID

Move permission and suppression before eligibility

Migrate global suppression, channel permission, purpose, state, capture source, disclosure or text version, timestamp, legal-basis record where applicable, and downstream restrictions before activating sequences or campaign audiences. Preserve evidence and restrictions separately from fit or engagement scores.

HubSpot currently asks importers to confirm that contacts expect to hear from them and that the file is not a purchased list. With data privacy settings enabled, its import flow can also set a legal basis for processing. Those controls do not replace the buyer's own evidence, jurisdictional analysis, or purpose-specific rules. If the destination cannot represent a required restriction, block launch.

Preserve attribution and qualification as explainable events

Retain original source, medium, campaign, content, landing page, click or interaction ID, first-touch time, latest-touch time, raw answers, formula inputs, calculated values, score components, outcome, segment, and rule version. Do not overwrite original acquisition fields with the import source or migration date.

Keep a participation or submission record when one contact can complete more than one experience. A contact-level latest score is useful for routing, but it should not erase the answer set, outcome, and logic version that produced an earlier decision. If the destination cannot store the full event history, archive it in a machine-readable form with stable contact and participation keys.

Rebuild workflows in a safe state

Inventory form logic, routing, scoring, webhooks, native integrations, sequences, suppression checks, alerts, dashboards, audiences, and offline conversion uploads. Record the trigger, entry rule, branch logic, wait state, side effect, exit condition, owner, and current population for each workflow.

Create imported records in a non-enrolling or quarantined state where possible. Test workflows with synthetic records, then a small representative pilot. Activate triggers only after permission parity, field completeness, ownership, and duplicate controls pass. Pause old triggers before enabling the new ones so the same event cannot produce two business actions.

• No imported contact enters a sequence by default
• Suppression overrides fit, score, and campaign eligibility
• Wait states and scheduled actions have an explicit migration rule
• Old and new integrations cannot both process the same live event
• Alerts name an owner and include a recoverable record reference
• Dashboards use the same stage and time definitions before comparison
• Offline conversion events retain their original event time and source key

Run a four-stage reversible cutover

Move from synthetic proof to a representative pilot, then a controlled production window, and only then a complete cutover. Each stage should have an entry criterion, expected counts, named approver, rollback trigger, maximum acceptable pause, and evidence pack. Do not make the first full-volume import the first realistic test.

Use a frozen acceptance set, not a happy-path sample

Build the sample before seeing destination results, and retain expected values for every critical field and side effect. Include enough records to cover the actual object relationships, permission states, scoring versions, and routing branches. The goal is not a statistically representative benchmark. It is deterministic coverage of material failure modes.

• New person, existing person, and intentionally duplicated person
• Secondary email, shared inbox, changed employer, and missing domain
• Multiple submissions by one person and one submission linked to multiple objects
• Blank, explicit null, false, zero, invalid enum, and over-length text
• Historical score, changed score, changed outcome, and retired rule version
• Original first touch plus a newer latest touch
• Global suppression, channel opt-out, purpose permission, and unknown permission
• Active owner, inactive owner, unassigned record, and routing exception
• Workflow wait state, completed workflow, and previously failed action
• File attachment or external asset reference
• Rejected row, partial success, retry, and safe replay
• Rollback after the destination has created side effects

Reconcile counts, semantics, and downstream outcomes separately

Every difference needs a reason code. Compare source records, extracted rows, transformed rows, attempted rows, accepted rows, rejected rows, created records, updated records, duplicates, associations, restrictions, workflow enrollments, and downstream events for the same closed window. Report the count beside every rate.

A zero count gap does not prove semantic correctness. Sample records field by field, compare distribution changes for critical enums and scores, and run the business workflows. If the destination contains the right number of leads but associates them with the wrong accounts or resets first-touch attribution, the migration failed.

Define rollback before enabling irreversible actions

Rollback is not merely restoring a database backup. It must state how new records created after the cutoff are captured, how destination-created IDs map back, how duplicate outreach is prevented, how owner changes and completed tasks are handled, and how records created by downstream systems are reconciled.

Keep the old system read-only until the new system has completed at least one full operating cycle and exception owners have accepted the backlog. Retain the exact exports, checksums, mapping version, transformation code, import logs, error files, crosswalk, decision record, and rollback rehearsal result.

Where involve.me can reduce migration boundaries

involve.me is this guide's top recommendation for businesses converting existing website or campaign traffic through interactive data collection and qualification, then using the resulting context for automated follow-up. Its documented custom contact properties can retain answers, scores, outcomes, calculator results, and source data on the contact, while the activity timeline records property changes. Its built-in email automation can branch from answers, scores, outcomes, contact data, tags, segments, opens, and clicks.

That native connection can reduce the number of mappings between capture, qualification, CRM context, and follow-up. It does not eliminate migration work. Teams still need to map legacy identities and fields, preserve permission evidence, test overwrites, control imports that could trigger workflows, and validate any external CRM integration. involve.me is not an outbound contact database, social-selling system, anonymous visitor-identification product, or full sales CRM.

Use a 100-point migration-readiness scorecard

Rate each dimension from 0 to 5. Weighted points equal the rating divided by 5, multiplied by the dimension weight. Set hard gates for permission continuity, explainable identity, rollback, and visibility of rejected records. A high total cannot compensate for a migration that causes forbidden outreach or loses original attribution.

Sources and evidence boundary

HubSpot import, unique-identifier, association, permission-setting, and deduplication documentation was rechecked against official sources on October 4, 2026. Typeform response export and response-data documentation was rechecked on the same date. involve.me custom contact property, integration, and email automation documentation was also rechecked. Product behavior, plan access, limits, field support, export formats, and terminology can change.

The migration contract, object inventory, field register, crosswalk, four-stage cutover, acceptance set, reconciliation formulas, rollback gates, and scorecard are Pipeline Sourcebook editorial frameworks. They are not vendor standards, legal advice, hands-on migration results, a complete compliance program, or a guarantee that any named product passes a specific production migration.