Migrate from Bridgify to Twenty CRM

Bridgify stores individual contacts as person records with contact details, association links, and interaction history. Twenty's People object is the direct equivalent — storing individuals linked to companies via companyId. We import each contact as a People record with name, email, phone, and job title fields preserved. If Bridgify stores contacts without a company link, those land in Twenty as People records with no companyId assigned.

Bridgify partner accounts, travel brands, hotel operators, and OTA relationships map to Twenty's Companies object. Company name, domain, industry, and address fields map directly. Parent-child company hierarchies in Bridgify map to Twenty's linked Company relation using the domainUniqueField reference method described in Twenty's import guide. We import companies first so their IDs are available when People records are imported.

Bridgify booking records, deal registrations, and partner agreements map to Twenty's Opportunities object. Each Opportunity links to a Company via companyId and optionally to a People record for the primary contact. Deal value, currency, expected close date, and pipeline stage from Bridgify map to Opportunity amount, closeDate, and stage fields. Stage names may need value mapping if Bridgify uses custom stage labels not present in Twenty's default pipeline.

Bridgify deal stages (e.g., Prospecting, Qualified, Won, Lost) map to Twenty Opportunity stage values. If Bridgify uses custom stage names, we create matching stage options in Twenty's Settings → Data Model before import. Stage probability values are not natively stored in Bridgify — we default to Fifty Fifty for new stages or use values you specify.

Bridgify's domain-specific records (bookings, tours, attractions, experience inventory) have no direct equivalent in Twenty's standard objects. We create a custom object in Twenty via Settings → Data Model before migration, defining fields that match the source schema. Relationships to People and Companies map as relation fields on the custom object. Custom object import runs after all standard objects are in place to satisfy foreign-key constraints.

Bridgify engagement logs, booking confirmations, and communication history map to Twenty Notes or Tasks. Notes in Twenty attach to People, Companies, Opportunities, or custom object records. Each imported note preserves the original creation timestamp and body text. Call and meeting records map to Tasks with Type set to 'Call' or 'Meeting' and the original duration preserved in the description field.

Bridgify owner IDs on contacts, companies, and deals resolve by email match against Twenty workspace members. We flag any Bridgify owner whose email has no matching Twenty user before migration — you can either invite that person to Twenty first or assign their records to a fallback owner. No record migrates without a valid Twenty owner assignment.

Bridgify file attachments on booking records, partner documents, or contact records migrate as note attachments in Twenty. Each file is downloaded from Bridgify's storage and re-attached to the corresponding Note record in Twenty. File size limits follow Twenty's attachment constraints. We preserve the original filename and content type.

Bridgify extended properties on any standard object (e.g., loyalty tier on a company record, booking reference on a contact) map to Twenty custom fields created via Settings → Data Model before import. We read the full property list from Bridgify's schema, map each to a Twenty field with matching type (text, number, date, select, multi-select, relation), and document the mapping in the migration plan.

Bridgify tag values on contacts, companies, or bookings become a custom select or multi-select field in Twenty. If tags are free-form strings, we create a text field. If tags follow a defined set, we create a select field with the exact options present in Bridgify and map each record's tag value to the matching option. Duplicate tags across objects may share one custom field definition or become separate fields depending on your preference.

Bridgify workflow logic, automation rules, and sequence triggers do not migrate to Twenty. These must be rebuilt in Twenty's workflow builder using triggers, conditions, and actions you define. We export your Bridgify workflow definitions as a JSON reference document so your admin can recreate each rule in Twenty with full visibility into the original logic.

Bridgify integrations with supplier networks, payment processors, or booking engines cannot be transferred to Twenty. Third-party connections must be rebuilt using Twenty's REST & GraphQL API or webhook system. We document every active integration endpoint from Bridgify and map each to a corresponding integration plan for Twenty.