CRM Data Cleanup Before Migration: Essential Checklist

CRM Data Cleanup Checklist Before Migration

A CRM data cleanup checklist before migration helps you remove duplicates, correct inaccurate records, standardise fields and decide what should actually move to the new system. Cleaning customer data before a CRM migration is usually safer and cheaper than transferring every old record and trying to repair the database afterwards.

Migration is not only a technical exercise. It is also a business decision about which customer, donor, student, patient, vendor or prospect information is useful enough to retain. Poor-quality data can create duplicate follow-ups, incorrect reports, failed integrations and privacy risks in the new CRM.

This guide explains how Indian small businesses, NGOs, schools, clinics, agencies and D2C brands can prepare their CRM data before migration.

1. Define the Scope of the CRM Migration

Before opening spreadsheets or exporting records, document what the migration includes. A business may have customer data spread across a CRM, Excel files, WhatsApp conversations, email tools, billing software, website forms and staff members’ personal devices.

Moving everything into one system without reviewing it can make the new CRM difficult to use.

Identify the systems and files involved

Create an inventory of every source containing customer or stakeholder information.

Common sources include:

• Existing CRM
• Excel and Google Sheets
• Accounting or invoicing software
• E-commerce platforms such as Shopify, WooCommerce or Magento
• Payment gateways and donation platforms
• Email marketing tools
• Website enquiry forms
• Lead forms from Meta or Google
• WhatsApp Business records
• Call-centre or telecalling software
• School admission or student management software
• Clinic appointment systems
• Agency project management tools
• Staff-owned contact lists

Record the owner of each source, the type of data it contains and whether it is still actively used. A spreadsheet maintained by a sales coordinator may contain newer phone numbers than the official CRM, but it may also contain inconsistent or unauthorised data.

Define the migration objective

The required cleanup depends on why you are migrating.

For example:

• A sales team may need active leads, contacts, companies, deal history and next actions.
• An NGO may need donor profiles, donation history, communication preferences and tax-related receipts.
• A school may need student, parent, enquiry and admission records, with access restricted by role.
• A clinic may need patient contact details and appointment history, but should avoid moving unnecessary medical information into a general-purpose CRM.
• A D2C brand may need customer profiles, order history, returns and consent status.

Write down the business processes that the new CRM must support. This prevents the project from becoming a simple file-copying exercise.

Set a retention rule

Decide which records will be:

1. Migrated as active records
2. Migrated as historical or archived records
3. Stored separately for legal or accounting needs
4. Deleted because they are obsolete, invalid or unauthorised

Do not assume that older records are automatically useless. A previous donor may become relevant again, and an old B2B contact may still be associated with an active company. At the same time, keeping every record indefinitely creates clutter and may increase privacy exposure.

Ask:

• Is the record linked to a current customer, donor, student, patient or vendor?
• Has there been a recent interaction?
• Is there an open transaction, case or obligation?
• Is the record needed for accounting, tax, audit or legal purposes?
• Is there a valid reason to retain the information?
• Does the organisation have permission or another lawful basis to use it?

2. Create a Data Inventory and Ownership Plan

A data inventory shows what you have before you decide what to clean. It also makes responsibility clear. Data cleanup often fails when everyone assumes another person will resolve unclear or duplicate records.

Build a field-level inventory

For each data source, record the important fields and their condition.

A useful inventory can include:

Do not rely only on column names. “Phone” may contain mobile numbers, landlines, WhatsApp numbers, notes or multiple numbers in one cell. “Status” may mean lead stage in one system and payment status in another.

Assign data owners

Appoint one person for each major data group. The owner should answer business questions that a developer or migration consultant cannot answer, such as:

• Which lead statuses are still valid?
• Are two similar records the same donor?
• Which customer category should be used?
• Which old fields are no longer needed?
• Which records must be restricted from general staff?

For a small organisation, one person may own several data groups. The important point is that responsibility is explicit.

Keep an issue log

