Migrate from Bp Premier to Freshsales

Bp Premier patient model has no direct Freshsales equivalent — healthcare data requires custom field architecture

Bp Premier's core entity is the Patient record with clinical properties (Medicare number, allergies, blood type, AHPRA-linked providers) that have no native Freshsales counterpart. Freshsales Contact objects do not include a Medicare number field, an allergy flag, or a blood-type property by default. We create these as Freshsales custom fields on the Contact object before migration. However, Freshsales's custom field type restrictions (maximum 500 custom fields per object, pick-list value limits) mean some complex clinical data trees in Bp Premier may need to be flattened or stored as text blobs. The custom field creation plan is delivered before migration data lands so the Freshsales schema is ready at cutover.

Healthcare data (PHI) in a sales CRM creates compliance obligations that must be addressed before migration

Migrating Bp Premier patient records into Freshsales means Protected Health Information enters a platform designed for sales CRM use cases, not healthcare data storage. Freshsales does not offer HIPAA Business Associate Agreements by default, and the Freshworks data processing addendum may not cover Australian healthcare data under the My Health Record Act framework. We flag this in the migration plan and require customers to confirm their legal and compliance review before Bp Premier patient data is loaded into Freshsales. Practices may need to migrate only non-clinical contact data (name, email, phone) as Contacts and store clinical data in a separate compliant system.

Bp Premier clinical workflows and recall sequences do not map to Freshsales automation objects

Bp Premier recall workflows (appointment reminders, test-result alerts, immunization recalls, chronic disease management flags) run as internal PM sequences. Freshsales Workflows and Sales Sequences automate outbound sales engagement — email drip sequences, task creation, stage advancement, and lead scoring. These are fundamentally different automation models with no data-level translation. We export Bp Premier workflow definitions as a structured reference document that your team uses to rebuild the clinical recall logic in Freshsales Workflows (or a dedicated healthcare recall tool) after cutover. No workflow logic migrates automatically.

Bp Premier document attachments live in a separate file store that requires separate extraction

Bp Premier stores clinical attachments (referrals, imaging, consent forms, pathology reports) as linked files in a directory structure outside the main database. The patient record holds a reference pointer, not the file itself. Freshsales Files attach directly to Contact records via the CRM interface or API. We extract Bp Premier attachments from the file store, match them to the corresponding Contact by patient ID, and re-upload them to Freshsales. Large files (above Freshsales's attachment size limit) are linked externally or split. The file extraction step is sequenced after Contact migration so the target Contact ID is known before files are attached.

Appointment history in Bp Premier can be voluminous and may exceed Freshsales Task API rate limits during bulk load

Active healthcare practices积累 years of appointment history. A single practice with 10 years of appointment data can produce hundreds of thousands of Task records in Freshsales. Freshsales applies API rate limits per account tier (Growth: lower daily limits; Enterprise: higher). We paginate the appointment history load across off-peak hours, monitor Freshsales API response headers for 429 throttling, and backoff/retry automatically. Practices with over 200,000 historical appointments may need to load only the most recent 2–3 years of appointment data and archive older records to a CSV reference file to stay within rate-limit budgets.