Migrate from Nookal to HighLevel

Nookal patient records map directly to HighLevel Contacts. Name, email, phone, address, and date of birth transfer as standard Contact fields. We preserve the original Nookal patient ID in a Source_System_ID__c custom field for traceability, enabling reliable delta-run deduplication when syncing incremental changes after the initial migration. This ensures each patient record maintains its origin reference throughout the migration lifecycle.

Nookal appointments carry practitioner, service type, date/time, duration, and status. We create a HighLevel custom appointment object to store these fields, or surface them as tagged notes on the Contact record. Appointment status (attended, cancelled, no-show) maps to custom pick-list values.

Nookal practitioners are staff members who own appointments. Practitioner name and credentials map to a Practitioner_Name__c custom field on the Contact. If practitioners need HighLevel login access, we flag them for manual user creation since practitioner-to-User mapping requires destination-side account provisioning.

Nookal invoices containing amounts, status (paid, unpaid, overdue), and line items map to a HighLevel Opportunity representing each billing event. Invoice number is preserved as Custom_Invoice_Number__c for audit trails. Paid invoices map to Closed Won opportunity stages while outstanding balances map to the appropriate open pipeline stage, maintaining financial visibility in the CRM.

Nookal clinical/treatment notes contain sensitive health information. HighLevel has no clinical notes equivalent — we migrate treatment note content as a custom Clinical_Note__c long-text field on the Contact or in a custom Clinical_Note__c object, flagging it for review against HighLevel's data-handling policies.

Nookal allows custom fields on patient records. Each custom field requires a corresponding custom field in HighLevel — created during migration setup. Field type mapping: text to text, number to number, date to date, pick-list to pick-list with value-by-value mapping.

Multi-location Nookal practices store location data on appointments and practitioners. We migrate location as a Location__c custom field on Contact and apply a tag matching the location name. This dual approach ensures HighLevel workflows can filter records by branch using either the custom field for data segmentation or the tag for workflow routing and automation triggers across locations.

Nookal referral source tracking maps to a Referral_Source__c custom field on Contact, with the original value preserved for historical accuracy. HighLevel tags provide an alternative grouping mechanism if referral sources need campaign attribution and marketing analysis. This enables practices to track where new patients originated and attribute them to specific marketing campaigns or referral partners.

Nookal's Medicare and DVA claiming integration is Australian health-insurance specific with no HighLevel equivalent. Claim status history migrates as a custom Medicare_Claim_Status__c text field for record completeness, preserving provider numbers, claim IDs, and status history. However, the actual claiming workflow must be rebuilt through a separate Australian health claiming tool or manual process outside HighLevel's ecosystem.

Nookal's accounting software integrations (Xero, QuickBooks) are configuration-level links with no stored mapping data in Nookal. We preserve the integration name as an Accounting_Integration__c reference field for documentation purposes. The actual connection must be re-established directly in HighLevel's Stripe and payment processor integrations, or through Zapier/Make workflows connecting to your accounting software post-migration.