Create a shared log for questions and decisions. Examples include:

• Whether “Pvt Ltd” and “Private Limited” should be standardised
• Whether a landline should be stored separately from a mobile number
• Whether former students should remain in the active contact list
• Whether old marketing contacts can be imported
• Whether an invoice address should overwrite a general contact address

Record the decision, person responsible and date. This creates a reference for future maintenance.

3. Standardise Customer Data Before Deduplication

Standardisation makes it easier to identify duplicates and map records to the new CRM. It also improves searching, segmentation, automation and reporting after migration.

Do not change data randomly. First define the format that the new CRM will accept.

Standardise names and organisation names

Decide how names should be stored:

• Individual first name and last name in separate fields
• Company or institution name in a dedicated organisation field
• Legal name and display name in separate fields where necessary
• Honorifics such as Mr, Mrs or Dr in a separate field, if required

Avoid placing excessive information in the name field, such as:

• “Rahul Sir”
• “Ms Priya - Pune”
• “Dr Anil, parent of Rohan”
• “ABC School owner”

These details belong in structured fields, notes or relationships.

For organisations, standardise obvious variations without changing the legal identity. For example, “ABC Pvt. Ltd.” and “ABC Private Limited” may refer to the same company, but verify before merging. Do not remove meaningful distinctions between branches, franchises or separate legal entities.

Standardise Indian phone numbers

Phone numbers are a common source of duplicate records in India. The same number may appear with different spacing, country codes or prefixes.

Choose a format, usually an international format with the India country code, and apply it consistently. Review:

• Numbers with spaces or hyphens
• Numbers beginning with or without the country code
• Numbers containing a leading zero
• Landlines with STD codes
• Multiple numbers in a single cell
• Extensions
• Invalid or unusually short numbers
• Shared family or office numbers

Do not automatically assume that every ten-digit Indian number is valid or belongs to the person named in the record. Validate where the number is important, especially for payment follow-up, admissions, appointments or delivery communication.

Store mobile, alternate phone, WhatsApp and landline separately if the CRM supports those fields. If you cannot verify whether a number is WhatsApp-enabled, do not label it as WhatsApp merely because it is a mobile number.

Standardise email addresses

Clean email fields by:

• Removing extra spaces
• Converting the address to a consistent case for comparison
• Separating multiple email addresses
• Identifying obvious formatting errors
• Marking bounced or unsubscribed contacts
• Keeping role-based addresses such as info@ or accounts@ distinct from personal addresses

Do not silently correct uncertain addresses. For example, changing a typo in a domain may create an address that belongs to another person. Mark it for review or request confirmation.

Standardise addresses and locations

Indian addresses are often incomplete or written in free-text form. Avoid trying to create a false level of precision.

Useful structured fields may include:

• Address line
• Locality or area
• City
• District
• State
• PIN code
• Country
• Billing and shipping address
• Branch or delivery location

Standardise state names, such as Maharashtra rather than using several abbreviations, and validate PIN codes where delivery or invoicing depends on them. Keep the original address in a controlled archive if a significant transformation is being made.

Standardise dates, currency and statuses

Choose one date format for import, preferably the format required by the destination CRM. Review whether dates mean:

• Lead creation date
• First interaction
• Last interaction
• Donation date
• Payment date
• Admission date
• Appointment date
• Contract renewal date

Dates written as 03/04/2024 may be ambiguous. Confirm whether the source uses day-month-year or month-day-year.

For financial information, document whether amounts are inclusive or exclusive of GST, whether they are in Indian rupees, and whether they represent invoices, payments, refunds or donations. Do not merge these concepts into one “value” field.

4. Find and Resolve Duplicate Records

Duplicate removal is one of the most important parts of a CRM data cleanup checklist before migration. Duplicate records can lead to repeated calls, fragmented histories, incorrect customer counts and duplicate marketing messages.

Use matching rules

Begin with high-confidence matching rules:

