How to Use Claude to Map Fields and Plan Data Cleanup Before a HubSpot Migration

Export your legacy CRM schema, picklist values, record counts and a small anonymized sample. Then prompt Claude in steps: first a draft field map (object, property, type and transformation for each field), then a cleanup rule list ranked by records affected and risk. Your migration team validates every row by hand, deciding objects, property types, owners and deletions, before anything reaches the HubSpot import.

Key takeaways

• Give Claude a schema export, picklist values with counts, record counts and a small anonymized sample, never real customer records.
• Use XML tags, fixed columns and one example row so Claude returns a field map with object, property, type and transformation for every field.
• Rank cleanup rules by records affected and risk, starting with emails and website domains, because HubSpot deduplicates contacts by email and companies by domain.
• Claude drafts; your team decides object choice, property types, owners and deletions, and a named reviewer signs off each row before import.
• Under PIPEDA your company stays accountable for personal information it sends to a processor, so keep personal data out of prompts and confirm US state law with counsel.

What should you give Claude, and what should you never paste in?

Give Claude the structure of your data, not the data itself: a schema export, picklist values with counts, record counts and a small anonymized sample. Never paste real names, emails, phone numbers, notes or deal details.

Digitalegy is a HubSpot partner. The prep below works whether you are leaving Salesforce, Zoho, Pipedrive or spreadsheets. If you are still weighing the wider steps of a project, read Things You Should Know Before Implementing HubSpot first.

A schema export is a list of every field in your legacy CRM with its object, label, API name and data type. A field map is the table that says where each legacy field lands in HubSpot and how its values change on the way. Give Claude four inputs:

• Schema export: object, label, API name, data type and required flag for every field you might migrate.
• Picklist values with counts: each value and how many records use it. HubSpot's guide to property field types states that "The maximum size of the property is 512,000 bytes, or 5,000 options, whichever is reached first," so counts show early which picklists need work.
• Record counts and fill rates: totals per object and the share of records where each field is not empty.
• An anonymized sample: 20 to 50 rows per object, with names, emails, phones and free text swapped for placeholders such as contact_0001@example.com.

Never paste real contact names, email addresses, phone numbers, notes, email bodies or deal details tied to a named customer. Anthropic's privacy center page on model training says: "And we encourage our users not to use our products and services to process personal data." A field map needs the structure of your CRM, not the people in it.

Which prompts turn a legacy schema into a draft HubSpot field map?

Run a short sequence: one prompt that limits Claude to your files, one that drafts the field map with fixed columns and an example row, and one that traces every row back to your schema.

Anthropic's prompting best practices note that "Claude responds well to clear, explicit instructions" and that "Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure." The same guide says XML tags help Claude parse prompts that mix instructions, context, examples and variable inputs, so wrap your files in <schema>, <counts> and <sample> tags. Its guide to reducing hallucinations adds two habits: let Claude admit uncertainty, and tell it to use only the documents you provide.

Worked example: Harbor Valve Supply (fictional)

Harbor Valve Supply is an invented distributor. Its legacy CRM holds 18,400 contacts, 3,100 accounts and 2,250 opportunities, with 15 fields in scope. Every count here is fictional.

Prompt 1: context and limits

You are helping plan a CRM migration to HubSpot. Use only the information inside the <schema>, <counts> and <sample> tags, not your general knowledge. If you are not sure what a field is for, write UNSURE and say what you would need to know. Never add a field that is not in <schema>.

Prompt 2: draft field map

For every field in <schema>, return one table row with these columns: legacy field, HubSpot object (contact, company, deal or activity), HubSpot property (a default property if one fits, otherwise a proposed custom property), property type, transformation rule, confidence (high, medium or low) and open question. Example row: Contact.Email | Contact | Email | default | trim spaces, lowercase | high | none. Flag any picklist with more than 5,000 values and any field empty in more than 80 percent of records.

The 5,000 threshold mirrors the option limit in HubSpot's property field type guide. After a first review pass, the draft looked like this:

Prompt 3: trace-back check

For each row in your field map, quote the line of <schema> it came from. Delete any row you cannot trace and list what you deleted.

Then run Prompt 2 again in a new chat and compare the tables. As the hallucination guide puts it, "Inconsistencies across outputs could indicate hallucinations."

How do you get Claude to rank data cleanup rules by impact?

Ask Claude for cleanup rules with the records each one touches and the risk if skipped, ranked by impact. Any rule that deletes or merges data goes to the team, never straight from the draft.

Prompt 4: ranked cleanup rules

Using <schema>, <counts> and <sample>, propose cleanup rules for duplicates, formatting, picklist consolidation and empty or unused fields. For each rule, give the fields affected, the records it touches, the risk if skipped (high, medium or low) and whether it must happen before import. Rank by records affected and risk. Label any rule that deletes or merges data TEAM DECISION.

