CRM migration
Field-level mapping, validation, and rollback between Core Practice and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Core Practice
Source
Freshsales
Destination
Compatibility
8 of 11
objects map 1:1 between Core Practice and Freshsales.
Complexity
BStandard
Timeline
48–72 hours
Overview
Core Practice stores dental practice data — patients, appointments, treatment records, billing, and multi-office locations — in a domain-specific schema built for clinical workflows. Freshsales organizes data around Leads, Contacts, Accounts, and Deals with a Contact Lifecycle Stage model and multi-pipeline deal management. FlitStack AI maps Core Practice patients to Freshsales Contacts, Core Practice appointments to Freshsales Appointments, and treatment/billing records to custom fields on Contact and Account objects. Multi-location dental practices map to Freshsales Accounts with location information in address fields. Freshsales has no clinical or treatment-management module — treatment plan data and clinical notes become custom fields for reference; they cannot drive Freshsales workflows since those must be rebuilt in Freshsales's automation tools. We use Core Practice's API to export records in sequence (patients first, then appointments, then treatments) and bulk-insert into Freshsales with lookup resolution by email match. A delta-pickup window captures any records created or modified during cutover.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Core Practice object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Core Practice
Patient
Freshsales
Contact
1:1Core Practice patients map directly to Freshsales Contacts. First name, last name, email, phone, and address fields transfer as-is. Patient status (active/inactive/recall) migrates to a custom pick-list field since Freshsales has no patient-status concept — the Contact Lifecycle Stage does not map directly to clinical status.
Core Practice
Patient
Freshsales
Account
many:1When a Core Practice patient is also a household or family billing account, we create a Freshsales Account (family/household name) and link the Contact records to it. Insurance subscriber information on the patient becomes custom fields on the Account for billing clarity.
Core Practice
Appointment
Freshsales
Appointment
1:1Core Practice appointments map to Freshsales Appointments with start time, end time, owner, and linked Contact preserved. Clinical metadata (provider name, operatory number, procedure codes) migrates as custom fields on the Appointment record since Freshsales Appointments lack clinical context fields.
Core Practice
Treatment Plan
Freshsales
Custom Field on Contact
1:1Core Practice treatment plans (procedures, diagnoses, notes) have no Freshsales equivalent. We migrate treatment plan summaries and procedure codes as long-text custom fields on the Contact record. Detailed clinical notes become attachments or custom fields per your specification — they cannot drive Freshsales automations.
Core Practice
Treatment Record
Freshsales
Custom Field on Contact
1:1Individual treatment records (date, procedure, provider, tooth number, notes) migrate as a series of custom fields on the Contact or as a JSON blob in a long-text field. Freshsales has no native treatment history object — clinical data is preserved for reference but cannot generate Freshsales reports by procedure type without custom reporting setup.
Core Practice
Billing Record / Ledger Entry
Freshsales
Deal
1:1Core Practice billing ledger entries (charges, payments, adjustments) are financial events. We map outstanding balances to Freshsales Deal amounts and payment history to custom fields on the Contact or linked Deal. A patient with an outstanding balance becomes a Deal record keyed to the Contact's Account.
Core Practice
Insurance Information
Freshsales
Custom Field on Contact / Account
many:1Primary and secondary insurance details (carrier, policy number, group number, subscriber) migrate as custom fields on both Contact and Account. Freshsales has no native insurance object — insurance data is preserved as reference fields but does not trigger Freshsales workflows.
Core Practice
Staff / Provider
Freshsales
User
1:1Core Practice staff records (dentists, hygienists, admin) map to Freshsales Users by email match. Provider type (dentist, hygienist, admin) becomes a custom pick-list field on the User record. Staff without Freshsales user accounts are flagged for admin to create accounts before migration or assigned to a fallback owner.
Core Practice
Recall / Re-care
Freshsales
Task
1:1Core Practice recall intervals (6-month hygiene, annual exam) generate Freshsales Tasks with due dates calculated from last appointment date plus recall interval. Recall type (hygiene, exam, perio) maps to Task subject. Open recalls become open Tasks; completed recalls become closed Tasks with completion date.
Core Practice
Practice Location
Freshsales
Account
1:manyCore Practice multi-location setups create separate Account records per location in Freshsales. Each location's patients link to their primary location Account via AccountId. Location address, phone, and operating hours migrate as Account fields. This enables territory management in Freshsales if you assign location-based Account teams.
Core Practice
Document / Attachment
Freshsales
File
1:1Core Practice file attachments (treatment consent forms, insurance cards, clinical images) re-upload to Freshsales Files linked to the corresponding Contact or Account record. File size limits apply — Freshsales supports file uploads up to 25MB per file. Inline images in notes are extracted and rehosted as individual files.
| Core Practice | Freshsales | Compatibility | |
|---|---|---|---|
| Patient | Contact1:1 | Fully supported | |
| Patient | Accountmany:1 | Fully supported | |
| Appointment | Appointment1:1 | Fully supported | |
| Treatment Plan | Custom Field on Contact1:1 | Fully supported | |
| Treatment Record | Custom Field on Contact1:1 | Fully supported | |
| Billing Record / Ledger Entry | Deal1:1 | Fully supported | |
| Insurance Information | Custom Field on Contact / Accountmany:1 | Fully supported | |
| Staff / Provider | User1:1 | Fully supported | |
| Recall / Re-care | Task1:1 | Fully supported | |
| Practice Location | Account1:many | Fully supported | |
| Document / Attachment | File1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Core Practice gotchas
No publicly documented public API for direct data extraction
Proprietary patient archiving logic can silently drop records
Appointment booking reliability is a documented weakness
Limited review volume limits migration confidence
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Extract Core Practice data in dependency order
FlitStack AI connects to Core Practice via API and exports records in sequence: patients first (to resolve Contact lookups), then appointments, then treatments, then billing records, then staff and locations. We preserve original create dates, last-modified dates, and owner assignments from Core Practice. Multi-location exports run per-location and are tagged with location identifiers for Freshsales Account assignment. This ensures referential integrity throughout the migration process.
Pre-map custom fields and value lists in Freshsales
Before data loads, FlitStack creates the custom fields required for dental-specific data: Patient_Status__c (pick-list), Treatment_History__c (long-text), Procedure_Codes__c (text), Operatory__c (text), Insurance_Carrier__c (text), Policy_Number__c (text), Recall_Type__c (pick-list), and others identified during the audit. We also create the Freshsales Accounts for each practice location if multi-location is detected. Your Freshsales admin reviews and approves the custom field setup plan before we proceed.
Match staff to Freshsales Users by email
Core Practice staff records are matched to Freshsales Users by email address. Provider type (dentist, hygienist) is stored as a custom pick-list on the User record. Staff without Freshsales user accounts are flagged before migration — your admin creates Freshsales accounts for them or assigns their records to a fallback owner. No contact or appointment lands without an OwnerId. This prevents orphaned records and maintains accountability across the migrated dataset.
Run sample migration with field-level diff
A representative sample (typically 200–500 records spanning patients, appointments, and treatments) migrates to Freshsales first. We generate a field-level diff showing every mapped field, its source value in Core Practice, and the resulting value in Freshsales. You verify patient status mapping, recall task generation, billing-to-Deal transformation, and location assignment before the full run commits. Sample approval is required before proceeding.
Full migration with delta-pickup and rollback audit
Full data load executes in dependency order — locations first (Accounts), then patients (Contacts), then appointments, then treatments and billing. A delta-pickup window (24–48 hours) captures any Core Practice records created or modified during the cutover window. FlitStack generates an audit log of every record inserted, updated, or skipped. One-click rollback reverts all changes if reconciliation fails. After rollback confirmation, your team can retry from the delta-pickup point.
Platform deep dives
Core Practice
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Core Practice and Freshsales.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Core Practice: Not publicly documented.
Data volume sensitivity
Core Practice doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Core Practice to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Core Practice to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Core Practice
Other ways to arrive at Freshsales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.