Migrate from BrightDoor to Salesforce Sales Cloud

BrightDoor Contact maps directly to Salesforce Contact. Salesforce requires AccountId on most contact records — BrightDoor contacts without a primary company are attached to a default 'Unassigned Accounts' record or flagged for manual review. Original create dates are preserved in a custom datetime field since Salesforce CreatedDate reflects migration time.

BrightDoor Company maps to Salesforce Account. Account hierarchies (parent/child communities or broker relationships) map to Salesforce ParentId on the Account object. BrightDoor allows multiple contacts per company; Salesforce enforces a primary AccountId on Contact plus AccountContactRelation for additional associations. If BrightDoor stores parent-child company relationships, those map to Salesforce ParentId — the parent Account must be migrated first to avoid referential integrity failures.

BrightDoor Deal maps to Salesforce Opportunity. The Deal name becomes Opportunity Name; amount and stage map directly. Salesforce Opportunity requires AccountId — Deals without a linked Company record in BrightDoor are flagged and linked to the default Account during migration. Pipeline mapping requires record-type configuration in Salesforce.

BrightDoor pipeline stages map to Salesforce Opportunity Stage values within a Sales Process. Each BrightDoor pipeline typically requires its own Salesforce Record Type so stage pick-list values are scoped per pipeline without cross-contamination. We deliver a record-type setup plan before migration runs.

BrightDoor property and community records have no Salesforce standard equivalent. We create custom objects (Property__c, Community__c) in Salesforce with fields mapped from BrightDoor's property schema. The Opportunity (Deal) links to the community or property via a lookup field (Community__c, Property__c) on the Opportunity record.

BrightDoor lot inventory records map to a custom Lot__c object linked to the Community__c object, or to custom fields on the Opportunity if lots are tracked as opportunity-level attributes. The mapping approach depends on how BrightDoor stores lot status (available, sold, reserved) and which records reference which.

BrightDoor's buyer registration data — including registration date, community, lot preference, sales agent, and lead source — maps to a custom Registration__c object with lookup fields to Contact and Property/Community. This captures the full buyer journey BrightDoor tracks at the welcome center or online portal.

BrightDoor activity history (calls, emails, meetings, notes) maps to Salesforce Task (Type='Call' or 'Email') and Event objects with original timestamps, owners, and WhatId/WhoId linkage preserved. WhatId links to the parent Account or Opportunity; WhoId links to the Contact. Notes migrate to Salesforce Notes (not the legacy Note object).

BrightDoor file attachments are downloaded and re-uploaded to Salesforce Files. Files are stored as ContentVersion with the parent record linked via ContentDocumentLink (ShareType='V' for viewer access). Salesforce's 25MB per-file limit applies — larger files are flagged for splitting or alternative storage.

BrightDoor owner IDs are resolved by email match against Salesforce users. Unmatched owners are flagged before migration — the team either creates Salesforce users first or assigns records to a fallback owner. Owner history is preserved in a custom field for audit continuity.

BrightDoor custom properties migrate as Salesforce custom fields on the corresponding object. Field type conversion is applied: numeric properties become Number fields; date properties become Date fields; pick-list-style properties become Picklist with value mapping. All custom fields receive the __c suffix per Salesforce convention.