Migrate from BrightDoor to Twenty CRM

BrightDoor contacts and agent records map directly to Twenty's People object. The mapping includes first name, last name, email, phone, job title, and address fields. Owner assignment resolves by email match against Twenty workspace members. BrightDoor contacts without a matching workspace member receive a default assignee — your team configures the fallback before migration runs.

BrightDoor companies — homebuilders, brokerages, and developer firms — map to Twenty's Companies object. Company name, domain/website, industry, employee count, and annual revenue transfer as standard fields. Parent-company hierarchies map to the Companies.ParentId field where the source data includes a parent-builder reference.

BrightDoor deal records migrate to Twenty's Opportunities object. The mapping carries deal name, amount, close date, pipeline stage, and owner. Pipeline stage names map value-by-value to Twenty's Opportunity stage pick-list. Deals with a primary contact link get resolved to that person's People record via email match before the Opportunity record is created.

BrightDoor's community and development records have no native equivalent in Twenty's standard schema. We create a custom object called 'Community' in Twenty with fields for community name, location, lot count, and development status. The migration links community records to related Opportunities via a custom relation field, preserving the BrightDoor association without forcing it into an ill-fitting standard object.

BrightDoor's property and lot records represent individual units within a community. These map to a custom 'Property' object in Twenty with fields for lot number, address, status (available/under contract/sold), price, and a relation to the parent Community record. The migration loads custom object records after standard objects, respecting Twenty's import order requirements.

BrightDoor engagement logs (calls, emails, meetings) map to Twenty Tasks. Each task records the subject, body, due date, assignee, and the linked People or Opportunity record. Original activity timestamps are preserved as a custom datetime field since Twenty's standard CreatedDate reflects the import date. Owner assignment on activities resolves by the same email-match logic used throughout the migration.

BrightDoor notes migrate to Twenty's Notes object. Notes attach to People, Companies, or Opportunities based on the source record association. File attachments are downloaded from BrightDoor and re-uploaded to Twenty's file storage. Inline images embedded in note bodies are extracted, rehosted, and the URLs updated in the note body before import.

BrightDoor agents and contacts often carry real-estate-specific custom fields: license number, builder affiliation, agent tier, MLS ID. These migrate as custom fields on Twenty's People object. Field types are matched — text strings to text fields, pick-list values to select fields, dates to date fields. You configure field visibility and required status in Twenty before the migration run.

Property-specific custom fields (HOA fee, lot type, spec status, builder partner) transfer to the custom Property object in Twenty. Numeric fields like HOA fees migrate as number fields with two-decimal precision. Status pick-lists map value-by-value to maintain reporting continuity. If BrightDoor's source field type is unsupported, the data migrates as a text field with a transformation note in the migration plan.

BrightDoor owner and agent records are users within the CRM. Twenty uses workspace members as the user object. Migration resolves BrightDoor owner IDs to Twenty workspace members by email address — if a BrightDoor agent email matches an invited Twenty member, all records owned by that agent assign to the matching Twenty member. Unmatched owners are flagged before migration and can be invited to Twenty or assigned a fallback owner.

BrightDoor's pipeline and stage model maps to Twenty's Opportunity stage pick-list. Each BrightDoor pipeline stage becomes a Twenty stage value. Probability weights associated with stages in BrightDoor are recorded as custom number fields in Twenty since the standard probability field is not configurable. You configure stage order and probability defaults in Twenty's workspace settings after migration.

BrightDoor's internal record ID is preserved on each migrated record as a custom text field called Source_System_ID__c. This field serves three purposes: it enables delta-run de-duplication if a second migration pass is needed, it provides traceability for reconciliation audits, and it allows your team to reference the original BrightDoor record without keeping the source system accessible.