Migrate from bxp software to HighLevel

Forms are bxp software's primary data containers holding arbitrary field configurations per client instance. We enumerate every Form during discovery and replicate the field schema in GoHighLevel as a Custom Object with fields typed to match (text, number, date, boolean, dropdown). Form submissions become GoHighLevel Custom Object records linked to the associated Contact by email lookup. Any Forms with complex branching logic require manual configuration in GoHighLevel's native form builder as branching logic cannot be exported as data.

bxp software Contact records map directly to GoHighLevel Contact records. Email, phone, name, and address fields migrate as typed fields. Custom fields on the Contact record migrate as GoHighLevel Contact custom fields added via the Settings > Custom Fields panel before migration. The Contact record is the primary dedupe key throughout the migration — we resolve any duplicate Contacts by email before insert.

bxp software logs call activities, agent interactions, and engagement history in a schema that varies by client deployment. We map standard activity fields (timestamp, type, duration, disposition) to a GoHighLevel Custom Object named ContactActivity, linked to the Contact by email. Where bxp Activities contain call recordings or linked notes, we export those as URL references or structured attachments for the customer's admin to relocate post-migration.

Contact-centre-specific metrics such as call duration, wrap time, average handling time, and QA scores are stored in bxp software but have no direct GoHighLevel equivalent. We create a GoHighLevel Custom Object named AgentMetrics with fields matching the source metrics schema enumerated during discovery. The contact reference is stored as an email field so the customer's admin can cross-reference records. Agent-level aggregations that existed as reports in bxp software are documented for rebuild in GoHighLevel reporting.

bxp software's eLearning module stores training completion records, scores, and module assignments. These have no native GoHighLevel equivalent. We create a Custom Object named TrainingRecord in GoHighLevel with fields for module name, completion status, score, assignment date, and expiry date. The learner is referenced by email against the Contact record. Module content and course materials do not migrate — these require manual relocation to the customer's chosen learning management system.

QA evaluations tied to calls are stored in bxp software but are typically bespoke to each deployment. We create a Custom Object named QARecord in GoHighLevel with fields derived from the source QA form schema — typically evaluation score, evaluator name, call reference, evaluation date, and any custom flags. The QARecord is linked to the associated Contact and Activity records for evaluation context. The customer should confirm during discovery whether the QA form schema is consistent across agents or varies by team.

bxp software can export data in CDA (Custom Data Archive) format, a proprietary binary export that requires parsing before it can be loaded into any target system. We convert CDA exports to structured JSON using our own parser built during the discovery phase. The converted JSON is validated and mapped to the appropriate GoHighLevel objects before insert. CDA conversion is scoped during discovery and priced based on archive size and field complexity.

CCL (Custom Contact Log) is a second proprietary archive format used by bxp software for contact and activity exports. We parse CCL exports into standard CSV or JSON, validate field coverage against the discovered bxp schema, and load into GoHighLevel via the API. CCL parsing adds one to two weeks to the migration timeline and is scoped separately during discovery.

bxp software Agents map to GoHighLevel Users by email. We extract the full Agent list during discovery and match against GoHighLevel User accounts. Any Agent without a matching GoHighLevel User is held in a reconciliation queue for the customer's admin to provision before record migration proceeds. User roles and permissions in GoHighLevel are configured separately and are outside migration scope.

bxp software's core value proposition is custom fields built per client instance. Every custom field is a mapping candidate. During discovery we enumerate all custom field names, types, and the objects they attach to, then configure equivalent custom fields in GoHighLevel before any data is migrated. The custom field enumeration output is reviewed with the customer's admin to confirm the mapping intent — some bxp fields may be dropped if they have no meaningful GoHighLevel target.

bxp software Form submissions are the atomic data records in a BXP deployment. Each submission is linked to a Form (the schema container) and a Contact. We map submissions to GoHighLevel Custom Object records where the object schema matches the source Form definition. Submissions that predate a Form definition change are flagged for review during reconciliation. Form submission timestamps are preserved as the record creation date in GoHighLevel.