Migrate from DGL Practice Manager to HubSpot

Clinical procedure logs have no native HubSpot home and require a custom object strategy

DGL stores clinical procedures, GP correspondence, dictation attachments, and operation notes inside the Electronic Patient Record. HubSpot's standard objects (Contact, Company, Deal, Ticket) carry relationship data, not clinical narrative. Migrating this data as raw Notes risks losing searchability and context. FlitStack AI creates a Clinical_Note__c custom object with fields for note type, procedure code, consultant owner, original date, and linked patient Contact. Your HubSpot admin decides whether to display Clinical_Note__c records on the contact timeline or surface them via a custom object list view. This step adds schema configuration time but preserves the full clinical history in a retrievable format.

DGL's per-invoice charging model has no HubSpot equivalent — billing workflows must be rebuilt

DGL Practice Manager charges practices per insurer invoice submitted. Reviewers report this fee structure is disclosed only at renewal and creates unexpected costs at scale. HubSpot's Deals carry no per-transaction billing logic — the invoice status, amount, shortfall, and submission history all need to be modelled as deal properties and pipeline stages. FlitStack AI maps DGL invoice records to Deals with status as stage and shortfall amount as a custom field, but the per-insurer submission workflow (EDI links, authorisation codes, claim跟踪) has no HubSpot equivalent and must be rebuilt either as a HubSpot workflow or through an integrated billing tool like HubSpot Payments or a third-party PM-integrated billing app.

Appointment diary structure flattens when imported as HubSpot Meetings

DGL's appointment diary supports multi-consultant LLPs with separate diaries per practitioner, appointment conflicts, and location-based scheduling. HubSpot Meetings store a single date, time, duration, and location per record. When multiple consultants share a clinic slot in DGL, FlitStack AI creates one Meeting per consultant-to-patient association rather than collapsing to a single record. This preserves individual diary ownership but requires your team to review the HubSpot calendar view to confirm no double-booking occurs at go-live.

DGL custom fields per patient require upfront HubSpot property creation

DGL allows practices to define custom fields on the patient record for insurance codes, GP references, clinical alerts, or referring-source tracking. HubSpot requires each custom property to be created before import — there is no dynamic field creation during migration. FlitStack AI audits your DGL export for all custom field definitions, maps data types to HubSpot equivalents (text, number, date, pick-list), and delivers a property creation checklist before the migration run. Practices with more than 30 custom fields per patient record fall into the upper pricing tier because property creation and validation multiply the planning work.

DGL's document template and letter-generation workflows do not transfer

DGL generates patient letters, appointment confirmations, and clinical reports using embedded Microsoft Word templates linked to the patient record. HubSpot has no native letter-generation engine — document creation would require either HubSpot's document generation feature (Sales Hub Enterprise) or an external integration like DocuSign or Mailshake. FlitStack AI exports your DGL template list and field mappings as a reference document so your HubSpot admin can rebuild letter workflows using HubSpot's native tools or a connected document app. This is a post-migration configuration task, not a migration deliverable.