Migrate from Field Pros to Microsoft Dynamics 365 Sales

Direct map. Dynamics 365 requires a primary AccountId for most contact records. Field Pros contacts without a linked company land with a placeholder account or are routed to the Lead entity based on status. Owner resolved by email match against Dynamics 365 users.

Contacts with an unqualified status field value route to the Dynamics 365 Lead entity. Leads can be qualified (converted) to Contact + Account once sales-ready. The split decision is based on a status field flag in Field Pros at migration time.

Direct map. Field Pros company hierarchies (parent/child) map to the Account.ParentAccountId lookup in Dynamics 365. Parent accounts must be migrated first; circular references are flagged before migration commits. Inactive companies can be marked with a status field, and the original industry code is preserved where applicable to maintain reporting continuity.

Direct map. Field Pros deal pipelines map to Dynamics 365 Sales Processes tied to business process flows. Pipeline stages map value-by-value to Opportunity Stage options, preserving original close dates and owner assignments. The deal amount transfers to EstimatedValue, and any custom deal fields are mapped to new_ columns on the Opportunity entity. Deal priority is preserved as a custom option set for downstream filtering.

Stage names map value-by-value from Field Pros to Dynamics 365 Opportunity Stage. Stage probability and forecast category are reapplied per the destination business process flow. Stage-entry timestamps are preserved as custom datetime fields. If a stage includes custom attributes (e.g., renewal flag), these are stored as additional new_ columns on the Opportunity entity, and the stage order is enforced by the business process flow definition.

Field Pros custom objects map 1:1 to Dataverse custom tables in Dynamics 365. Custom-object associations that use a many-to-many model in Field Pros need Dataverse N:N intersection tables. We surface this in the pre-migration schema plan. The new tables are created under a designated solution publisher prefix, and we verify that the target license tier (Professional vs. Enterprise) supports the resulting table count before the migration proceeds.

Field Pros call logs become Dynamics 365 Tasks with Type='Phone Call'. Emails become Email activity records. Meetings become Appointments with original start/end times and owner preserved. Parent record links to Contact or Account are maintained. Cancelled or rescheduled meetings retain their original status as an Appointment entity with a 'Cancelled' state. Call duration and disposition are stored in custom fields on the Task record for reporting.

Field Pros notes migrate as Dynamics 365 Annotations. Rich-text formatting is preserved. Notes attached to a specific record link via the ObjectId lookup. If the parent record fails migration, notes are held for manual reattachment. Notes without a valid parent are placed in a staging queue and reported in the migration summary, allowing admins to reassociate them after the migration completes. Annotations longer than the default size limit are split into multiple records.

Field Pros file attachments are re-uploaded to Dynamics 365 SharePoint document libraries or as Note attachments. File size limits (default 128MB per file in Dataverse) are enforced. Inline images in rich-text notes are extracted and rehosted separately. The original folder hierarchy is recreated in SharePoint, and file permissions are translated to Dynamics 365 sharing settings. Large files exceeding 128MB are chunked and uploaded via the SharePoint REST API to stay within limits.

Owner resolution happens by email match against Dynamics 365 SystemUser records. Unmatched owners are flagged before migration — your admin either invites them to Dynamics 365 first or assigns their records to a fallback owner. No record lands without an assigned owner.

Field Pros custom fields that have no direct Dynamics 365 equivalent (e.g., multi-select or formula fields) are created as new_ Dataverse columns in the appropriate table. Field type conversion is documented in the migration plan before execution. Unsupported field types such as multi-select picklists are stored as delimited text columns, and option-set mappings are preserved in a companion metadata table for downstream reporting.