Migrate from Propertybase to Salesforce Sales Cloud

Direct map. Propertybase Company stores brokerage clients, builders, solicitors, and agencies. Salesforce Account accepts the same name, industry, phone, and address fields. Parent-company hierarchies in Propertybase map to Account.ParentId. The mapping preserves the full company name and any custom industry classifications used in Propertybase for segmentation reporting in Salesforce.

Direct map for contacts linked to a Company record (SystemIsIndividual = FALSE in Propertybase). These land as standard Salesforce Contacts with an AccountId pointing to the mapped Account. Owner resolved by email match against Salesforce users. Contact title, department, and mailing address fields map directly to their Salesforce equivalents for complete record continuity.

Propertybase Individual Contacts (buyers without a company record) map to Salesforce Contacts with a ghost AccountId — Propertybase stores a background placeholder company to satisfy Salesforce's AccountId requirement. We preserve this as an 'Unassigned Account' default or a designated ghost Account.

Propertybase Enquiries (inbound requests for information) map to Salesforce Leads. Source fields (request type, source channel, property interest) migrate as custom Lead fields. Status and priority pick-list values map value-by-value. The mapping preserves the original enquiry creation date and any assigned owner for historical activity tracking within Salesforce.

Propertybase Listings have no Salesforce standard equivalent — they migrate as a custom object named Property_Listing__c. Property details (address, price, status, property type) map to custom fields on this object. Listings linked to a Master Project use a lookup to the custom Master_Project__c object.

Propertybase Offers and Contracts map to a custom Real_Estate_Offer__c object. Offer amount, status, purchaser contact, and associated Listing lookup migrate as custom fields. Closed-won offers can optionally create a Salesforce Opportunity for reporting continuity. The custom object also stores offer expiration dates and any contingencies recorded in Propertybase.

Propertybase Master Project hierarchies (multi-building or multi-stage developments) map to a custom Master_Project__c object. Individual Listings hold a lookup to this parent. The hierarchy depth is preserved as a custom field chain. Master Project details including development type, total units, and completion status are stored as custom fields on this object.

Propertybase Favourite records link Enquiries to Listings they expressed interest in. This N:M relationship has no Salesforce standard equivalent — we create a Property_Interest__c junction object with lookups to the mapped Lead and Property_Listing__c. The junction object also stores the date when the interest was recorded and the source channel that generated the enquiry.

Propertybase engagement records (calls, emails, meetings, notes) map directly to Salesforce Task, Event, and Note objects. Original timestamps, activity type, and owner are preserved. TaskWhatId and TaskWhoId link back to the mapped parent records. The mapping preserves the full activity description and any custom activity type classifications used in Propertybase.

Propertybase file attachments (listing photos, contract PDFs) re-upload to Salesforce Files via ContentVersion. File size limits (Salesforce default 25MB per file) may require chunking for large video assets. We re-attach Files to the mapped parent record. Original file names, content hashes, and file type metadata are preserved for post-migration verification.

Propertybase custom objects migrate 1:1 to Salesforce custom objects. API names preserve the Propertybase namespace where possible. Custom object associations that use N:N relationships in Propertybase need Salesforce junction objects. The migration plan documents all custom field types, pick-list value sets, and validation rules that must be replicated in Salesforce.