CRM CLEANUP & MIGRATION

Canadian CRM migrations require CASL re-consent planning for contacts whose implied consent has expired — migrating them without a re-consent plan transfers a compliance liability into the new system

Canadian businesses running a CRM migration face a compliance exposure that most migration checklists do not address. CASL implied consent — the form of consent that covers a broad range of commercial relationships — has a two-year maximum duration. A contact database assembled over three to five years will contain a meaningful proportion of records whose implied consent has expired. Migrating those records into a new CRM and continuing to send commercial email to them is a CASL violation. The migration moment is also the moment when French-language data, Quebec contact preferences, and provincial segmentation are most often lost. Migration projects standardise data into a flat format, and the nuances of a bilingual contact database rarely survive a poorly planned migration intact. We run CRM cleanup and migration projects for Canadian businesses that include CASL consent expiry assessment, bilingual data preservation, provincial segmentation, and deduplication before the new system goes live.

Request a CRM Cleanup Audit → View the evidence →
This is for you if

This service is for Nepal-based businesses that have been running their sales process through a combination of WhatsApp Business, personal phones, and Google Sheets — and have now decided to move into a proper CRM.

Your contact list exists across multiple Google Sheets maintained by different team members, each with a different column structure

You have exported contacts from WhatsApp Business and now have a list of names and phone numbers with no additional context

You have never defined what fields, pipeline stages, or lead source categories your CRM should have

You want to set up HubSpot, GoHighLevel, or a similar platform but are not sure what data to import or how to structure it first

What's broken

Problems We Solve

Contacts with expired CASL implied consent migrated without a re-consent workflow

CASL distinguishes between express consent (where a contact has explicitly opted in to receiving commercial electronic messages) and implied consent (which arises from an existing business relationship, an inquiry, or a published contact address used in a business context). Express consent does not expire. Implied consent has a defined maximum duration: two years from the date of the most recent business transaction, six months from an inquiry, and until rescinded for contacts whose email address was published in a business directory context. A CRM migration that moves all contacts regardless of consent type and consent date is moving a subset of contacts whose implied consent has already expired. The size of that subset grows with the age of the database. A five-year-old CRM with active imports but no consent date tracking may have 20 to 40 percent of contacts in an expired implied consent state. We assess consent status and consent date across the database before migration, categorise contacts by consent type and expiry status, and build a pre-migration re-consent workflow for contacts whose implied consent is within 90 days of expiry or has already expired. Contacts who do not re-consent are archived rather than migrated.

No French-language data in the migrated CRM

Canadian businesses with Quebec-based contacts, bilingual team members, and French-language marketing content often hold French-language data in their CRM: French-language notes, Quebec-specific segmentation tags, French contact preferences, and deal descriptions written in French. A migration that does not explicitly map these fields to the new CRM loses them. The more common loss is subtler: the migrated CRM treats all Canadian contacts as a single homogeneous segment, without province or language preference flags. The Quebec marketing team, which was previously filtering by language preference or province to send French communications, loses that capability because the migration did not preserve those fields. We audit French-language and bilingual data fields before migration, build the field mapping to preserve them in the destination CRM, and configure Quebec-specific segmentation in the new system so that bilingual marketing workflows are available from day one post-migration.

Duplicate contacts from multiple Canadian marketing channels

Canadian CRM databases accumulate duplicates from multiple marketing and sales channels that do not de-conflict before writing to the CRM: HubSpot form submissions from the website, Eventbrite conference registration exports, LinkedIn lead generation form exports, trade show badge scanner exports, and manual entries by the sales team from business card exchanges. The same individual can appear with a different first name spelling (John versus Jon), a different email address (work versus personal), missing fields on some records and complete fields on others, and sometimes different job titles across records from different time periods. Standard deduplication tools that match only on email address will miss a significant portion of these duplicates. We run multi-signal deduplication before migration, matching on email address, email domain plus name similarity, phone number, and company name combination, producing a merge recommendation report for review before any merges are executed, and importing the deduplicated dataset into the new CRM.

Provincial tax data not migrated correctly

Canadian businesses with deals that include provincial tax calculations face a specific migration data mapping challenge. GST, HST, PST, and QST rates vary by province, and the tax rate applied to a historical deal is a piece of accounting data that needs to be preserved in the new CRM for reconciliation against historical invoices. Most CRM migration templates include standard deal fields (value, stage, close date, owner) but do not include tax rate or tax amount fields, because these are not standard CRM fields. The result is that post-migration deal records are missing provincial tax data, which creates discrepancies when the finance team attempts to reconcile CRM deal history against accounting records. We identify tax-related fields in the source CRM, create corresponding custom fields in the destination CRM, and include them in the migration file so that historical deal records arrive in the new system with provincial tax data intact.