• Exact email address
• Exact phone number after formatting
• Existing customer or donor ID
• GSTIN, where relevant and lawfully collected
• Combination of name and organisation
• Combination of name, phone and city

Avoid merging records only because the names look similar. “Amit Kumar” may refer to many different people.

A practical process is:

1. Run automated matching using email, phone and known IDs.
2. Review probable matches manually.
3. Separate certain duplicates from possible duplicates.
4. Assign a surviving or master record.
5. Preserve useful information from the records being merged.
6. Record the merge decision.

Choose the surviving record

When two records are duplicates, decide which record becomes the master. Factors may include:

• More recent verified contact details
• More complete organisation or address information
• Active transactions or open cases
• Correct consent and communication status
• Better linked history
• A recognised customer, donor or student ID

Do not simply keep the newest record. An older record may contain important transaction history or consent information.

Preserve related information

Before merging, check whether the duplicate records have:

• Deals or opportunities
• Orders or invoices
• Donations
• Support tickets
• Appointments
• Notes and tasks
• Email or campaign activity
• Consent or opt-out history
• Family, student or organisation relationships

The migration plan should explain how this information will be attached to the surviving record. A basic contact import may not carry over all related objects automatically.

Avoid over-merging

Some people share a phone number or email address. Family members may use one number, and small businesses may use a common accounts@ address. A school may have one parent contact shared across multiple students.

Do not merge records solely because they share a contact detail. Use relationships such as parent-child, household, company contact or branch contact where the new CRM supports them.

5. Review Field Quality, Completeness and Relevance

A clean database is not necessarily a database with every field filled. It is a database where the important fields are accurate, meaningful and used consistently.

Classify fields by importance

Separate fields into:

• Mandatory for operations
• Needed for reporting
• Needed for integrations
• Useful but optional
• Historical only
• Sensitive or restricted
• No longer required

For an NGO, donor name, donation date, amount, receipt status and communication preference may matter more than a detailed sales pipeline. For a clinic, appointment information may be relevant, while sensitive medical details may need a separate system with tighter controls.

Remove obsolete fields

Old CRMs often contain fields created for temporary campaigns or previous staff workflows. Examples include:

• “Lead source old”
• “Follow-up status 2”
• “Customer type new”
• “Temporary category”
• “Import batch”
• “Old region”
• “Do not use”

Do not migrate these fields by default. If they contain historical value, rename and document them. Otherwise, archive them according to your retention policy.

Review picklists and statuses

Free-text fields create inconsistent reporting. Replace values such as:

• Interested
• interested
• Hot lead
• Very interested
• Call back
• Call later
• Follow-up pending

with a defined set of statuses and separate fields where necessary. For example, lead stage, next action and next action date should not be combined into one text field.

Create a data dictionary containing:

• Field name
• Business meaning
• Data type
• Allowed values
• Mandatory or optional status
• Owner
• Destination field
• Transformation rule

This dictionary is useful during migration and when training staff.

Check missing and suspicious values

Review records with:

• No name or organisation
• No usable contact method
• Invalid email
• Invalid phone number
• Duplicate identifiers
• Missing source
• Impossible dates
• Negative or unexplained amounts
• Unrecognised status values
• Placeholder text such as “NA”, “test”, “-” or “unknown”

Do not automatically delete records with missing fields. A donor may have a valid transaction but no email, and a lead may be valuable even when its phone number is absent. Classify records according to their business use.

6. Protect Personal Data and Control Access

CRM migration involves personal information. In India, organisations should consider the Digital Personal Data Protection Act, 2023 and applicable rules, along with sector-specific obligations and contractual requirements. Legal compliance depends on the organisation, data type, processing purpose and current regulatory position, so obtain appropriate professional advice where necessary.

Collect and migrate only what is needed

Before transferring a field, ask:

• What purpose does this field serve?
• Is the purpose still valid?
• Does the new CRM need the field?
• Who should be able to see it?
• Is the field sensitive or confidential?
• Is it required for a legal, accounting or operational reason?

