Migrate from Skyward CRM to Salesforce Sales Cloud

Skyward CRM Company records map to Salesforce Account. The company identifier becomes Account.Id; company name maps to Name; address fields map to BillingAddress components. Account is created first in the migration sequence to satisfy foreign-key constraints before child Contact records are imported. We use company name as the dedupe key during import to prevent duplicate Account creation.

Skyward CRM Contact records map to Salesforce Contact. Each Contact's parent CompanyId resolves to a Salesforce AccountId at migration time using the Account dedupe key. Standard name, email, phone, and address fields map directly. We preserve any contact-specific custom fields discovered during the admin panel enumeration phase as typed Salesforce custom fields.

Skyward CRM Lead records map to Salesforce Lead as a separate object from Contact, preserving lifecycle stage data that would otherwise be lost if leads were imported as Contacts without an Account. Lead Status from Skyward CRM maps to Salesforce Lead Status; any lead score property becomes a custom field lead_score__c on the Salesforce Lead object.

Skyward CRM Deal records map to Salesforce Opportunity. Each Deal's associated Contact and Company resolve to Opportunity Contact Roles and AccountId at migration time. Deal value maps to Amount; deal name maps to Name; owner maps to OwnerId via the User reconciliation step. Closed-won and closed-lost reasons from Skyward custom fields become Salesforce Loss Reason fields.

Skyward CRM pipeline stages use fully custom names with no enforced standard set. We enumerate every stage during scoping, capture the stage order and probability value, and map each to a Salesforce Opportunity StageName within a configured Sales Process. Multi-stage pipelines require a separate Record Type in Salesforce, each with its own Sales Process whitelisting the relevant stage values.

Skyward CRM Activity records map to Salesforce Task (calls and tasks), Event (meetings), and EmailMessage (emails) objects. Activity type, date, and notes preserve. All timestamps normalize to UTC during import. The parent Contact or Deal resolves to WhoId and WhatId on the Salesforce activity record. Large activity volumes use Salesforce Bulk API 2.0 with chunking and exponential backoff.

Skyward CRM custom fields on core objects require manual discovery from the admin panel since no public metadata API exists. We enumerate every discovered custom field per object, map the field type to an equivalent Salesforce field type (text, number, date, picklist, checkbox, etc.), and pre-create the destination schema before the import phase. Any missed custom field requires a post-migration gap review.

Skyward CRM partner records use a non-standard schema including partner type, commission structure, and shared lead attribution fields. Partner records do not automatically merge with contacts even when the partner is also a customer. We extract partners into a separate staging table and map them to the destination CRM's equivalent object based on the customer's intended use: standard Account with a partner-type flag, or a custom Partner object created during schema design.

Skyward CRM users assigned as record owners extract into a User roster. We match by email address against the destination Salesforce org's User table. Any Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Salesforce Users are used for historical owner assignment if the original Skyward CRM user is no longer active.

Skyward CRM product catalog entries linked to deals migrate to Salesforce Product2 records. We extract product name, SKU, pricing, and description fields. A Standard Pricebook is created in Salesforce before migration, and PricebookEntry records link products to the Pricebook during the import phase.

Skyward CRM notes attached to contacts, companies, or deals migrate to Salesforce Note records. Notes preserve body text and creation timestamp. Attachment of notes to parent records uses ContentDocumentLink with the shared link type, pointing to the resolved Contact, Account, or Opportunity.

Reports in Skyward CRM are generated from live data and are not stored as independent record sets. We do not migrate reports as data because they are configuration artifacts that reference specific object schemas. Customers rebuild reports in Salesforce using the Report Builder with the new object and field structure. We document the complete list of existing Skyward CRM reports during scoping for the customer to reference during rebuild.