Migrate from GBuilder to Twenty CRM

Twenty requires custom fields to exist before CSV import — they are not auto-created

GBuilder custom fields cannot be imported into Twenty as new fields during the data load. Twenty's import process reads fields that already exist in the data model, and attempting to import into a non-existent field silently drops those values. FlitStack extracts the complete GBuilder custom field inventory during the planning phase, creates corresponding fields in Twenty Settings → Data Model, and verifies field existence before the migration run. If your GBuilder setup has 40+ custom fields, this pre-creation step adds 1–2 days to the timeline because Twenty's UI requires manual field creation or API-based bulk field provisioning per object.

GBuilder pipeline semantics collapse into Twenty's flat Opportunities stage model

GBuilder supports multiple named pipelines, each with independent stage sets. Twenty's Opportunities object uses a single stage select field with no sub-pipeline construct. If your GBuilder setup uses more than one pipeline, the pipeline identity must be preserved as a separate custom field (Pipeline_Name__c) and stage names must be qualified (e.g., 'Enterprise — Negotiation') to prevent collisions when two pipelines share a stage name like 'Proposal Sent'. This affects reporting that relies on GBuilder's pipeline-stage hierarchy — those reports must be rebuilt in Twenty's views and do not migrate automatically.

Twenty API rate limits cap bulk migration throughput at 100–200 requests per minute

GBuilder API responses and Twenty's import API both impose rate limits that affect large migration runs. Twenty's Pro tier allows 100 API calls per minute; Organization tier allows 200. GBuilder's export API similarly throttles large record pulls depending on your subscription tier. FlitStack throttles API calls on both sides using exponential backoff and batch endpoints where available. For migrations exceeding 50,000 records, this throttling extends the migration window — we compensate by running parallel workers within rate-limit headers and splitting large record sets into chunked loads that respect the per-minute quota on Twenty's API.

GBuilder owner-to-Twenty Workspace Member resolution requires pre-invited users

Twenty's foreign-key model for record ownership links Opportunities and Tasks to Workspace Members. The GBuilder owner field does not map to Twenty's assignee without an existing Workspace Member record to reference. If a GBuilder owner email has no corresponding Twenty user, the record either gets assigned to a fallback user (defined by you before migration) or is flagged as unresolvable. The fix requires inviting all GBuilder users to Twenty and waiting for them to accept before migration — user invitations that arrive after the migration window cause orphaned ownership on records already loaded. We validate user resolution before committing the migration plan.

File attachments require re-hosting — original storage URLs are not preserved as live links

GBuilder stores file attachment URLs that point to GBuilder's own blob storage. Those URLs become invalid after the migration completes and the GBuilder account is deprovisioned. Twenty does not maintain a link to external file storage; it accepts file uploads into its own storage layer. FlitStack downloads each attachment from GBuilder, re-uploads it to Twenty, and links the file to the correct record in Twenty's context. For large file sets (e.g., proposal documents, drawings, or project images), this re-hosting step adds extraction and upload time proportional to total attachment volume.