Avoid moving sensitive information into a general CRM merely because the export contains it. This is especially important for clinics, schools, NGOs working with vulnerable groups and organisations handling identity or financial information.

Review consent and communication preferences

Maintain clear fields for:

• Email marketing permission
• SMS or WhatsApp communication preference
• Phone contact preference
• Opt-out or unsubscribe status
• Source of consent
• Date or context of consent, where available

An old contact list is not automatically a permission to send promotional messages. Marketing communications should be handled according to applicable laws, platform rules and the organisation’s own consent records.

If a person has opted out, ensure that the migration does not reset the status. Test that the new CRM and connected email or WhatsApp tools respect those preferences.

Secure exports and temporary files

CRM exports are often CSV or Excel files containing personal data. Protect them by:

• Restricting access to the migration team
• Using approved storage instead of personal email accounts
• Avoiding unsecured USB drives
• Applying strong passwords where supported
• Removing temporary files after verification
• Recording who received the files
• Confirming deletion with external vendors where appropriate

Take a backup before cleanup, but do not treat an unprotected backup as a permanent archive. Keep an untouched source backup separately from the working cleanup file.

Plan access in the new CRM

Use role-based access where available. Sales staff may not need access to donor banking information, clinic notes or school records. An agency may need client-level separation so one client’s data cannot be viewed by another project team.

Define who can:

• View records
• Edit records
• Export data
• Delete records
• Access sensitive fields
• Change consent status
• Merge duplicates
• Configure integrations

7. Map, Transform and Test the Migration

Once the source data has been cleaned, map it to the destination CRM. Mapping is the point where business meaning is translated into the new system.

Create a source-to-destination map

A mapping document should show:

Some fields should not be mapped directly. A source field called “Status” may need to become several destination fields, such as lifecycle stage, lead status and follow-up outcome.

Prepare the import file

Before import:

• Remove formula errors
• Convert formulas to values where required
• Use one row per record
• Separate multiple values into supported fields
• Remove blank columns
• Keep headers consistent
• Use the destination CRM’s accepted date and picklist formats
• Preserve record IDs where the system supports them
• Mark records that need review

Do not use Excel formatting as evidence that data is structured. Colours, merged cells and comments often disappear during CSV export.

Run a small test import

Import a limited sample before moving the full database. Include different record types:

• A complete contact
• A duplicate candidate
• A record with missing phone
• An organisation with several contacts
• A record with an address
• A customer with transaction history
• A contact who has opted out
• A record with special characters in the name

Check the results inside the new CRM, not only in the import report.

Verify:

• Names and phone numbers
• Dates and amounts
• Relationships
• Notes and activities
• Ownership assignment
• Consent status
• Custom fields
• Search and filtering
• Reports
• Email, SMS, WhatsApp or payment integrations

Validate counts and samples

After the test import, compare source and destination counts. Counts alone are not enough, because one source record may generate several related records or some records may be intentionally excluded.

Use both:

• Reconciliation checks, such as number of contacts, deals, donations or orders
• Manual sample checks across important categories

Ask business users to test real workflows. A sales person should create a follow-up, a finance user should review transaction details, and an NGO programme manager should find a donor and view the permitted history.

8. Plan Cutover and Post-Migration Monitoring

A migration is not complete when the import button finishes. The organisation needs a controlled cutover and a period of monitoring.

Freeze or control changes

If staff continue editing the old CRM while the migration is running, the two systems may disagree. Decide whether to:

• Freeze updates temporarily
• Export a final delta after the main migration
• Use a defined cut-off time
• Record urgent changes manually
• Keep the old system read-only for a short period

Inform staff in advance. State where new leads, enquiries, donations or appointments should be recorded during the transition.

Keep a rollback plan

Before final migration, confirm:

• The original data backup is available
• The destination can be restored or cleared safely
• The import files are versioned
• The migration log is complete
• The team knows how to report errors
• The old system will not be deleted immediately

