Migrate from My Practice Now to HubSpot

My Practice Now client records map 1:1 to HubSpot Contacts. The primary contact's name, email, phone, and address fields map to HubSpot's standard contact properties. Each client must have at minimum an email address to create a HubSpot Contact; clients without email are flagged for manual review before migration.

Any custom fields stored on a Practice client record — lead_source, referral_code, client_rating, billing_tier — are recreated as HubSpot custom contact properties. Each property's type (text, number, date, picklist) is matched to the closest HubSpot field type. Picklist values are mapped value-by-value to maintain segmentation in HubSpot lists and workflows.

Practice appointments have no direct HubSpot equivalent — appointments become HubSpot Support Tickets. Ticket subject carries the appointment summary, ticket status maps from appointment status (confirmed/cancelled/no-show), and service_type is preserved as a custom picklist on the ticket. Practitioner assignment resolves to HubSpot Ticket owner by email match. Original appointment timestamps are preserved on custom datetime fields since HubSpot Tickets do not have native scheduling timestamps.

Practice invoice totals map to HubSpot Deal amounts — one invoice equals one Deal. Invoice number becomes the Deal name. Invoice status (paid/partial/unpaid/overdue) maps to a custom deal property (Invoice_Status__c) since HubSpot Deal stage does not inherently represent payment status. Overdue flag triggers an alert in the migration audit log for manual follow-up.

Services defined in Practice's catalog map to HubSpot Products. Service name, description, and unit price carry over directly. If a Practice service was used as a line item on a specific invoice, that association is preserved by attaching the Product to the corresponding Deal in HubSpot. Products with no historical usage still migrate so HubSpot's product library is populated for future deal-line-item use.

Practice payment records track partial payments, payment method, and date per invoice. Since HubSpot Deals do not store a payment ledger, payment history is preserved as a custom text area field on the Deal (Payment_History__c) formatted as 'Date | Amount | Method'. A separate Deal custom property (Amount_Paid__c) tracks the paid portion for reconciliation against the total Deal amount.

Notes attached to a Practice client record migrate as HubSpot Contact Engagements of type 'note' with the original create timestamp. Notes are appended to the contact's timeline. If a note contains a date reference or follow-up action, FlitStack flags it so it can be used as a manual trigger for a HubSpot follow-up task.

Documents stored on Practice client records or appointments are downloaded and re-uploaded to HubSpot Files. Each file is associated to the relevant Contact or Ticket record via HubSpot's file association model. File size limits apply — HubSpot supports files up to the limit set by your HubSpot subscription tier. Files without an associated contact or ticket are held in a 'Migrated Files' folder for manual association.

Practitioners and staff members in Practice are resolved to HubSpot Users by email address match. A complete staff list is exported first so HubSpot Admins can pre-create user accounts before the migration runs. Unmatched practitioners are flagged and assigned to the HubSpot admin user as a fallback — this is reviewed with the practice manager before migration commits.

Workflows, automations, appointment reminders, and invoice-triggered sequences from Practice cannot be imported into HubSpot. FlitStack exports the full workflow definitions — trigger types, conditions, and action sequences — as a JSON reference document. Your HubSpot admin or a FlitStack consultant uses this to rebuild equivalent workflows in HubSpot Workflows or Sequences after go-live.

Practice's client-facing portal settings (branding, intake forms, booking page configuration) are account-level settings with no HubSpot equivalent. These cannot be migrated. FlitStack documents the current portal configuration — form field names, branding settings, and booking page URL — as a reference so the Service Hub portal can be rebuilt to match.