Migrate from Rizer to HighLevel

Rizer Contacts map directly to GoHighLevel Contacts. Standard fields (name, email, phone, address) migrate as typed fields. Referral source attribution from Rizer becomes a custom contact property (referral_source__c) in GoHighLevel. Lifecycle stage transitions, callback dates, and tag lists migrate as custom fields and contact tags respectively. GoHighLevel's contact model does not have a native referral tracking object, so attribution history is flattened into custom properties at migration time.

Rizer Company records map to GoHighLevel Company objects. Industry tags and custom company properties from Rizer migrate as GoHighLevel custom fields on the Company object. The Company-Contact association is preserved by resolving the Rizer contact-company link to a GoHighLevel Contact-Company lookup at migration time. GoHighLevel introduced native Company object support in 2024; we use the native object rather than creating a custom object equivalent.

Rizer Deals map to GoHighLevel Opportunities. Deal stage becomes GoHighLevel pipeline stage. If the Rizer account uses multiple deal pipelines, we create a corresponding number of GoHighLevel pipelines during schema setup. Deal value, expected close date, and associated Contact all transfer directly. The Rizer deal owner maps to the GoHighLevel assigned user by email match.

Rize Clients map to GoHighLevel Company records when the time-tracking scope is included in the migration. Client billing information from Rize migrates as custom fields on the Company record (billing_rate__c, billing_model__c). We treat the Rize and Rizer exports as two separate scoped passes and cross-reference the Client-Contact association to ensure the GoHighLevel Company is linked to the correct Contact record migrated from Rizer.

Rize Projects map to GoHighLevel Opportunities with a project tag (project_source__c = 'rize') distinguishing them from CRM Deals. If the customer uses GoHighLevel's custom objects feature, Projects can alternatively land as a custom Project object with lookup to the Client-Company. The migration plan is agreed with the customer during scoping based on how they report project revenue. Project status from Rize (active, paused, completed) maps to GoHighLevel Opportunity stage values.

Rize Tasks under Projects map to GoHighLevel Tasks linked to the corresponding Opportunity. Subtasks in Rize (represented as a boolean or count field on a Task) are expanded into discrete GoHighLevel Task records with a parent_task_id__c reference. Task assignment resolves to a GoHighLevel User by email match. Billable hours from Rize migrate as a custom field (billable_hours__c) on the GoHighLevel Task.

Rizer and Rize Team Members map to GoHighLevel User accounts by email match. Role assignments (admin, manager, member) from Rizer do not have a direct GoHighLevel equivalent; we document the role assignments as a custom field on the User record (source_role__c) and the customer's admin configures GoHighLevel permissions after migration. We do not provision inactive users in GoHighLevel without explicit instruction from the customer.

Rizer custom contact fields migrate to GoHighLevel custom contact fields. We inspect raw values before writing to infer data type because Rizer does not enforce type constraints at the API layer; date fields stored as strings, multi-select fields stored as delimited text, and numeric fields stored as text are all common. GoHighLevel custom fields support text, number, date, phone, and picklist types, and we map accordingly. The custom field schema is created in GoHighLevel before migration begins using the v2 API.

Rizer tags on Contacts migrate as GoHighLevel contact tags. Tags applied to Workflows and other objects are preserved as a comma-separated list in a migration_notes__c custom field because GoHighLevel's tag model is primarily contact-centric. The customer receives a tag taxonomy review during scoping to identify duplicate or unused tags for cleanup before import.

Rizer Workflow definitions (trigger conditions, delay rules, branching logic, tag triggers) do not migrate as executable code. We produce a written inventory of every active Rizer Workflow with its name, trigger event, conditions, actions, and recommended GoHighLevel Workflow equivalent. The customer's admin rebuilds workflows in GoHighLevel's visual builder. This is standard scope for all FlitStack AI migrations.