Migrate from Kizen to Microsoft Dynamics 365 Sales

Kizen Contacts are a standard Object type with name, email, phone, address, and lifecycle properties. Dynamics 365 separates unqualified prospects into Lead and qualified buyers into Contact attached to Account. We define the split rule at scoping by examining the Kizen Contact lifecycle property values. Contacts with a pre-sale lifecycle stage map to Salesforce Lead; contacts with a qualified lifecycle stage map to Salesforce Contact with the original Kizen lifecycle stage preserved in a custom field kizen_lifecycle_stage__c on both Lead and Contact for audit. The AccountId on Contact is resolved after the Account import phase completes.

Kizen Company records map directly to Dynamics 365 Account. The company domain field becomes the Account Website, and we use it as the dedupe key during import. Kizen's Primary relationship (one-to-many linking Contacts to Company) maps to the standard Account-Contact lookup, and the relationship cardinality is preserved during migration. Company industry, size, and revenue fields map to typed Account fields where available.

Kizen Deals map to Dynamics 365 Opportunity. The dealstage property maps to StageName, and the pipeline assignment maps to a Record Type and Sales Process we configure in the destination org before migration. Closed-Lost and Closed-Won reason fields from Kizen custom properties become Opportunity Loss Reason and custom Win Reason fields. Kizen deal amount and close date migrate as Amount and CloseDate on Opportunity.

Each Kizen pipeline becomes a Dynamics 365 Record Type on Opportunity with a corresponding Sales Process that whitelists the migrated stage values. Stage order and probability percentages transfer from Kizen to the Dynamics 365 stage definitions. If Kizen has multiple pipelines with overlapping stage names, we create separate Record Types so that the pipeline context is preserved and stage values remain scoped per line of business.

Kizen custom Objects are the primary migration complexity driver. We discover every custom Object via the Kizen API at the start of scoping, map its custom fields to typed Dataverse columns, and pre-create the destination custom entity in Dynamics 365 before any data import. Lookup relationships between custom Objects are reconstructed as Dataverse lookup columns or, if the relationship type does not map directly, as a text field holding the related record ID. Custom Object naming convention is preserved with a __c suffix per Dynamics 365 standard.

Kizen Activities are a distinct Object type capturing logged interactions against other Objects. We split by activity type: calls become Task with TaskSubtype=Call, standard tasks remain Task, and scheduled meetings become Event. The Kizen activity timestamp becomes ActivityDate (Task) or StartDateTime/EndDateTime (Event). We preserve the linked Object reference by resolving the Kizen relationship field to the corresponding Dynamics 365 record ID at migration time.

File attachments linked to Kizen Objects are exported as binary blobs with their parent record reference preserved. We attach them to the corresponding Dynamics 365 record as a Note with an annotation holding the file blob, or we map to SharePoint document libraries if the destination org has SharePoint integration configured. Document management capabilities vary by Dynamics 365 tier; we note the chosen strategy in the migration spec.

Kizen tags are label values applied to Object records. We export tags as multi-select field values on the corresponding Dynamics 365 record. If the Dynamics 365 destination has a picklist field for the tag category, we use that; otherwise we create a custom multi-select picklist field and populate it during import. Tags without a destination field equivalent are exported as a text field and flagged for the customer to decide on final placement.