---
title: "Lead Generation Software Migration Checklist: Move Without Losing Attribution or Consent"
description: "A migration contract, field register, reversible cutover, reconciliation model, rollback plan, and scorecard for preserving lead identity, context, permission, and workflow state."
canonical: "https://best-lead-generation-software.com/blog/lead-generation-software-migration-checklist"
last-updated: "2026-10-04"
---

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

A migration contract, field register, reversible cutover, reconciliation model, rollback plan, and scorecard for preserving lead identity, context, permission, and workflow state.

Published: 2026-10-04
Updated: 2026-10-04

## 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.

- [Test every integration boundary](https://best-lead-generation-software.com/blog/lead-generation-software-integration-testing)
- [Protect person, account, and participation identity](https://best-lead-generation-software.com/blog/lead-deduplication-identity-resolution)

## 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.

| Layer | Examples | Migration decision |
| --- | --- | --- |
| Identity | Contacts, people, companies, accounts | Preserve keys and crosswalks |
| Participation | Submissions, sessions, answers, calculations | Retain each material interaction |
| Qualification | Score components, total, outcome, segment, rule version | Move the reason, not only the label |
| Permission | Purpose, channel, state, text version, timestamp, suppression | Migrate before activation |
| Acquisition | Source, medium, campaign, content, landing page, click ID | Keep original and latest touch separate |
| Operations | Owner, lifecycle, task, sequence, routing and exception state | Recreate only with an acceptance test |
| Evidence | Event history, exports, rejected rows, transformation log | Archive in a machine-readable form |

## 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.

| Transfer pattern | Best fit | Proof required | Primary risk |
| --- | --- | --- | --- |
| Native migration tool | Supported source and destination pair | Object coverage, logs, retry and rollback | Opaque transformations |
| CSV or spreadsheet import | Controlled records and fields | Frozen file, map, validation report | Missing relationships or history |
| API transfer | High volume or complex objects | Cursor, idempotency, error ledger | Engineering and rate-limit failure |
| Temporary sync | Phased cutover with ongoing writes | Direction, authority and conflict rules | Loops and last-write loss |
| Archive only | Required history with no active use | Stable keys, readable format, retention owner | Unusable compliance theater |

- [Typeform response export documentation](https://help.typeform.com/hc/en-us/articles/360029253572-Export-your-responses)
- [Typeform response data documentation](https://help.typeform.com/hc/en-us/articles/360029253732-Working-with-your-responses)

## 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.

| Register field | Question it answers | Failure prevented |
| --- | --- | --- |
| Source and destination keys | Where does the value live? | Silent misrouting |
| Definition and type | What exactly does it mean? | Semantic drift |
| Transformation and null rule | How can the value change? | False certainty |
| Authority and overwrite rule | Which value wins? | Stale replacement |
| Provenance and event time | Who supplied it, and when? | Unexplainable context |
| Permission purpose and retention | May it be used and kept? | Unauthorized use |
| Validation owner and test | Who accepts the result? | Orphaned failures |

## 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

- [HubSpot import tool concepts and identifiers](https://knowledge.hubspot.com/import-and-export/understand-the-import-tool)
- [HubSpot record deduplication documentation](https://knowledge.hubspot.com/records/deduplication-of-records)

## 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.

| State | Migration rule | Automation result |
| --- | --- | --- |
| Globally suppressed | Preserve as a hard restriction | No promotional enrollment |
| Channel opt-out | Keep channel and timestamp | Block that channel |
| Purpose-specific permission | Preserve purpose and evidence | Use only for that purpose |
| Unknown or missing | Do not infer permission | Hold or route for policy review |
| Permission withdrawn during cutover | Propagate with priority | Stop queued and future actions |

- [Use the consent, provenance, and retention checklist](https://best-lead-generation-software.com/blog/lead-generation-data-governance-checklist)

## 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.

| Context | Minimum retained fields | Why it matters |
| --- | --- | --- |
| Acquisition | Original and latest source, campaign, landing page, event time | Attribution does not reset at import |
| Declared data | Question ID, answer, form version, event time | Meaning survives label changes |
| Calculated data | Inputs, formula version, result | The number remains explainable |
| Qualification | Components, total, threshold, outcome, rule version | A status has a reason |
| Handoff | Owner, stage, accepted time, next action | The receiving team can act |

## 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.

| Stage | Scope | Required exit evidence |
| --- | --- | --- |
| 1. Contract and synthetic proof | Invented records with no real outreach | Fields, keys, restrictions and errors behave as predicted |
| 2. Representative pilot | Small frozen sample across edge cases | Field-level acceptance and reason-coded differences |
| 3. Controlled production window | Bounded real records with monitored writes | Workflows complete without duplicate or forbidden actions |
| 4. Cutover and read-only hold | All in-scope records and new traffic | Counts reconcile and a full operating cycle completes |

## 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.

| Metric | Formula | Decision |
| --- | --- | --- |
| Import acceptance | Accepted rows / attempted rows | Transport and validation success |
| Critical-field completeness | Records meeting the critical contract / accepted records | Usable context |
| Duplicate creation | Unintended duplicates / accepted records | Identity quality |
| Suppression parity | Destination restricted records / source restricted records | Restriction continuity |
| Association accuracy | Correct tested associations / tested associations | Relationship integrity |
| Workflow parity | Correct tested outcomes / executed test workflows | Operational continuity |
| Reconciliation gap | Source in-scope records minus accepted and reason-coded rejected records | Unaccounted loss or excess |

## 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.

| Launch gate | Pass evidence | Blocker |
| --- | --- | --- |
| Permission | Restrictions reconcile and win | Required restriction cannot be represented |
| Identity | Match rules and crosswalk are explainable | Duplicate or wrong-record risk exceeds threshold |
| Context | Critical fields and event history meet contract | Attribution or qualification becomes unexplainable |
| Operations | Owners, alerts and workflows pass | Invisible failures or unintended enrollment |
| Recovery | Rollback rehearsal and restore objective pass | No safe route back |
| Measurement | Counts, definitions and windows align | Differences have no reason codes |

## 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.

- [Read the involve.me review](https://best-lead-generation-software.com/reviews/involve-me)
- [involve.me custom contact properties](https://help.involve.me/en/articles/16394729-custom-contact-properties)
- [involve.me integrations documentation](https://help.involve.me/en/articles/1566559-integrations)
- [involve.me email automation](https://help.involve.me/en/articles/13052756-email-automation-build-personalized-email-workflows)

## 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.

| Dimension | Weight | Pass evidence |
| --- | --- | --- |
| Scope and ownership | 10 | Every object has a decision and owner |
| Identity and crosswalk | 15 | Stable old-to-new IDs and tested match rules |
| Field and context continuity | 15 | Critical values retain meaning and provenance |
| Permission and suppression | 15 | Restrictions reconcile before activation |
| Attribution and qualification | 10 | Original events and rule versions remain explainable |
| Workflow safety | 10 | Imports do not trigger unintended actions |
| Reconciliation | 10 | Every difference has a reason code |
| Rollback and recovery | 10 | Rehearsed path restores safe operation |
| Security and retention | 5 | Access, archive, deletion and evidence are controlled |

## 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.