You've booked the CRM move as an import, mapped the spreadsheet columns and reserved a cutover window. The decision is whether your team is relocating records or changing the rules that marketing, sales and service use to act on them. Treating those jobs as interchangeable is how a technically clean import becomes an operational problem.
Why a Finished Load Can Still Fail RevOps
Say you're a marketing operations lead moving a legacy CRM into Salesforce Sales Cloud. The import finishes, the record counts match and users can log in. During the opening week, though, previously qualified leads enter nurture, account owners lose visibility and campaign reporting assigns pipeline to the wrong source.
Data conversion changes format, structure, encoding or representation while preserving the record's intended meaning. Data migration is the broader movement between systems, usually combining extraction, conversion, validation, transfer and post-cutover governance. Most platform transitions need both. Decide how values should change before trying to prove that relationships and reporting survived the move.
The import succeeded, but the handoff didn't
In that scenario, the legacy system's Qualified status might mean that sales accepted the lead. Mapping it directly to a marketing-qualified lifecycle stage changes who should act next. The destination accepts the value because it's valid, not because it expresses the right business decision.
Ownership creates a similar trap. Copying a representative's name into a text property doesn't establish an active Salesforce owner or HubSpot record owner. A preserved consent flag can also become misleading if its purpose, source and supporting history don't accompany it.
For marketing operations, sales operations and RevOps managers, these aren't isolated database defects. They affect routing, segmentation, forecasting inputs and customer handoffs across Salesforce Sales Cloud, Account Engagement, Service Cloud, Revenue Cloud and HubSpot Sales and Marketing Hubs.
Scope the business outcome
The useful question in data conversion vs data migration isn't which label sounds more technical. It's which decisions require business approval and which controls prove the destination works.
A project manager can mark an import task complete without demonstrating that a seller receives the right lead or that a campaign report retains its definition. Use the comparison below as the working distinction when assigning responsibilities and accepting deliverables.
What Conversion Changes and Migration Moves
Data conversion versus data migration
| Question | Data conversion | Data migration |
|---|---|---|
| Definition | Changes format, structure, encoding or representation while preserving meaning | Moves data between systems, combining extraction, transformation or conversion, validation, transfer and governance |
| Typical trigger | Field types, dates, encodings, picklists or object models don't match | A new CRM, tenant, warehouse or marketing platform must become the system of record |
| Acceptance test | Semantic fidelity, and presentation fidelity where layout matters | Completeness, metadata continuity, permissions, checksums and operation in the destination |
| RevOps example | CSV values remapped to Salesforce or HubSpot lifecycle, ownership, consent and dates | Cutover of accounts, contacts and opportunities into a new Sales Cloud org or HubSpot portal |
| Failure that still looks done | Records load but stages, owners or attribution mean the wrong thing | Counts match but routing, relationships and reports stay broken |
| Project deliverable | Documented conversion rules and value maps | Reconciliation totals, relationship checks, permissions and post-cutover governance |
Values can load and still mean the wrong thing. Records can also arrive intact while the handoffs and reports that depend on them remain broken. These are different failure modes, so they need different acceptance evidence.
Separate representation from relocation
Start with what changes. Converting a CSV date string into a Salesforce Date field changes its representation; moving a compatible dataset into another environment changes its location. Rebuilding a flat customer export as Accounts, Contacts and Opportunities combines structural conversion with migration.
The trigger determines who needs to participate. A picklist mismatch needs the person who owns its business definition. A destination becoming the system of record also needs administrators and integration owners who can coordinate applications that read or update those records.
The City of Toronto's Digital Records Conversion and Migration Guideline distinguishes conversion that changes format while preserving authenticity, reliability, integrity and usability from migration between hardware or software configurations without changing the underlying format. Where relevant, conversion must also preserve visual characteristics such as layout, colour and typography.
That records-management distinction gives CRM teams a useful acceptance-test split:
Practical rule: Test conversion for fidelity of meaning. Test migration for completeness and successful operation in the destination.
A checksum can help verify that an unchanged export file survived transfer. It can't establish that a transformed opportunity stage still represents the same sales milestone. For transformed fields, compare the result with an approved mapping rather than expecting identical file contents.
Specify the evidence separately
For a Salesforce conversion, record the source status, destination field, permitted target value and exception handling. For the accompanying migration, retain source identifiers, target identifiers and the relationship map used to attach Contacts to Accounts and Opportunities to their intended Accounts.
An ETL workflow can execute extraction, transformation and loading, but it doesn't replace either specification. The pipeline implements decisions; business owners still approve what the decisions mean.
This separation also improves budgeting. F1Group's resource on understanding data migration costs is useful context when distinguishing mapping effort from transfer, testing and cutover work, rather than pricing the entire project as a file upload.
Label each workstream explicitly. Conversion rules describe how values become usable in the target model; migration controls describe how the team will prove that the move is complete and operationally sound.
How to Judge Whether the Load Worked
Matching record counts provides reassurance, but it doesn't establish business continuity. A target can contain the expected number of Contacts while attaching them to the wrong Accounts, or contain every Opportunity while assigning stages that distort the forecast.
Measure performance and correctness separately. Otherwise, a green import log can conceal the exact defects your sales and marketing teams need fixed.
Four outcomes that separate a fast load from a sound one
| Outcome | What to measure | False success to reject |
|---|---|---|
| Throughput | Records loaded per minute | A fast load that leaves lifecycle stages unmapped |
| Transformation error rate | Values that fail mapping or land in the wrong type | A zero-error file that preserves obsolete statuses |
| Relationship reconciliation | Share of account, contact and opportunity links restored | Orphan contacts and broken account hierarchies |
| Post-load quality score | Accuracy and coherence of the fields RevOps actually uses | Matching counts with reporting and routing that no longer agree |
Give each outcome its own denominator
Calculate transformation errors against the values or records evaluated, and document which denominator you use. Include semantic defects identified during validation, not only rows rejected by the importer.
For relationship reconciliation, compare expected links with restored links using the source-to-target identifier map. In HubSpot, inspect Contact-to-Company and Deal associations; in Salesforce, test Account relationships and Opportunity Contact Roles where they're in scope.
Build the post-load score from agreed data-quality metrics, with visible component results. A combined score shouldn't allow accurate email addresses to conceal missing ownership or unusable attribution.
Test quality in CRM terms
Statistics Canada's quality framework evaluates information through relevance, accuracy, timeliness, accessibility, interpretability and coherence. Apply those dimensions to the fields and processes your team uses:
- Relevance: Confirm that each retained field supports routing, scoring, forecasting or another defined process.
- Accuracy: Validate names, email addresses and revenue values against the authoritative source, including currency context.
- Timeliness: Check that last-activity dates and stage-age calculations distinguish recent engagement from historical imports.
- Accessibility: Test representative user profiles and teams, not just the administrator who performed the load.
- Interpretability: Ask marketing and sales owners whether the same picklist label describes the same qualification decision.
- Coherence: Compare attribution, lifecycle and ownership across Sales Cloud, Account Engagement and HubSpot wherever they exchange information.
A completed load is not a successful migration.
Keep the final evidence split explicit. Conversion rules document how values change; migration controls verify counts, relationships, deduplication outcomes, permissions, auditability and reporting continuity. Acceptance should require both, with unresolved exceptions assigned to a named owner.
Privacy Duties That Travel With the File
A conversion can be a new processing activity, not merely a mapping exercise. Sending contact attributes through a staging service, enrichment platform or foreign-hosted integration introduces questions that an import success message cannot answer.
The Office of the Privacy Commissioner of Canada's PIPEDA principles require identified purposes, limited collection and retention, accuracy, and safeguards against loss, theft, unauthorized access, disclosure, copying, use or modification. Apply those duties to the working copies, not just the production CRM.
Trace the complete processing path
Review extraction files, API credentials, staging tables, import logs, failed-record reports, sandbox copies and temporary administrator access. A spreadsheet on a shared drive deserves the same deliberate review as the destination Salesforce or HubSpot environment.
Answer these questions in order:
- Identify personal information: Which fields contain it, and what documented purpose justifies processing each field?
- Map intermediate locations: Where do temporary files, backups and rejected records travel?
- Assess additional exposure: Does the destination, foreign-hosted integration or AI tool change who can access the information?
- Prove retention and deletion: Who removes working copies, when, and what evidence confirms completion?
The Canadian cross-border processing guidance addresses continued organizational accountability and comparable protection when third parties process personal information; Quebec organizations must also complete a privacy impact assessment before transferring personal information outside Quebec and verify equivalent protection.
Use a consent management framework to connect migrated preferences with purpose and supporting evidence. For the separate question of marketing measurement, SourceLoop's discussion of how to measure conversions while respecting privacy offers additional context, not a substitute for Canadian legal review.
Prepare for incidents before extraction
The Privacy Commissioner's breach guidance includes loss, unauthorized access or unauthorized disclosure resulting from inadequate or missing safeguards, requires reporting and individual notification where there is a real risk of significant harm, and requires records of every breach to be retained for two years, including breaches below that reporting threshold.
Assign an incident owner, an evidence pack and an escalation path in the migration runbook. Preserve access logs, affected file inventories, relevant timestamps and containment actions, with controlled access to that evidence.
Can the organization prove where personal information travelled, who accessed it and what happened to the working copies?
A load that cannot account for where Canadian contact, account and opportunity data was staged or accessed remains operationally incomplete.
Which Records to Keep Change or Leave Out
Preserving bad legacy values faithfully isn't the same as building a useful CRM. A conversion can retain every field while carrying forward obsolete statuses, conflicting account hierarchies and consent information that nobody can substantiate.
Canadian reporting in IT Brief Canada states that 84% of organizations struggle with inaccurate or duplicate data, with outdated contact information at 32%, identity fraud or impersonation at 17%, duplicate records at 15%, and difficulty integrating multiple sources at 12%.
Field and record dispositions before cutover
| Disposition | Use it when | Approver | Risk if skipped |
|---|---|---|---|
| Preserve exactly | Legal name, contract IDs and still-valid consent history | Data owner | Audit and consent gaps |
| Transform | Lifecycle, ownership, dates, picklists and attribution must match the destination | RevOps | Automations fire on the wrong meaning |
| Merge | Duplicate contacts or accounts exceed the confidence threshold | RevOps with sales operations | Double routing and split pipeline |
| Quarantine | Low-confidence matches, suspected impersonation or conflicting hierarchies need review | Data owner | Bad merges that are hard to undo |
| Exclude but retain | No current routing, reporting or service purpose exists | RevOps | Dirty system of record, or silent loss if not recoverable |
Set field-level survivorship rules
Don't choose the surviving record and assume every field on it should win. A recently updated Contact might have a correct job title but an unreliable company association. Another record may contain the authoritative contract reference or documented communication preference.
Define survivorship by field, including the trusted source, precedence rule and treatment of conflicts. Name the owner of the surviving Contact or Account, and preserve the identifiers needed to explain how the consolidated record was assembled.
Set deduplication confidence thresholds before running bulk merges. Exact email matches may support some decisions, but shared addresses, subsidiaries and company-name similarities require additional context. Send uncertain matches to an exception queue rather than forcing them into a clean-looking result.
Retain evidence without importing clutter
Deleting or consolidating records can improve routing while creating attribution or relationship-history gaps. Before approval, inspect Campaign Member relationships, Opportunity Contact Roles, HubSpot Deal associations and service history attached to the affected records.
RevOps and the data owner approve the disposition, not the import tool. Record the reason, source identifier, approver and recovery location for excluded records, subject to an approved retention policy. Recoverable doesn't mean retained indefinitely.
Less migrated data can support more trustworthy revenue operations when exclusions are deliberate and explainable. A complete import isn't necessarily safer than a smaller, governed dataset.
After launch, monitor actual routing, lifecycle progression and reporting results. Review the exception queue alongside operational defects, rather than treating the original failed-record file as the final quality assessment.
Which Job Each Platform Move Needs and the Go or No-Go
A legacy CRM replacement is a migration with embedded conversion. An in-place HubSpot property cleanup is primarily conversion. Name the dominant work before assigning a tool, because the label should determine the approvals, dependencies and acceptance evidence your team plans.
Dominant work by CRM and marketing-automation situation
| Situation | Dominant work | What must be true at the end |
|---|---|---|
| Legacy CRM to Salesforce Sales Cloud | Migration with embedded conversion | Accounts, contacts and opportunities arrive with remapped stages, owners and relationships |
| HubSpot property cleanup in the same portal | Conversion | Picklists, dates and lifecycle values change without a new system of record |
| Account Engagement connected to existing Salesforce | Selective conversion plus integration | Prospect fields, scores and lifecycle agree with leads and contacts |
| Service Cloud or Revenue Cloud added beside Sales Cloud | Subset migration | Cases, entitlements or commercial records move while core accounts stay coherent |
| Clay enrichment into the CRM | Conversion of external attributes | Firmographic fields are normalized and sourced, not treated as a new database |
| Tenant-to-tenant move of a standardised export | Migration | Completeness, permissions and checksums hold because the format already matches |
Choose the program around the operational dependency
For Sales Cloud, plan the dependency order around Accounts, Contacts, Opportunities and their related records. Carry source identifiers into a controlled crosswalk so child records attach to the intended parents. Keep workflow and Flow behaviour under deliberate control during loading, then test the intended production behaviour before release.
A same-portal HubSpot cleanup needs a different approach. Inspect lists, workflows, scoring and reports that reference a property before replacing its options. Changing the displayed label without checking downstream conditions can leave the property cleaner and the process less reliable.
Connecting Salesforce Account Engagement, formerly Pardot and also referred to as MCAE, requires selective mapping plus ongoing integration design. Confirm which system owns each shared field, how sync conflicts should resolve and how prospects relate to Salesforce Leads and Contacts. Don't assume an integration should overwrite every difference.
For Service Cloud, identify the Cases, entitlements and customer relationships that must remain usable. For Revenue Cloud, define the commercial records in scope for your implementation rather than treating the product name as an object inventory. Adding either platform doesn't automatically require relocating all existing Sales Cloud data.
Enrichment through Clay should feed sourced, normalized attributes into approved CRM fields. Keep enrichment provenance separate from authoritative customer information, and avoid overwriting verified values just because an external result is newer. If the enrichment workflow itself is changing tools, the Yalc migration guide for GTM teams provides a focused companion for that narrower transition.
Make the go or no-go decision explicit
Choose conversion-first when the system of record stays put and inconsistent meaning is the primary problem. Choose a migration program with a conversion workstream when the trusted operational home changes. Where personal information passes through foreign-hosted tools, scope the necessary conversion, transfer and privacy controls together.
A platform move doesn't automatically produce an end-to-end process. The Government of Canada's service-modernization reporting illustrates that broader integration challenge: modernizing access and connecting the full service remain distinct operational tasks.
Delay cutover when relationship, consent or ownership rules remain unapproved. An unresolved rule affecting customer communication or account access isn't an ordinary cleanup item to hand to users after launch.
Define the rollback trigger as well as the launch criteria. Identify who can stop the release, where users will work if validation fails and how changes made during the cutover window will be recovered. A fallback that nobody has rehearsed is only an assumption.
Put the work into an executable sequence
Inventory objects and personal fields. List source objects, destination objects, dependencies and business owners. Include Campaigns, activities, service records and integration-managed properties where they affect the scoped process.
Write conversion rules separately from migration controls. For each transformed field, specify source meaning, destination meaning, exceptions and approval. For the move, define reconciliation, access testing and reporting evidence.
Assign a disposition and a named approver. Use preserve, transform, merge, quarantine or exclude decisions at the field and record levels. Resolve disputed ownership before the extraction becomes a production dependency.
Define the success outcomes and breach evidence pack. Assign responsibility for throughput, transformation errors, restored relationships and post-load quality, alongside incident escalation and controlled audit evidence.
Rehearse cutover in a sandbox or suitable test environment. Include difficult records, inactive owners and unusual associations. Compare routing and reports, not only row counts, and verify that the final change set can be applied without undoing approved transformations.
The deliverable this week should be a named dominant workstream and an owner authorized to approve it. Choose conversion when meaning needs repair, migration when the operational home changes, or both when the destination requires a new representation of the business.
MarTech Do offers RevOps system audits, CRM implementation and data-migration support across Salesforce and HubSpot as an option for teams that need help designing these controls. Visit MarTech Do to discuss your source systems, target objects and cutover risks, and scope a plan that separates conversion decisions from migration acceptance.