What we engineer

What We Do

CRM data structure definition

Before any import, we work with you to define what fields the CRM needs, what your pipeline stages should be named, and what lead source categories apply to your business. This becomes the schema that all imported data maps to.

Google Sheet audit and standardisation

We audit all existing Google Sheets, identify inconsistencies in column structure and data formatting, and produce a single cleaned master import file with consistent columns, standardised phone number formats, and clear handling of blanks.

Cross-sheet deduplication

We identify contacts that appear in more than one sheet, standardise the matching fields, and merge duplicate rows so that each contact appears once in the final import file.

WhatsApp export processing

We take your WhatsApp Business contact exports, merge them with the Google Sheet data, and flag contacts that need additional context before they can be actioned in the CRM.

CRM import and configuration

We import the cleaned file into your chosen platform — HubSpot, GoHighLevel, or an equivalent — with correct field mapping, pipeline stage setup, and lead source property configuration.

Post-import validation

After the import, we check for records that did not map correctly, contacts missing required fields, and any duplicates that were not caught before the import. We provide a validation report and fix any issues before handing the CRM over for active use.

Request a CRM Cleanup Audit →
What changes

What Changes

Before
After
Before Each team member has maintained their own format. One sheet has phone numbers in column B, another has them in column D. Some rows have email addresses, most do not. Company names are in some rows and absent from others. Lead source is recorded in a free-text notes column by one person and missing entirely from another person's sheet. Before any CRM import can proceed, this data needs to be standardised into consistent columns for name, email, phone number, company, and lead source. Without that standardisation, the CRM import wizard cannot map fields correctly, and the resulting contact records are incomplete from day one.
After A single cleaned contact list exists, deduplicated and standardised, ready for import
Before Three sheets with significant overlap is a common pattern. The sales team has "leads 2022," "leads 2023," and "WhatsApp contacts" as separate files. The same contact appears in all three, sometimes with a different phone number format (+977-98XXXXXXXX in one, 98XXXXXXXX in another, 977 98XXXXXXXX in a third). When all three sheets are imported without deduplication, the CRM starts with multiple records for the same person. Deduplication before the import is the first step. It requires standardising phone number formats so that matching logic can identify duplicates correctly, then merging or removing the redundant rows before the import file is finalised.
After The CRM is configured with fields, pipeline stages, and lead source categories that reflect how the business actually works
Before A contact exported from WhatsApp Business is a name and a phone number. There is no conversation history attached to the export, no record of what was discussed, no indication of where the lead is in the sales process, and no notes from the sales person. Importing a WhatsApp export directly into a CRM produces a contact database that has names and numbers but no sales intelligence. For each WhatsApp contact that matters, the context needs to be added manually or through a structured interview with the sales team before the import. Without that step, the contacts are in the CRM but the information needed to action them is not.
After Every imported contact has a consistent data structure so that filters, segments, and reports work from day one
Before The Google Sheet has names and contact details but no record of where each lead came from. Without that data, the first CRM reports cannot show which channels — Instagram, referral, website, trade fair — are producing the best leads. The business cannot make a channel allocation decision based on CRM data if the CRM was never given that information. Adding lead source data retroactively is partially possible through team recall, invoice records, and message history, but it requires a structured process. Where it cannot be recovered, a consistent "source unknown" classification needs to be applied so that future data is not contaminated by blanks that look like a separate category.
After The team has a defined process for adding new contacts so the CRM stays clean going forward
How it works

Process

  1. 01

    Discovery call (60 minutes)

    60 minutes

    We review your existing Google Sheets and WhatsApp exports, understand your sales process, and define the fields, pipeline stages, and lead source categories your CRM needs.

  2. 02

    Data audit

    We audit all source files for structural inconsistencies, blank fields, phone number format variations, and duplicate entries. We provide a written audit report with findings and a recommended approach.

  3. 03

    Data standardisation and deduplication

    We produce a single cleaned master import file with standardised columns, consistent phone number formats, merged duplicates, and retroactively recovered lead source data where possible.

  4. 04

    CRM configuration

    We configure your chosen CRM platform with the agreed field structure, pipeline stages, and lead source properties before the import runs.

  5. 05

    Import and validation

    We run the import, check for mapping errors and missed duplicates, and produce a post-import validation report. Any issues identified are fixed before the platform is handed over.

  6. 06

    Team handover

    We walk the team through the configured CRM, explain how to add new contacts correctly, and document the data entry standards so the clean database stays clean.

