Migrate from Bizstim Business Management Software to Twenty CRM

Bizstim Client records map directly to Twenty CRM Person records. We extract all standard contact fields including name, email, phone numbers, address, and any custom fields scoped to the client record. The Bizstim client status flag maps to Twenty's Person status field. Notes and free-text fields attached to the client record migrate as Twenty Files linked to the Person via the attachment relationship. Client records are imported first in the dependency order because they are referenced by practitioner_id on session records and by client_id on payment records.

Bizstim Practitioner records map to Twenty CRM Person objects with a practitioner role designation in a custom field or tag. The practitioner_id is preserved as an external identifier for relationship resolution during session record migration. practitioner_wage settings from Bizstim migrate as custom fields on the Person record. We deduplicate against Staff records using staff_id to avoid creating duplicate Person entries when both Practitioner and Staff endpoints return overlapping data. The mapping assumes the customer has reviewed and confirmed that Practitioner and Staff records represent distinct individuals in their business.

Bizstim Service records with a group_id represent individual offerings within a bundle; those without group_id are standalone services. We map standalone services to Twenty custom object entries with service name, cost, session count (group_num), and practitioner wage defaults as structured fields. Services with group_id are grouped by their parent group_id, and the group itself maps to a Twenty Opportunity or custom object that bundles the child service entries. This preserves the service package structure that Bizstim customers use for tutoring sessions, appointments, and bundled service offerings.

Bizstim service_group_names table entries define the parent group structure that organises related services via group_id. We export the group hierarchy and map each group to a Twenty Opportunity with the group name as the opportunity name, using the group_id as an external reference key. Child services are linked to the parent group Opportunity via a custom lookup field. Service groups that contain no child services are imported as standalone custom object entries without a parent relationship.

Bizstim Payment records track amounts, dates, and client associations via client_id. We map each payment to a Twenty Activity record attached to the corresponding Person (resolved from client_id), with the payment amount and currency stored in custom fields on the Activity. For customers using Bizstim's invoice feature, the invoice record migrates as a separate Activity with invoice number, date, and line-item details. Currency fields are stored as decimal values and migrated as-is with the currency code preserved in a text field until the customer's admin confirms the currency configuration in Twenty.

Bizstim Client records contain minTime, maxTime, slotDuration, and sessionLimit fields that define individual availability windows for each client. We extract these as structured availability rules and map them to Twenty Event records with the practitioner and client linked via the Person relationship. Session scheduling data migrates as Events with the start time, duration, and attendee information preserved. The customer's admin rebuilds the recurring availability pattern in Twenty's calendar after migration because the calendar preference data does not include the practitioner's own schedule constraints.

Bizstim User records return login information and role data for system users. We export the user table to identify owner and assignee mappings that apply to Practitioner and Client records. Owner resolution is performed by matching the Bizstim user email to the email of the corresponding Person in Twenty, and the owner assignment is set on the migrated records. Any Bizstim User without a matching Person in Twenty is flagged for the customer's admin to provision a Twenty User account before record import resumes.

Bizstim Staff records are queryable via GET and in most Bizstim accounts overlap with Practitioner records. We export Staff records and consolidate them with Practitioner records, deduplicating by staff_id against the practitioner_id list. Any Staff records without a corresponding Practitioner entry are migrated as separate Person records with a staff role designation. This mapping ensures that businesses using Staff and Practitioner as distinct objects do not lose staff-specific data during the migration.

On-demand encrypted links are session-scoped temporary tokens that generate session access URLs tied to a custom student identifier and agent IDs. These tokens are not portable across systems and are not migrated by design. The customer's admin sets up new session access mechanisms in Twenty using Twenty's built-in meeting link integration or a third-party video tool. We document the count of active on-demand links during scoping so the admin accounts for this gap in their migration checklist.

Bizstim client notes and free-text fields are included in the Client export and migrate as Twenty Files attached to the corresponding Person record via the file relationship. Binary attachments or file uploads stored within client records must be identified separately during the scoping call, as the Bizstim API does not expose a dedicated attachment endpoint and file storage requires manual export from the Bizstim interface. We include file migration as a line item in the scoping document with a note that customer-assisted export is required for binary attachments.

Bizstim allows extended custom fields on Client and Practitioner records. We export the full custom field schema during scoping, map each custom field to an equivalent custom field in Twenty on the Person object, and include field-type validation (text, number, date, picklist) in the mapping document. Fields that do not have a direct Twenty equivalent are flagged for the customer's admin to confirm whether a custom field, tag, or note is the appropriate destination.

Service records in Bizstim support extended custom fields beyond the standard cost, session count, and practitioner wage fields. We export the service custom field schema during scoping and map each field to a corresponding custom field on the Twenty destination object (Custom Object or Opportunity depending on the mapping strategy). Fields with picklist or multi-select values are mapped to Twenty picklist or multi-select fields with the value set validated against Twenty's allowed values.