Migrate from Brokerkit to Microsoft Dynamics 365 Sales

Brokerkit's agent record maps directly to Dynamics 365 Contact, with the agent's associated brokerage mapped to a Dynamics 365 Account. Each agent's primary brokerage affiliation becomes the Contact's AccountId lookup. If an agent has multiple brokerage affiliations in Brokerkit, secondary affiliations surface as Account Contact Relationships in Dynamics 365.

Each Brokerkit brokerage company record translates directly to a Dynamics 365 Account, preserving the company name, address, and contact details. Franchise or subsidiary relationships are expressed via Account.ParentAccountId, allowing hierarchical reporting and territory segmentation. Where Brokerkit supplies industry classification or employee counts, those values populate Account.Industry and Account.NumberOfEmployees, ensuring that downstream analytics and segmentation inherit the full corporate profile.

Brokerkit's recruiting pipeline becomes a Dynamics 365 Sales Process. Each Brokerkit pipeline stage maps to a corresponding Opportunity StageName value. Because Brokerkit stages are recruiting-specific (e.g. License verification, Offer review), we create custom stage values in Dynamics 365 rather than using default sales stages, preserving the recruiting workflow language in the new system.

Each Brokerkit recruiting deal maps to a Dynamics 365 Opportunity record. The deal's amount maps to Opportunity.Amount, close date to Opportunity.CloseDate, and owner to Opportunity.OwnerId resolved by email match against Dynamics 365 users. Deal stage from Brokerkit maps to the Opportunity.StageName value within the corresponding Sales Process.

Brokerkit activity records (calls logged, emails sent, meetings scheduled, notes attached to an agent) migrate as corresponding Dataverse activity types. Phone calls become PhoneCall, scheduled meetings become Appointment, emails become Email, and free-form notes become Note. Original timestamps and activity owners are preserved. Activities are linked to the corresponding Contact record.

Brokerkit custom properties on agent records that have no direct Dynamics 365 equivalent are created as Dataverse custom fields with a publisher prefix. For example, a Brokerkit property 'license_state' becomes a custom field new_license_state on Contact. We deliver a custom field creation plan before the migration run so the Dynamics schema is ready for data.

Brokerage-level custom properties (e.g. 'mls_id', 'broker_license_number') that have no Dynamics 365 native equivalent are created as Account custom fields. We enumerate all Brokerkit company custom fields and map them to new_ prefixed fields on the Account entity before data loading.

Brokerkit's agent tagging system (e.g. 'Top Producer', 'Referral Source', 'New Hire') has no direct Dynamics 365 equivalent. Tags migrate as a custom text or multi-select field (new_AgentTags__c) on the Contact record. Your admin decides whether to use a delimited text field or build a dedicated option set for tag-based segmentation.

The Brokerkit user assigned to an agent record (typically the recruiting broker) is resolved by email match against Dynamics 365 users. Unmatched owners are flagged before migration; your team either provisions them in Dynamics 365 first or assigns their records to a designated fallback owner. No record lands without a valid Dynamics 365 owner.

Files attached to Brokerkit agent or company records are migrated as Dataverse Annotations with documentbody populated from the source file. The original filename and MIME type are preserved. Dynamics 365 default file size limits apply (typically 10MB per attachment for most API scenarios).

The original Brokerkit record ID is stored as a custom field on each entity for traceability and delta-run de-duplication. This prevents duplicate records on subsequent migration runs and allows your team to reference the source system ID for reconciliation audits.

Because Dynamics 365 records its own CreatedOn and ModifiedOn timestamps when data is written, the original Brokerkit creation and last‑modified dates are captured in custom datetime attributes—new_originalcreatedate and new_originalmodifieddate—so that historical trend reports, aging analyses, and compliance audits can reference the true origin timestamps rather than the migration load date.