Request a CRM Cleanup Audit →
Common questions

FAQ

How do I handle CASL implied consent expiry when migrating a Canadian CRM to a new platform?

Before migrating, export your contact database with the consent type field, the consent date field (or last interaction date if you are using that as a proxy for implied consent), and the consent source. Calculate the days since last interaction or consent date for every contact, and flag records where implied consent has expired (more than 730 days since the qualifying interaction for business relationship implied consent, or more than 180 days for inquiry-based implied consent). For records approaching expiry (within 90 days), trigger a re-engagement campaign before migration that converts them to express consent if they respond, or archives them if they do not. Records with expired implied consent and no response to the re-engagement campaign should not be migrated into the new CRM for marketing use — they can be archived in a suppression list. This pre-migration consent triage is the cleanest way to ensure the new CRM starts with a compliant contact database.

How do I preserve French-language contact preferences and segmentation during a Canadian CRM migration?

French-language preservation requires a pre-migration audit of which fields contain French-language data or French-preference indicators. In HubSpot, this typically includes a language preference property, a province or region property, any custom segmentation lists with Quebec-specific criteria, and contact notes written in French. In the migration field mapping document, ensure each of these fields has a corresponding destination field in the new CRM, not a generic notes dump. If the destination CRM does not have a native language preference field, create a custom contact property before migration. Post-migration, verify that existing segmentation lists and contact views that used French-language or Quebec-specific filters can be rebuilt in the new system using the migrated field data.

How do I deduplicate a Canadian CRM before migrating to HubSpot or Zoho?

Start with an email address deduplication pass, which will identify the majority of exact duplicates. For the remaining duplicates (same person with different email addresses or missing email on one record), run a secondary pass matching on phone number, then a tertiary pass matching on first name plus last name plus company name. Tools such as OpenRefine allow fuzzy matching on text fields to catch name spelling variations (for example, Marie-Claire versus Marie Claire). For each matched pair, generate a confidence score based on how many fields match and present the high-confidence pairs (two or more signals matching) for bulk merge approval and the low-confidence pairs for individual review. Execute the merges in your source CRM or in a staging dataset before the migration import, so the new CRM receives clean data from the start rather than requiring a post-launch deduplication project.

How do I migrate provincial tax rate data correctly when moving between CRM platforms in Canada?

First, identify where provincial tax data lives in your source CRM: it may be in a deal custom field (tax rate percentage or tax type), in a line item field, in a deal notes field, or only in a connected accounting system such as QuickBooks or FreshBooks. If the tax data is in a custom field in the source CRM, map it to a corresponding custom field in the destination CRM and include it in the migration file. If it is only in deal notes as freetext, you have two options: parse the notes programmatically to extract the tax data before migration, or accept that historical deal tax data will need to be reconciled from the accounting system rather than the CRM. For new deals post-migration, configure a workflow in the new CRM that sets the tax type automatically based on the billing province field, so that going forward the tax data is structured and consistent.

What is the process for PIPEDA-compliant data migration when switching CRM platforms in Canada?

PIPEDA (the Personal Information Protection and Electronic Documents Act) requires that personal information be used only for the purposes for which it was collected, that it be kept accurate and up to date, and that it be disclosed to third parties only with consent or under specific exceptions. A CRM platform change involves transferring personal data to a new software vendor (a new third party). Under PIPEDA, you should review whether your privacy policy discloses that customer data may be stored by third-party software providers, ensure the new CRM vendor has a PIPEDA-compatible data processing agreement or privacy policy, update your privacy policy to reflect the new platform if necessary, and notify contacts if the change involves a new data processing purpose or a new category of data use. The migration itself should include a data minimisation review: migrate only the personal data fields that are necessary for the intended use in the new system, not every field that was ever captured.

Our team

The people behind the work

Not a black box. Real specialists you can call, with their names on the work.

Niraj Raut

Niraj Raut

Founder — Ecommerce SEO
Keshab Joshi

Keshab Joshi

PPC Expert
Hawrry Bhattarai

Hawrry Bhattarai

Google Ads Expert
Arogya Rijal

Arogya Rijal

SaaS SEO Expert
About Us →
Start here

CRM cleanup and first-time CRM setup for Nepal businesses

If your contact data is currently split across Google Sheets and WhatsApp exports, the right starting point is a data audit, not a CRM purchase. The audit identifies what you have, what state it is in, and what work is needed before a CRM import will produce a usable database.

Request a CRM Cleanup Audit →

Ignited Nepal is a Growth Engineering Company based in Kathmandu. We work with Nepal businesses setting up their first CRM and with teams that need their existing data cleaned before it can be used.