CRM migration
Field-level mapping, validation, and rollback between Nookal and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Nookal
Source
Freshsales
Destination
Compatibility
13 of 14
objects map 1:1 between Nookal and Freshsales.
Complexity
BStandard
Timeline
48–72 hours
Overview
Nookal organizes patient records, practitioner schedules, location data, invoices, and clinical notes in a per-practitioner model designed for Allied Health practices in Australia. Freshsales CRM uses a standard Lead-Contact-Account-Opportunity-Activity model with custom fields and custom modules for healthcare-specific data. We map Nookal client records to Freshsales Contacts and Accounts, practitioner assignments to Freshsales owner lookups (resolved by email match), location data to Account records, and invoices to custom fields on Deals with line items. Clinical notes, Medicare/PBS numbers, and treatment plans that have no standard Freshsales equivalent become custom fields — we define these in your Freshsales account before any data loads. We run migrations via Freshsales' REST API with rate-limit awareness (1,000 requests/hour on Growth tier, scaling to 5,000/hour on Forest) using a staged export-transform-load pipeline that handles field mapping, email-based duplicate detection, and timestamp preservation. Nookal workflows, automations, and Medicare claiming logic have no equivalent in Freshsales and must be rebuilt manually — we export workflow definitions as a reference document for your admin.
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 Nookal 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.
Nookal
Client
Freshsales
Contact
1:1Nookal client records map directly to Freshsales Contacts. Client first name, last name, email, phone, and address fields map to Freshsales Contact fields. Records without an email address require special handling — Freshsales Create Contact API requires a valid email, so FlitStack flags email-missing records before migration for manual resolution.
Nookal
Client
Freshsales
Account
many:1Nookal client business details (company name, industry, website) merge into a Freshsales Account record linked to the Contact via the AccountId lookup. If a Nookal client has no company affiliation, FlitStack attaches the Contact to a default 'Unassigned Account' record in Freshsales.
Nookal
Location
Freshsales
Account
1:1Nookal locations (clinics, practice sites) map 1:1 to Freshsales Account records. Location name becomes Account Name, and location address, phone, and email map to the corresponding Account fields. Each location-account retains its address as the primary billing or service address for appointments and invoices associated with that site.
Nookal
Practitioner
Freshsales
User / Owner
1:1Nookal practitioner records map to Freshsales Users by email address match. FlitStack resolves each practitioner email against Freshsales user accounts before migration — unmatched practitioners are flagged so they can be invited to Freshsales before the migration runs. Practitioner specialty and title map to custom fields on the User or Contact record.
Nookal
Appointment
Freshsales
Custom Module / Activity
1:1Nookal appointment records have no direct Freshsales equivalent because Freshsales is not a scheduling system. FlitStack creates a custom Appointments module in Freshsales with fields for appointment date, time, duration, practitioner (linked via Contact or User lookup), client (linked via Contact), location (linked via Account), appointment type, and status. If your Freshsales plan does not support custom modules, appointments migrate as custom fields on the Contact record with date, type, and practitioner encoded as text.
Nookal
Clinical Note
Freshsales
Custom Field / Note
1:1Nookal clinical notes, treatment plans, and assessment data store as custom text or long-text fields in Freshsales. FlitStack creates Treatment_Plan__c and Clinical_Notes__c custom fields on the Contact object. Large clinical documents may be attached as Files linked to the Contact record. Note timestamps and practitioner author information are preserved in custom datetime fields.
Nookal
Invoice
Freshsales
Deal (custom fields)
1:1Nookal invoice records do not map to a standard Freshsales object because Freshsales has no native invoicing. Invoice amount, status (paid/unpaid/overdue), and date map to custom fields on a Freshsales Deal record — Invoice_Amount__c, Invoice_Status__c, Invoice_Date__c. Line items are stored as custom multi-select or text fields. Full invoice PDF files are attached to the Deal record as Salesforce Files equivalents.
Nookal
Payment
Freshsales
Custom Field / Note
1:1Nookal payment records (Medicare bulk-bill payments, patient payments, DVA claims) migrate as custom fields on the related Deal (for invoiced amounts) or as activity Notes attached to the Contact. Payment date, amount, payment method, and reference number are preserved. Payment history that spans multiple appointments is aggregated into a Payment_Summary__c text field on the Contact record.
Nookal
Medicare / DVA Claim
Freshsales
Custom Field
1:1Nookal Medicare and DVA claiming data has no Freshsales equivalent. Claim status, provider number, service type, and claim reference number migrate as custom fields on the Contact or Deal record. FlitStack creates Medicare_Provider_Number__c, DVA_Claim_Status__c, and Claim_Reference__c fields. Note that Medicare 2.0 claiming logic (deadline June 30, 2025) must be rebuilt as Freshsales workflows or handled through a dedicated Medicare-integrated tool.
Nookal
Custom Property
Freshsales
Custom Field
1:1Nookal custom properties on client, practitioner, or location records map to Freshsales custom fields on the corresponding object. FlitStack inspects Nookal's full property list and pre-creates matching custom fields in Freshsales (via API) before data loads. Field types are mapped: Nookal text to Freshsales text, Nookal date to Freshsales date, Nookal dropdown to Freshsales picklist with value-by-value mapping.
Nookal
Attachment / File
Freshsales
Files
1:1Nookal file attachments (clinical documents, referral letters, imaging files) linked to client records re-upload to Freshsales as Files attached to the Contact record. File size limits apply per Freshsales plan — FlitStack splits large file batches and retries failed uploads. Inline images in clinical notes are extracted and rehosted as separate file attachments.
Nookal
User / Staff
Freshsales
User
1:1Nookal staff records map to Freshsales Users for owner assignment. Active staff members are matched to Freshsales users by email. Nookal staff roles (admin, practitioner, receptionist) map to Freshsales roles and profiles, though sharing rules and permission sets must be configured manually in Freshsales after migration.
Nookal
Referral Source
Freshsales
Custom Field / Lead Source
1:1Nookal referral source data (referring practitioner, referral letter, external provider) migrates as a custom Referral_Source__c field on the Contact object. If referral data represents an external organization, it may map to a separate Account record linked via lookup relationship. Referral tracking workflows in Freshsales must be rebuilt manually.
Nookal
Waiting List
Freshsales
Custom Module / Deal
1:1Nookal waiting list entries do not have a direct Freshsales equivalent. FlitStack creates a Waiting_List__c custom module (or custom fields on the Contact) with fields for preferred appointment date, practitioner preference, service type, and waitlist status. As clients move off the waiting list into booked appointments, the status updates via Freshsales workflows that your admin rebuilds post-migration.
| Nookal | Freshsales | Compatibility | |
|---|---|---|---|
| Client | Contact1:1 | Fully supported | |
| Client | Accountmany:1 | Fully supported | |
| Location | Account1:1 | Fully supported | |
| Practitioner | User / Owner1:1 | Fully supported | |
| Appointment | Custom Module / Activity1:1 | Fully supported | |
| Clinical Note | Custom Field / Note1:1 | Fully supported | |
| Invoice | Deal (custom fields)1:1 | Fully supported | |
| Payment | Custom Field / Note1:1 | Fully supported | |
| Medicare / DVA Claim | Custom Field1:1 | Fully supported | |
| Custom Property | Custom Field1:1 | Fully supported | |
| Attachment / File | Files1:1 | Fully supported | |
| User / Staff | User1:1 | Fully supported | |
| Referral Source | Custom Field / Lead Source1:1 | Fully supported | |
| Waiting List | Custom Module / Deal1: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.
Nookal gotchas
Medicare 2.0 migration deadline is hard-gated
No public API forces reliance on built-in exports
Custom clinical note templates are account-specific
Medicare claiming groups tied to Provider Numbers restrict bulk migrations
Accounting sync does not export raw ledger data
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
Review Nookal data model and export capabilities
FlitStack reviews the full Nookal data model — client properties, practitioner records, location data, appointment structure, invoice history, and custom fields — to build a complete inventory before writing any migration logic. We assess which Nookal data is exportable via API versus those requiring manual export, identify records with missing required fields (notably email addresses, which Freshsales requires for Contact creation), and document the full list of custom properties that need Freshsales custom fields created in advance. This inventory drives the pre-migration checklist delivered to your admin before data moves.
Pre-create Freshsales custom fields for healthcare data
Before any data loads, FlitStack creates the custom fields in Freshsales that have no standard equivalent: Medicare_Number__c, DVA_Number__c, Treatment_Plan__c, Clinical_Notes__c, Invoice_Amount__c, Invoice_Status__c, Invoice_Date__c, Appointment_Date__c, Appointment_Type__c, and practitioner-to-owner lookup fields. For clients without an email address, we flag those records for manual email entry or alternate identification before the migration runs — Freshsales Create Contact API requires a valid email. This step ensures the Freshsales schema is ready before the first record loads.
Load core objects via Freshsales API with rate-limit awareness
FlitStack sequences the migration to satisfy Freshsales foreign-key requirements: Accounts first, then Contacts with owner lookups resolved by email match to Freshsales users, then custom objects and activities. We pace requests against your Freshsales plan API limits (1,000/hour on Growth, up to 5,000/hour on Forest) with automatic retry on HTTP 429 responses and exponential backoff. Large batch imports use Freshsales bulk import files where appropriate to reduce API call volume. All timestamps, owner assignments, and source system IDs are preserved at this stage.
Run a sample migration with field-level verification
A representative slice of records — typically 200–500 spanning clients, locations, practitioners, and appointments — migrates first. FlitStack generates a field-level diff report comparing source Nookal values against the destination Freshsales fields so you can verify Medicare number mapping, practitioner-to-owner resolution, appointment date preservation, and invoice-to-Deal field mapping before the full run commits. You approve the sample before we proceed to full migration.
Cut over with delta pickup for in-flight changes
The full migration runs against Freshsales. A delta-pickup window (typically 24–48 hours) captures any Nookal records created or modified during the cutover — appointments booked, client records updated, invoices issued. FlitStack uses scoped read access on Nookal so your team keeps working normally throughout. All migration operations are written to an audit log, and one-click rollback is available if reconciliation identifies missing or misaligned records after the migration completes.
Platform deep dives
Nookal
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 Nookal 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
Nookal: Not publicly documented.
Data volume sensitivity
Nookal 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 Nookal to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Nookal 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 Nookal
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.