Start with identifiers. HubSpot's deduplication article explains that "HubSpot automatically deduplicates contacts using email addresses, and companies using domain names," and that when a contact with the same email exists, "the imported information will update the existing contact rather than create a new one." Messy emails and websites can lead to unexpected updates or missed matches. The ranked list for the fictional example:

1. Merge duplicate emails: 640 contacts (3.5 percent of 18,400) once case and spaces are fixed. Risk high. TEAM DECISION on the surviving record.
2. Decide on contacts without email: 1,150 contacts that email matching cannot catch. Risk high. TEAM DECISION: import, enrich or archive.
3. Reduce websites to root domains: 410 of 3,100 accounts. Risk high for company matching.
4. Map 11 stages to 7: 2,250 opportunities, 186 open in retired stages. Risk high for forecasts. TEAM DECISION for the 186.
5. Consolidate lead source from 23 to 8 values. Risk medium for attribution.
6. Consolidate industry from 41 values. Risk medium.
7. Convert revenue and amount text to numbers with a currency. Risk medium.
8. Standardize close dates. Risk low once converted.
9. Leave Fax behind (97 percent empty). Risk low. TEAM DECISION because it removes data.

Both picklists end far below the 5,000-option cap in HubSpot's field type guide; the reason to consolidate is clean reporting. To keep records clean after go-live, read How to Improve Data Quality in RevOps with HubSpot's AI Tools.

Which migration decisions must your team validate by hand?

Claude drafts every row; your team decides object choice, property types, owners and deletions. A named reviewer checks each row against HubSpot's default objects and properties and signs it off before import.

Treat the validation status column as a contract: Claude proposes, and only a named person marks a row Accepted. For a refresher on how HubSpot organizes records before you choose target objects, open An Overview of the HubSpot Data Model.

HubSpot's import tool article notes that "Mapping correctly ensures that your data goes to the right place (i.e. the correct object and the correct property) when added to HubSpot." Sign off each row against this checklist:

1. Traceable: the field appears in the schema export and in the Prompt 3 output.
2. Object: the target object matches how your teams use the data.
3. Default first: no default HubSpot property already covers the field.
4. Type: the type fits what the field stores. HubSpot's field type guide says only certain field types can have their type or options edited after creation, so settle types before import.
5. Size: dropdown, checkbox and radio select properties stay within 512,000 bytes or 5,000 options, whichever is reached first.
6. Identifiers: contacts match on Email and companies on Company domain name, the identifiers HubSpot recommends for imports.
7. Owners: every legacy user maps to an active HubSpot user or a named fallback.
8. Deletions: every Do not migrate row has an archive location and an approver.
9. Sign-off: reviewer name, date and final status recorded on the row.

How long does Claude-assisted prep take, and what does it cost?

In a fictional planning estimate for a 200-field schema, the Claude-assisted method cuts prep time by about 40 percent, almost all of it in drafting. Tool cost is the Claude plan your company uses; check that it is a commercial plan whose terms cover this work. The main cost is reviewer time.

The figures below are a planning estimate for a fictional schema, not measured results. Replace each assumption with your own.

The saving is 18.3 hours, about 40 percent. Review time does not shrink, and it should not: that is where decisions happen.

Check the terms and price of the Claude plan your company uses. The larger cost is people: a RevOps lead or CRM admin who owns the map, a sales operations lead for stages and owners, a marketing operations lead for lead source fields, and the person accountable for privacy.

If your legacy CRM is on HubSpot's supported list and you load data with HubSpot Smart Transfer, which HubSpot says "is designed for a one-time migration of data from another app to HubSpot," your validated map answers the questions its mapping steps ask.

What are the risks, and how do you control them?

The main risks are invented fields, wrong property types, personal data in prompts and lost activity history. Each has a specific control: trace-back, type review, anonymization and an activity plan.

Anthropic's hallucination guide is direct about the limits of any prompt technique:

"Remember, although these techniques significantly reduce hallucinations, they don’t eliminate them entirely. Always validate critical information, especially for high-stakes decisions." (Reduce hallucinations)

• Hallucinated fields: Claude invents a field or property. Control: Prompt 1 limits, Prompt 3 trace-back and a second run of Prompt 2.
• Wrong property types: revenue stored as text breaks number reports and filters. Control: review every type before import.
• Data privacy: real records end up in a chat. Control: anonymized samples only, and know your plan's terms. For commercial Claude for Work accounts (Team or Enterprise plans), Anthropic's page on processor and controller roles says Anthropic acts as a processor on behalf of the customer and processes data only as the customer instructs, to provide the Claude service.
• Lost history: calls, emails and notes stay behind because nobody mapped them. Control: list activity types in your export. HubSpot's import tool article says supported activities include calls, emails, meetings, notes and tasks. Decide which you bring and which records they attach to.

How do PIPEDA and US state privacy laws affect what you share with Claude?

In Canada, PIPEDA keeps your company accountable for personal information it sends to any processor, so the safe default is to keep personal data out of Claude. For US records, confirm the applicable state laws with counsel; the anonymized method works in both countries.

