Migrate from Sunbase Data to Twenty CRM

Sunbase Contact records (name, email, phone, address, plus industry-specific fields) map to Twenty People. Standard fields migrate directly. Sunbase custom fields on Contact require a pre-shared field manifest because the field definition metadata (name, type, validation) does not export alongside data. We validate that all custom field names in the manifest exist as configured fields in Twenty Settings → Data Model before the import phase begins.

Sunbase captures leads through door-to-door sales forms, web capture, and manual entry. We classify Sunbase Leads by status: unqualified leads (no associated Deal, no follow-up scheduled) map to Twenty People as a standalone record; leads with an active deal or scheduled appointment map to Twenty People with a linked Opportunity. The customer defines the classification threshold during scoping based on their sales process.

Sunbase Client records represent either individuals (homeowners) or organizations (property owners, general contractors). We inspect the client_type field during extraction and route individual clients to Twenty People and organizational clients to Twenty Company. The customer confirms the client type taxonomy during scoping because Sunbase does not enforce a strict type distinction.

Sunbase CRM module Company records (distinct from organizational Client records) map directly to Twenty Company. The company domain or website becomes the lookup anchor. If both Sunbase Company and Sunbase Client (org type) exist for the same organization, we deduplicate during the transform phase by company name match and consolidate into a single Twenty Company record.

Sunbase Deals (with pipeline stages, deal values, proposals, quotes, and stage history) map to Twenty Opportunity. The pipeline stage name maps to Opportunity stage. Sunbase pipeline configuration (visual sales boards, stage definitions) is non-exportable; we document the current stage names and probabilities from Sunbase during scoping and the customer configures the corresponding Opportunity stages in Twenty before migration. Closed-Won and Closed-Lost reasons migrate as custom fields.

Sunbase Projects (installation or job-site operations with metadata, status, budget tracking, and linked Work Orders) have no direct Twenty standard object equivalent. We pre-create a Twenty custom object named Project via Settings → Data Model, define custom fields matching Sunbase project metadata, and import Projects as custom object records. Projects with multiple associated Work Orders maintain a lookup relationship that we resolve by Project ID during import.

Sunbase Work Orders (permit info, task details, attachments, system specifications, employee assignments, and scheduling data) migrate to a Twenty custom object named Work Order. We pre-create the custom object schema including fields for permit number, system specifications, assigned crew, and status. Work Order links to Project via a lookup relationship resolved at import time. Attachments require separate handling (see gotchas).

Sunbase Invoices (line items, payment status, and linkage to Project or Client) migrate to a Twenty custom object named Invoice. We preserve invoice number, issue date, due date, line item descriptions, amounts, and payment status. Invoices link to the originating Project or Client record via lookups resolved at migration time. Historical paid invoices migrate as records with a Paid status flag.

Sunbase Employee records include HR data, crew assignments, and GPS location history. We split Employee into two migration targets: (1) people records for employees who are also sales contacts or client-facing (migrated to Twenty People with a role tag), and (2) a user provisioning list for employees who need Twenty user accounts. GPS trail data is bulk-exported where available and provided as a CSV attachment to the customer for manual use in Twenty; it does not map to a standard Twenty field.

Sunbase Appointments (with dates, times, assigned contacts, and status) map to Twenty Task records with the scheduled date preserved in the due date field. The appointment description migrates as the Task body. Google Calendar linkage is not transferable; appointments land as Twenty records without a calendar sync. We flag calendar reconnection as a post-migration configuration step.

Sunbase Documents (contracts, financing applications, permits) are binary files stored in the module. CSV import does not include file attachments. We extract file metadata (file name, upload date, associations to Contact, Deal, Project) as structured records and provide the customer with a document re-upload plan: either manual re-upload via Twenty's UI or API-based migration of the binary files. The customer chooses the approach during scoping.