Do not shut down the old CRM on the same day without confirming that critical history, reports and integrations work in the new system.

Monitor after go-live

For the first period after migration, review:

• Duplicate creation
• Failed integrations
• Missing task assignments
• Incorrect notifications
• Broken reports
• Unsubscribed contacts receiving messages
• Unusual changes in lead or customer counts
• User-created inconsistent values
• Import errors that were not visible in the initial report

Create a correction process. Staff should know whether to edit a record themselves, report an issue to an administrator or add a note rather than changing a controlled field.

Establish ongoing data hygiene

Data cleanup should become a routine, not a one-time project. Set a practical schedule for:

• Duplicate review
• Invalid email and phone checks
• Inactive lead review
• Consent and unsubscribe reconciliation
• Unassigned record checks
• Picklist review
• Access review
• Backup and export review

Train staff on simple rules: do not create a new contact before searching, do not put important information only in free-text notes, and do not share CRM exports casually.

Common Mistakes to Avoid During CRM Data Cleanup

Several shortcuts create problems later.

Migrating all historical data without a purpose

Large volumes of old data can make search, reporting and user adoption worse. Move what supports current operations, reporting, compliance or a defined historical requirement.

Treating blank fields as errors

A missing optional field is not necessarily poor data. Focus on the fields that affect the organisation’s workflows and decisions.

Merging based only on names

Names are not unique identifiers. Use phone, email, customer ID, organisation and transaction context before merging.

Changing data without a record of the change

Keep the original export, working version and transformation notes. This makes it possible to investigate an incorrect merge or mapping decision.

Ignoring related records

Contacts without their deals, donations, orders, cases or appointments may look clean but provide an incomplete customer history.

Forgetting communication permissions

A CRM migration must preserve opt-outs and consent-related information. Treat these fields as operationally important, not as optional marketing notes.

Letting every user create custom fields

After migration, uncontrolled customisation can recreate the same data-quality problems. Approve new fields only when there is a clear business use and an owner.

Frequently Asked Questions

What is CRM data cleanup before migration?

CRM data cleanup is the process of reviewing, correcting, standardising, deduplicating and classifying records before importing them into a new CRM. It includes customer details, company records, transactions, activities, consent information and related history.

Should we migrate every record from the old CRM?

No. Decide what should be active, archived, retained separately or deleted based on business value, legal or accounting requirements, consent and data-minimisation principles. Migrating every record can transfer errors and make the new CRM harder to manage.

How do we identify duplicate customer records?

Start with reliable matching fields such as email, standardised phone number, customer ID or GSTIN where relevant. Then review possible matches using name, organisation, location and transaction history; do not merge records based only on similar names.

Should phone numbers be stored with the Indian country code?

Use one consistent format supported by the destination CRM, commonly an international format with India’s country code. Review landlines, shared numbers, multiple numbers and unverified WhatsApp details separately rather than assuming every mobile number has the same communication permission.

How long does CRM data cleanup take?

The effort depends on the number of records, number of data sources, level of duplication, quality of historical data, number of integrations and how much manual review is required. A small, well-maintained database may need limited preparation, while several years of spreadsheets and disconnected tools require more analysis and testing.

Can a CRM migration team clean the data for us?

A migration team can usually help with exports, transformations, duplicate rules, field mapping, test imports and validation. Your staff still need to make business decisions about retention, consent, ownership, sensitive information and which records represent the same person or organisation.

Where to Start

Begin by listing every system and spreadsheet that contains customer or stakeholder information. Appoint data owners, create a field inventory, define the records and fields worth retaining, and make a backup before changing anything.

Next, standardise phone numbers, emails, names, addresses, dates and status values. Resolve high-confidence duplicates, document uncertain records, prepare a source-to-destination mapping and run a small test import before the full CRM migration.

If you need help reviewing your CRM migration checklist or planning the cleanup and import, talk to the Govindani Infotech team on WhatsApp; project requirements and pricing can be confirmed there.