Migrate your Bp Premier data
Server-based medical practice management software for Australasian GPs and specialists. Bp Premier manages patient records, clinical notes, appointments, and government health integrations entirely on-premise, making data extraction a manual, vendor-assisted process.
In its favor
Why people choose Bp Premier
The signal that keeps Bp Premier on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Bp Premier is purpose-built for Australasian healthcare regulation, natively supporting Medicare, DVA, My Health Record, eRx, and NASH certificates out of the box.
Practices value the low maintenance cost and ownership model, particularly the strong customer support reported across G2 reviews and user forums.
The software runs on-premise or on a dedicated server, giving practices direct control over their patient data storage and compliance posture.
Built-in clinical functionality for recording blood pressure, pulse, and other vitals within the patient record is well-regarded by GP workflows.
The Lyrebird Scribe AI integration for automated clinical note generation is a draw for practices seeking to reduce administrative burden.
The Windows server-based architecture requires dedicated IT infrastructure and manual patching, which smaller practices find burdensome compared to cloud-native alternatives.
Known issues in certain Bp Premier versions, including MySL date-created quirks and callstack alerts, cause frustration when support cannot resolve them quickly.
No publicly documented REST API limits external integrations, making Bp Premier difficult to connect with modern healthcare analytics, patient portals, or automated workflows.
Transitioning between Bp Premier versions (e.g., moving to Orchid) requires a full reinstall and data migration, creating significant downtime risk for practices.
Practices migrating to cloud-first platforms like Epic or ModMed report that the absence of a modern API makes automated data portability difficult and vendor-dependent.
Reasons to switch
Why people leave Bp Premier
The recurring reasons buyers give for replacing Bp Premier. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Bp Premier fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Bp Premier pricing overview
Bp Premier pricing is not publicly disclosed and is negotiated directly with Best Practice Software on a per-practice basis. Licensing is typically per practice or per provider, with annual support contracts required. Practices should budget separately for server infrastructure, IT support, and integration setup costs, which are not included in the software license.
Bp Premier (Legacy)
Tier 1 of 3
Not publicly listed
What's included
Need help selecting your CRM?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Bp Premier's schedule — see our quote-based pricing →
What gets migrated
Bp Premier object support
Object-by-object support for Bp Premier migrations. Per-pair details surface during scoping.
Patients
Fully supportedBp Premier supports full patient record exports via Utilities > Export Patient Records, covering demographics, addresses, emergency contacts, and Medicare/DVA details. We map these fields 1:1 and flag any inactive or deceased flags that need downstream attention.
Encounters (Consultations)
Fully supportedEach consultation is stored as a clinical encounter with date, provider, type (in-rooms, home, phone), and free-text notes. We extract encounter records and preserve the encounter-to-provider relationship via HPI-I linkage.
Clinical Notes
Mapping requiredClinical notes are stored as formatted text or rich-content blocks. We extract the raw note content and body text; layout and embedded objects may require post-migration formatting review depending on the destination system.
Prescriptions (MySL)
Mapping requiredThe MySL subsystem stores prescription history with a known date-created quirk: new prescriptions record the prescribing date, while modified prescriptions record the edit date. We flag this discrepancy and log the extraction context so the destination system can interpret prescription timelines accurately.
Appointments
Mapping requiredAppointment Book data includes date, time, duration, provider, appointment type, and status. Historical appointments export cleanly; future recurring appointments may need to be rescheduled on the destination platform if the migration occurs before their date.
Providers (Users)
Fully supportedEach provider is identified by their HPI-I (Healthcare Provider Identifier – Individual) and linked to their AHPRA registration. We preserve the provider record and their assignment to appointments and encounters.
Organisations (Practice)
Fully supportedThe practice-level record includes the HPI-O (Healthcare Provider Identifier – Organisation), NASH certificate details, PRODA credentials, and My Health Record registration status. These are essential for re-registering integrations on the destination system.
Documents and Attachments
Mapping requiredUploaded documents (letters, images, referral letters) are stored in a file-store area. We extract and transfer the file store separately, then re-link documents to the corresponding patient record on the destination. File naming conventions and linking metadata must be verified post-migration.
Billing and Medicare Claims
Mapping requiredBilling records include item numbers, patient payments, Medicare/DVA rebates, and outstanding balances. We extract the financial ledger as a transactional record; outstanding balances and credit card payment data require explicit re-entry or reconciliation on the destination platform.
My Health Record Uploads
Not in this platformDocuments uploaded to My Health Record are immutable once submitted and cannot be re-extracted for re-submission to a new system. We document which records were uploaded so the destination system can record the upload reference and avoid duplicate submissions.
eRx Dispense Records
Mapping requiredElectronic prescriptions dispensed via eRx are tracked in Bp Premier. We extract the dispense history; the destination system must be eRx-enabled to continue the prescription continuity chain.
Custom Letter Templates
Mapping requiredPractices commonly create custom letter templates with merge fields. We extract the template body and field definitions; the destination system's template engine may use different merge field syntax and requires manual re-authoring.
Third-Party Integrations (Lyrebird Scribe)
Not in this platformAI scribe notes generated via the Lyrebird Scribe integration are written back into the clinical note at the time of the encounter. We capture the note content itself during encounter extraction but cannot transfer the Lyrebird integration configuration, which must be re-connected on the destination system independently.
Insurance Claims
Mapping requiredInsurance claim records include carrier details, policy numbers, claim status, and history. We extract claim headers and status; supporting documents and in-progress claims require review before the destination system assumes responsibility.
| Object | Support | Notes |
|---|---|---|
| Patients | Fully supported | Bp Premier supports full patient record exports via Utilities > Export Patient Records, covering demographics, addresses, emergency contacts, and Medicare/DVA details. We map these fields 1:1 and flag any inactive or deceased flags that need downstream attention. |
| Encounters (Consultations) | Fully supported | Each consultation is stored as a clinical encounter with date, provider, type (in-rooms, home, phone), and free-text notes. We extract encounter records and preserve the encounter-to-provider relationship via HPI-I linkage. |
| Clinical Notes | Mapping required | Clinical notes are stored as formatted text or rich-content blocks. We extract the raw note content and body text; layout and embedded objects may require post-migration formatting review depending on the destination system. |
| Prescriptions (MySL) | Mapping required | The MySL subsystem stores prescription history with a known date-created quirk: new prescriptions record the prescribing date, while modified prescriptions record the edit date. We flag this discrepancy and log the extraction context so the destination system can interpret prescription timelines accurately. |
| Appointments | Mapping required | Appointment Book data includes date, time, duration, provider, appointment type, and status. Historical appointments export cleanly; future recurring appointments may need to be rescheduled on the destination platform if the migration occurs before their date. |
| Providers (Users) | Fully supported | Each provider is identified by their HPI-I (Healthcare Provider Identifier – Individual) and linked to their AHPRA registration. We preserve the provider record and their assignment to appointments and encounters. |
| Organisations (Practice) | Fully supported | The practice-level record includes the HPI-O (Healthcare Provider Identifier – Organisation), NASH certificate details, PRODA credentials, and My Health Record registration status. These are essential for re-registering integrations on the destination system. |
| Documents and Attachments | Mapping required | Uploaded documents (letters, images, referral letters) are stored in a file-store area. We extract and transfer the file store separately, then re-link documents to the corresponding patient record on the destination. File naming conventions and linking metadata must be verified post-migration. |
| Billing and Medicare Claims | Mapping required | Billing records include item numbers, patient payments, Medicare/DVA rebates, and outstanding balances. We extract the financial ledger as a transactional record; outstanding balances and credit card payment data require explicit re-entry or reconciliation on the destination platform. |
| My Health Record Uploads | Not in this platform | Documents uploaded to My Health Record are immutable once submitted and cannot be re-extracted for re-submission to a new system. We document which records were uploaded so the destination system can record the upload reference and avoid duplicate submissions. |
| eRx Dispense Records | Mapping required | Electronic prescriptions dispensed via eRx are tracked in Bp Premier. We extract the dispense history; the destination system must be eRx-enabled to continue the prescription continuity chain. |
| Custom Letter Templates | Mapping required | Practices commonly create custom letter templates with merge fields. We extract the template body and field definitions; the destination system's template engine may use different merge field syntax and requires manual re-authoring. |
| Third-Party Integrations (Lyrebird Scribe) | Not in this platform | AI scribe notes generated via the Lyrebird Scribe integration are written back into the clinical note at the time of the encounter. We capture the note content itself during encounter extraction but cannot transfer the Lyrebird integration configuration, which must be re-connected on the destination system independently. |
| Insurance Claims | Mapping required | Insurance claim records include carrier details, policy numbers, claim status, and history. We extract claim headers and status; supporting documents and in-progress claims require review before the destination system assumes responsibility. |
Gotchas
What to watch for in Bp Premier migrations
Issues we've hit on past Bp Premier migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
MySL prescription date-created has inconsistent behavior
My Health Record uploads are immutable and non-extractable
No REST API — migration relies entirely on export tools
Server-to-server migration requires full reinstall
Legacy version data format differences
| Severity | Issue |
|---|---|
| High | MySL prescription date-created has inconsistent behavior |
| High | My Health Record uploads are immutable and non-extractable |
| High | No REST API — migration relies entirely on export tools |
| Medium | Server-to-server migration requires full reinstall |
| Low | Legacy version data format differences |
Leaving Bp Premier?
Where Bp Premier customers move next
12 destinations Bp Premier can migrate to.
How a Bp Premier migration works
Four steps, Bp Premier-specific
Connect
API key (not publicly documented) into Bp Premier. Scopes limited to read-only on the data we move.
Map
We translate Bp Premier-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Bp Premier quirks before production.
Migrate
Full migration with Bp Premier rate-limit handling. Rollback available throughout.
FAQ
Bp Premier migration FAQ
Answers to the questions buyers ask most during Bp Premier migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Bp Premier migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationReady when you are
Migrate Bp Premier.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Bp Premier setup and destination — written quote back within a business day.