The Office of the Privacy Commissioner of Canada lists PIPEDA's fair information principles. Those relevant to a migration include:

• Accountability: "An organization is responsible for personal information under its control. It must appoint someone to be accountable for its compliance with these fair information principles."
• Limiting collection: "The collection of personal information must be limited to that which is needed for the purposes identified by the organization."
• Accuracy: "Personal information must be as accurate, complete, and up-to-date as possible in order to properly satisfy the purposes for which it is to be used."
• Safeguards: "Personal information must be protected by appropriate security relative to the sensitivity of the information."

The OPC's guidelines for processing personal data across borders (dated 2009) state that "PIPEDA does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing" and that "The transferring organization is accountable for the information in the hands of the organization to which it has been transferred." If you send personal information to a CRM or AI vendor for processing, your company stays accountable for it.

The anonymized-input method keeps the prep step from handling personal information at all. The accuracy principle also gives your cleanup rules a compliance reason, not only a reporting one. Confirm with counsel whether provincial laws add requirements.

For US records, the sources in this post do not describe a single federal law that plays the role PIPEDA plays in Canada, so start from your own data. Use the State field in your export to list which states your contacts live in, and bring that list to counsel. Ask which state laws apply to the people in your database and whether fields such as notes hold sensitive details. What you share with Claude stays the same in Toronto and Texas: structure and placeholders, never people.

When should you bring in an implementation team instead?

Bring in an implementation team when decisions outweigh drafting: custom objects, a live Salesforce sync during the move, heavy activity history, multiple currencies or no one with time to sign off every row.

• Your map needs custom objects or complex associations.
• You plan to keep Salesforce running during the move. HubSpot's Smart Transfer article warns that "Smart Transfer and the Salesforce integration use different unique identifiers to match records, so using both at the same time will create duplicate records in HubSpot and Salesforce."
• A legacy picklist nears the 5,000-option limit.
• Years of calls, emails and notes must stay attached to the right records.
• Records span currencies or business units that need separate pipelines.
• No one has time to sign off every row.

Digitalegy became a HubSpot Gold Partner in 2019, Platinum in 2023 and Diamond in 2024. Teams that want help with implementation, migration and custom integrations can start with HubSpot implementation from Digitalegy. Companies that want guided onboarding for their teams after the migration can start with HubSpot onboarding.

Frequently asked questions

Should I use HubSpot Smart Transfer or the import tool?

Use Smart Transfer when your legacy app is on its supported list and you are doing a one-time migration; otherwise use the import tool. HubSpot describes Smart Transfer as designed for a one-time migration from another app, while the import tool maps spreadsheet columns to properties to create records, update existing ones and define relationships.

Will importing the same contact twice create a duplicate?

Not if the email matches. HubSpot's deduplication article says an import with an existing email updates that contact instead of creating a new one. Keep Email as the unique identifier column in every contact import file, as HubSpot's import tool article recommends for imports.

What if my legacy CRM is a set of spreadsheets?

Export each sheet's column headers as your schema and give Claude those, with counts and an anonymized sample. Then load the data with HubSpot's import tool, which maps spreadsheet columns to HubSpot properties.

Does Claude train on what I paste?

For Anthropic's commercial offerings, such as the Anthropic API and Claude for Work (Team and Enterprise plans), Anthropic's privacy center says it will not use your chats or coding sessions to train its models unless you opt into a specific program named on that page. Check which plan your company uses. Anonymize anyway.

Should I map fields from the full schema or only fields in active use?

Start from the full schema so nothing is missed, then let fill rates narrow it. In the worked example, Prompt 2 flags any field empty in more than 80 percent of records, and Fax (97 percent empty) became a Do not migrate row that the team approves with an archive location.

What should I do with Claude after go-live?

Use it on clean data. How to Use Claude to Review HubSpot Pipeline Data and Flag Forecast Risk Every Week sets up a weekly routine that flags slipped close dates, stalled deals and missing fields.

Sources

1. Understand property field types in HubSpot, HubSpot Knowledge Base (September 29, 2026)
2. How do you use personal data in model training?, Anthropic Privacy Center (March 16, 2026)
3. Prompting best practices, Anthropic (Claude Platform Docs)
4. Reduce hallucinations, Anthropic (Claude Platform Docs)
5. Deduplicate records in HubSpot, HubSpot Knowledge Base (October 2, 2026)
6. Understand the import tool, HubSpot Knowledge Base (March 6, 2026)
7. Transfer data from other apps using HubSpot Smart Transfer, HubSpot Knowledge Base (November 4, 2026)
8. Does Anthropic Act as a Data Processor or Controller?, Anthropic Privacy Center (October 30, 2026)
9. PIPEDA fair information principles, Office of the Privacy Commissioner of Canada (May 29, 2025)
10. Guidelines for processing personal data across borders, Office of the Privacy Commissioner of Canada (January 27, 2009)