Migrate from Panacea to Microsoft Dynamics 365 Sales

Direct map. Panacea contacts with a primary company association land as Dynamics 365 Contacts with their AccountId populated. Panacea contacts that represent unqualified prospects route to the Dynamics 365 Lead entity — your team decides which Panacea contact property defines qualification status for the split.

Panacea contacts that have not progressed to a closed-won or closed-lost deal state split to Dynamics 365 Leads. Leads are created from Panacea contacts where the associated deal stage has never advanced past a defined threshold. Your FlitStack migration plan specifies this threshold based on your Panacea pipeline configuration.

Direct map. Panacea company name, domain, industry, and employee count map to the corresponding Dynamics 365 Account fields. Panacea parent-child company hierarchies map to Account.ParentId. Multi-company contacts from Panacea (N:N model) collapse to a primary AccountId plus Account Contact Relationships in Dynamics 365.

Direct map. Each Panacea deal becomes a Dynamics 365 Opportunity. The Panacea pipeline name maps to the Opportunity.RecordTypeId (one record type per pipeline). Stage names map value-by-value to the Opportunity Stage pick-list values scoped under that record type. Amount, close date, and owner map directly.

Each Panacea pipeline becomes a Dynamics 365 Sales Process (the business process flow) paired with a Record Type. Record types govern which page layout, field visibility, and stage pick-list values apply per deal type. We deliver a record-type setup plan before the migration runs so your Dynamics 365 admin can pre-create the schema.

Stage names map value-by-value per record type. Probability and forecast category are re-applied from the Dynamics 365 stage definitions. Panacea stage-entry timestamps are preserved as custom datetime fields (Stage_Entered_Date__c) since Dynamics 365 does not store historical stage-entry dates natively. This preserves audit trail continuity for reporting on deal progression history across both platforms.

Panacea custom properties become Dynamics 365 custom fields prefixed with new_ in the Dataverse schema. Text, number, date, and pick-list property types map to their corresponding Dataverse attribute typeclass. Pick-list values require a value-mapping table if the source values differ from Dynamics 365's existing options. Field-level security can be configured on each custom field post-migration.

Panacea call logs map to Dynamics 365 PhoneCall activities, emails to Email activities, meetings to Appointments, and notes to Annotations. Original timestamps, owner references, and parent-record links (ContactId or OpportunityId) are preserved. FlitStack uses the Dataverse activity tables to maintain the full activity timeline in the destination.

Panacea file attachments re-upload to Dynamics 365 as Annotation records attached to the parent Contact, Account, or Opportunity. Files exceeding Dynamics 365's 25 MB per-attachment limit are flagged and require SharePoint document library configuration in your Dynamics 365 environment before the migration commits.

Panacea owner IDs resolve to Dynamics 365 SystemUser records by matching the owner's email address. 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 OwnerId.

Dynamics 365 sets CreatedOn and ModifiedOn at the time records are created in the system. To preserve historical reporting, FlitStack captures the original Panacea create date and last-modified timestamp as custom datetime fields on each entity. These custom fields enable time-series reports and trend analysis that rely on the original creation timeline rather than the migration execution date.

The Panacea internal record ID is stored as a text field (Source_System_ID__c) on each Dynamics 365 record for traceability, delta-run de-duplication, and rollback identification. This field is indexed in Dynamics 365 to support efficient lookups during the delta-pickup window, ensuring that delta records can be matched accurately against already-migrated rows.