Migrate from Skyward CRM to Microsoft Dynamics 365 Sales

Skyward CRM Company records map to Microsoft Dynamics 365 Sales Account. The Company is the parent entity for Contact records, so we extract and import Companies first to establish the accountid foreign key before Contact import. Company name becomes Account Name, and company phone/address fields map to standard Account address and telephone fields. We use Company name as the dedupe key during import to prevent duplicate Accounts.

Skyward CRM Contact records map to Microsoft Dynamics 365 Sales Contact with accountid resolved to the parent Account created in the previous phase. Standard name, email, phone, and address fields map directly. Any contact that is also a partner (identified by cross-reference to the partner staging table) is flagged with a custom field for manual review rather than automatically merged, since Skyward CRM does not automatically merge partner and contact records even when the same entity appears in both modules.

Skyward CRM Lead records migrate to Microsoft Dynamics 365 Sales Lead. Lead source, status, and rating fields map directly. We preserve the full lead score or qualification data in custom fields on the Dynamics 365 Lead since Skyward CRM stores qualification metrics as custom properties. Lead records without an associated Company are imported as standalone Leads; those with a Company association resolve to the imported Account.

Skyward CRM Deal records map to Microsoft Dynamics 365 Sales Opportunity. The Deal name becomes the Opportunity name, deal value maps to Amount, and the deal owner maps via email lookup to the Dynamics 365 User. Pipeline stage mapping is the most critical transformation: we capture the complete Skyward CRM pipeline configuration during scoping, produce an explicit stage-mapping table, and configure Microsoft Dynamics 365 Sales Process stage values to match before import so that Deal records land in the correct stage.

Skyward CRM allows full customization of deal pipeline stages with no enforced naming standard. Each Skyward pipeline maps to a Microsoft Dynamics 365 Sales Process, and each Skyward stage name maps to a Dynamics 365 StageName value within that Sales Process. We configure the Sales Process in the destination Dynamics 365 org before any Opportunity records are imported. Multi-stage pipelines with conditional transitions require additional validation to confirm all Deal records land in the correct stage after import.

Skyward CRM's partner management module stores partner entities with fields for partner type, commission structure, and shared-lead attribution. Partner records do not automatically merge with contacts even when the same entity appears in both. We extract partners into a separate staging table and map them to Dynamics 365 Accounts (if the partner is also tracked as a business entity) or to a custom partner entity that the customer configures. Commission structure fields map to custom fields on the partner entity. The customer's admin decides the partner strategy during scoping.

Skyward CRM Activity records (calls, emails, meetings, tasks, notes) migrate to Microsoft Dynamics 365 Sales Task and Event records. Activity type determines the target object: call activities map to Task with TaskSubtype=Call; meeting activities map to Event; emails and tasks map to Task. Activity timestamps normalize to UTC during import. The WhoId on Task/Event points to the resolved Contact or Lead; the WhatId points to the related Opportunity or Account. Complex activity threads that span multiple contacts require junction-table handling.

Skyward CRM product catalog entries map to Microsoft Dynamics 365 Sales Product2 records. Product name, description, and pricing fields migrate directly. Product-to-deal associations require junction-table handling during import because Dynamics 365 stores product-opportunity links as OpportunityLineItem records with references to both the Opportunity and the Product2. We create Pricebook2 entries during import to enable quoting workflows.

Skyward CRM users assigned as record owners are extracted by email address. We resolve each Skyward owner email against the Microsoft Dynamics 365 Sales User table using email as the lookup key. Any Skyward Owner without a matching Dynamics 365 User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Contacts, Leads, Opportunities, and Activities are resolved at migration time.

Skyward CRM supports custom fields on core objects, but the platform does not expose a public metadata API that enumerates custom field definitions. During scoping, we request admin-panel access to manually enumerate custom fields for each object. Each discovered custom field maps to a Dynamics 365 custom field of equivalent data type (text, number, picklist, date, etc.). We explicitly document all discovered custom fields in the field-mapping spreadsheet before the import phase. Any custom field missed during discovery results in a post-migration data gap review.