Migrate from Bright to Microsoft Dynamics 365 Sales

Bright contacts migrate as Dynamics 365 Contacts. Each contact requires a primary AccountId lookup; if a Bright contact has no company association, FlitStack links it to a default placeholder account, or your admin can define a fallback rule assigning unbound contacts to a designated holding account. The migration preserves the original created date, owner email, and custom fields, while enforcing referential integrity for downstream opportunities and activities.

Bright contacts that represent early-stage prospects with no closed deal history can be routed to Dynamics 365 Lead. Your team decides the split threshold — for example, contacts with zero associated deals become Leads; those with deal history become Contacts.

Bright companies map directly to Dynamics 365 Accounts. Parent‑company hierarchies are preserved using the Parent AccountId field, keeping the top‑level and subsidiary structure after migration. Bright's many‑to‑many contact‑company associations collapse to a single primary AccountId per contact, with relationships stored in Account Contact Relationships; FlitStack creates these records automatically. All custom fields on the company become Dataverse columns with the new_ prefix, and original created date and owner are retained.

Bright deals map to Dynamics 365 Opportunities. The deal name becomes Opportunity Name, the amount maps to EstimatedValue, the close date to CloseDate, and the pipeline stage to StageName via value mapping. Owner resolves to OwnerId through email matching against Azure AD‑synced users, and custom fields on the deal become Dataverse new_* columns. Probability values are reapplied based on the target stage, while original created and modified timestamps are retained.

Bright deal pipelines translate to Dynamics 365 Business Process Flows. Each Bright pipeline stage becomes a stage step in the BPF. If Bright uses multiple pipelines, FlitStack can create BPFs for each pipeline or collapse them into a single BPF with conditional branching that routes opportunities by pipeline type. The BPF is linked to opportunities at creation, and any pipeline‑specific custom fields map to Dataverse new_* columns on the opportunity.

Bright owner records are matched by email address against Dynamics 365 system users synced from Azure Active Directory. Unmatched owners are flagged before migration — your team either invites them to Dynamics 365 or assigns records to a designated fallback owner.

Bright call logs migrate as Dataverse PhoneCall activities. Subject, description, duration (in minutes), direction (mapped to DirectionCode), and timestamp transfer directly. Owner resolves via email to a system user, and the RegardingId links the call to the associated contact or account. Any Bright custom fields on the call become Dataverse new_* columns on the PhoneCall table, preserving additional metadata such as outcome or phone number.

Bright email records map to Dataverse Email activities. Subject, body text, from/to addresses, and timestamp transfer, while direction (inbound/outbound) is stored in DirectionCode. Owner resolves via email to a system user, and RegardingId links the email to the contact or account. Email attachments migrate as annotation records attached to the email, and Bright custom fields on the email become Dataverse new_* columns on the Email table, preserving thread ID.

Bright meeting records become Dataverse Appointments with start time, end time, location, subject, and attendees. Required attendees are linked as ActivityParty records, and the meeting body maps to Description. Owner resolves via email to a system user, and RegardingId links the appointment to the contact or account. Bright custom fields on the meeting become Dataverse new_* columns on the Appointment table, preserving conference ID or meeting type.

Bright notes migrate as Dataverse Annotations (note entity). The notetext, subject, and owner are preserved, and the created date is retained. Rich-text formatting in Bright notes converts to HTML so the appearance carries over to Dynamics 365. If a note contains file attachments, FlitStack extracts them as file annotations linked to the same parent record, and any Bright custom fields on notes become Dataverse new_* columns on the Annotation table.

Bright file attachments on contacts, companies, or deals re‑upload as Dataverse file annotations. The filename, mime type, and creation date are preserved, and the annotation is linked to the parent record via RegardingId. Dynamics 365 storage quotas limit file size; FlitStack flags any attachments exceeding the limit before migration and can split or compress them. Any Bright custom fields on the attachment become Dataverse new_* columns on the annotation table.

Bright custom objects map 1:1 to Dataverse custom tables. Table names receive the new_ prefix. Custom object relationships using N:N associations may need junction tables in Dataverse — FlitStack identifies these during discovery and includes junction table creation in the migration plan.

Bright custom properties on contacts create new_* columns in the Dataverse Contact table. Data types map: text fields to nvarchar, number fields to integer or decimal, pick-lists to choice, dates to datetime. Your Dynamics admin publishes the solution before the data load.

Bright user records don't directly map to Dynamics 365 system users because Dynamics users must exist in Azure AD first. FlitStack resolves Bright owner emails against existing Dynamics system users; for Bright users not yet in Dynamics, the migration plan flags each one for your admin to provision or reassign.