Migrate from bxp software to Microsoft Dynamics 365 Sales

Forms are BXP's primary data containers and hold arbitrary field configurations per client. We create a Dataverse table in Dynamics 365 named to match the BXP Form name, then map each BXP field to a typed Dataverse column (string, integer, decimal, datetime, or choice). The BXP Form ID is preserved as a custom field for audit traceability. If the customer uses multiple Forms with shared field structures, we consolidate them into a single Dataverse table with a FormType discriminator column to avoid duplicating the schema.

BXP Contact records map directly to Dynamics 365 Contact. Where the BXP instance stores an organisation name alongside individual contact details, we split the data: organisation name becomes an Account record, and individual details become a Contact record linked by a Lookup relationship. The BXP contact's email address is the dedupe key. Custom fields on the BXP Contact are enumerated during discovery and mapped to typed Dataverse columns on the Contact or Account record.

BXP activity logs (call duration, disposition, recording URL; email content; meeting attendees and location) map to Dynamics 365 Task (subtype Call), Event, and EmailMessage records. Call metadata (duration, wrap time, queue name) migrates to custom fields on the Task record since Dynamics 365 does not have native contact-centre metric fields. Activity timestamps are preserved as ActivityDate on Task and StartDateTime/EndDateTime on Event. BXP activities tied to a specific Contact carry a WhoId reference to the migrated Contact record.

BXP stores contact-centre metrics — call duration, wrap time, QA scores, and average handle time — in bespoke fields or sub-Forms that vary by client deployment. These do not map to standard Dynamics 365 objects. We create a custom Dataverse AgentMetric entity with columns for agent ID (lookup to User), metric date, metric type (choice), metric value, and source BXP Form ID. Each metric type (Average Handle Time, QA Score, Occupancy Rate) gets its own row so that the data is queryable in Power BI post-migration.

BXP's core value proposition is custom fields built per client. Every custom field is a mapping candidate. During discovery we enumerate all custom field names, data types, and picklist values from the BXP Form structure and map each to the equivalent Dataverse column type (Text, Integer, Decimal, Boolean, Choice, Option Set, or Lookup). Choice and Option Set fields in BXP map to Dataverse Option Sets with the same label-value pairs. Lookup fields referencing other BXP Forms map to Dataverse Lookup columns with the same target table relationship.

BXP can export custom archives in CDA format, a proprietary structured archive that requires parsing before migration. We request the CDA export directly from BXP during discovery, decode the binary or structured text format, and convert it to standard CSV or JSON before mapping to the equivalent Dataverse table. CDA parsing is scoped as a separate technical discovery task during the proposal phase; some CDA schemas require reverse-engineering based on the archive's internal field headers.

CCL is BXP's companion archive format to CDA, typically used for bulk record exports with relationship metadata. Like CDA, CCL requires parsing before migration. We request CCL exports during discovery and process them through a custom parser that extracts record-level data and relationship links. CCL relationship metadata is used to resolve parent-child lookups during the Dataverse import phase, ensuring that the correct AccountId and ContactId references are established on child records.

BXP's eLearning module stores training completion records, module scores, and assignment data in bespoke Form structures. Microsoft Dynamics 365 Sales has no native eLearning object. We create a custom Dataverse TrainingRecord entity and map course name, completion date, score, agent ID (lookup to User), and source Form reference. The customer may alternatively use Microsoft Viva Learning as a replacement for BXP's eLearning module post-migration; in that case, we document the mapping so that a Viva Learning admin can import the historical completion records as a reference archive.

QA evaluations tied to specific calls are stored in BXP in bespoke Form structures that vary by client deployment. Each QA record typically references a call activity, an agent, a scoring rubric, and a written evaluation. We map these to a custom Dataverse QAEvaluation entity with fields for call reference (lookup to Task), agent reference (lookup to User), evaluator name, score per rubric dimension, overall score, and evaluation notes. This preserves the full evaluation context alongside the associated contact-centre activity record.