Migrate from Badger Maps to Freshsales

Badger Maps accounts map directly to Freshsales Accounts. Account name, address components (street, city, state, postal code, country), phone, email, and domain all have direct equivalents. Accounts are migrated first so that related Contacts and Deals can reference them via their AccountId foreign key in Freshsales.

Badger Maps territory assignments (which rep owns which territory polygon) have no native equivalent in Freshsales. We preserve the territory name as a custom text field on the Account record (Territory_Name__c). Your Freshsales admin then creates matching territories in Territory Management and assigns accounts manually or via territory rules post-migration.

Badger Maps route data (multi-stop sequences with optimized order) has no direct Freshsales object. Route names and associated account lists are exported as a custom text field (Badger_Route_Reference__c) on each Account for rep reference. True route optimization must be handled by a third-party routing tool or Freshsales-compatible field-sales add-on post-migration.

Badger Maps contacts associated with accounts map directly to Freshsales Contacts. First name, last name, email, phone, mobile phone, and job title all have direct field equivalents. The contact's parent AccountId is resolved to the migrated Freshsales Account record. Badger Maps allows multiple accounts per contact; Freshsales supports Account Contact Relationships for the same.

Badger Maps leads map to Freshsales Leads using direct field mapping for name, email, phone, company, and source information. Lead status values are mapped value-by-value to Freshsales Lead Status pick-list options. Unqualified leads retain their original status; no automated lead scoring is applied during migration.

Badger Maps deals map to Freshsales Deals (opportunities). Deal name, amount, stage, expected close date, owner, and associated account all have direct equivalents. Stage values are mapped value-by-value to Freshsales Deal Stage pick-list options. Owner is resolved by email match against Freshsales users; unmatched owners are flagged for admin assignment before the migration commits.

Badger Maps check-in records (account name, visit timestamp, visit type, free-text notes) are exported via the Badger Maps API and transformed into Freshsales Tasks with Type = 'Check-in'. Original check-in timestamp, visit location, and rep owner are preserved on the Task record and linked to the corresponding Account. This keeps field activity visible in Freshsales activity feeds.

Badger Maps meeting records with start time, end time, associated account, and notes export as Freshsales Events. Subject is set to the account name with a 'Meeting' prefix. Original meeting duration and rep owner are preserved. Events are linked to the migrated Account record via the WhatId field.

Badger Maps custom fields (text and numeric types) map to Freshsales custom fields of the matching type. Numeric custom fields become Number-type custom fields on the Account object. Text custom fields become Text-type custom fields. Each custom field requires pre-creation in Freshsales before migration; we deliver a custom field creation checklist as part of the migration plan.

Badger Maps map filter fields like Priority, Specialty, or custom category filters are stored as account properties. These map to Freshsales custom picklist fields on Account with the same values. Value-by-value mapping is applied if the source pick-list values have a defined set; open-text filter values are migrated as text fields.

Badger Maps user records (reps and managers) are matched to Freshsales users by email address. The matched Freshsales User ID becomes the OwnerId on migrated Accounts, Contacts, Leads, and Deals. Users who exist in Badger Maps but have no corresponding Freshsales account are flagged before migration — your team invites them to Freshsales or assigns a fallback owner.

The Badger Maps internal record ID for each account and contact is stored in a custom field (Source_Badger_ID__c) on the Freshsales record. This enables delta-run de-duplication on repeat migrations, traceability back to the source system, and cross-referencing if a record needs to be reconciled against the original Badger Maps export.