Migrate from Corteza CRM to Salesforce Sales Cloud

Corteza Leads map directly to Salesforce Lead. The standard fields (first name, last name, email, phone, rating) map to their Salesforce equivalents. We resolve the lead conversion workflow during scoping: if the customer's Corteza instance uses the lead-to-account conversion trigger, we flag the corresponding Salesforce Lead Status and Sales Process configuration needed post-migration. Lead source and any custom rating fields migrate as custom fields on Lead.

Corteza Accounts (companies) map directly to Salesforce Account. Industry classification, address data (street, city, state, postal code, country), and social media URLs migrate to their Salesforce equivalents. Account is the parent of Contact, so we create all Account records before any Contact import so that AccountId is available at Contact insert time. We use the Corteza account name as the Account Name and the domain as a dedupe key during import.

Corteza Contacts map to Salesforce Contact with the AccountId lookup resolved from the parent Account import. Standard fields (first name, last name, email, phone, job title) migrate to their Salesforce equivalents. We preserve the Corteza contact-account relationship by matching on account name or domain at migration time. If a Corteza Contact has no associated Account, we create a standalone Contact with no AccountId or assign it to a default placeholder Account depending on the customer's scoping preference.

Corteza Opportunities (deals) map to Salesforce Opportunity. Stage, amount, probability, and close date migrate to StageName, Amount, Probability, and CloseDate. The Corteza pipeline assignment maps to a Salesforce Record Type and Sales Process that we configure before migration. If Corteza stores closed-lost reasons or win reasons as custom fields, we map them to Salesforce Loss Reason and Win Reason standard fields.

Corteza Campaigns map to Salesforce Campaign with campaign type, status, and budget fields preserved. Campaign members (Contacts and Leads) map to Salesforce CampaignMember records. We resolve CampaignMember contacts by matching email against the migrated Contact and Lead tables. Campaign activity history (response tracking) migrates as CampaignMember status values. Note that Salesforce does not natively replicate Corteza's full campaign workflow or member scoring behavior; these require a post-migration review of available AppExchange tools or custom Flow rebuild.

Corteza Cases (support issues) map to Salesforce Case if the destination Salesforce org includes Service Cloud or if the customer configures Case as a standard object in their Sales Cloud tier. Status, priority, origin, and resolution fields migrate directly. Case-Account and Case-Contact relationships are resolved from the parent Account and Contact imports. If the destination org does not have Service Cloud licensed, we flag this during scoping and recommend a Service Cloud activation or a Case Custom Object fallback configuration.

Corteza Contracts map to Salesforce Contract when the destination org has the Contract object enabled (standard in Sales Cloud Professional and above). Contract terms, start and end dates, and status migrate directly. Contract-Account relationships resolve via Account lookup. Line items (ContractLineItem) map to Salesforce ContractLineItem if the customer uses the Salesforce CPQ or Order Management product; otherwise, we treat line items as a custom object migration.

Corteza Tasks map to Salesforce Task. Each task carries status, due date, assignee (OwnerId resolved via User email match), subject, and description. Tasks can be standalone or related to any parent record in Corteza; we resolve the WhatId and WhoId lookups during migration by matching parent records against the migrated Lead, Contact, Account, and Opportunity tables. Activity timeline ordering is preserved by setting ActivityDate to the original Corteza timestamp.

Corteza Events (meetings, calls) map to Salesforce Event with StartDateTime, EndDateTime, Subject, and Location preserved. Attendees map to EventRelation records pointing at the migrated Leads, Contacts, and Users. We resolve all EventRelation lookups after the parent Contact and User imports are complete. If Corteza stores event descriptions as rich text, they migrate as Salesforce Event Description.

Corteza Notes attached to CRM records migrate to Salesforce Note with the parent record linked via ContentDocumentLink. Note body migrates as the Note Body field (rich text supported). If Corteza stores notes as files rather than note records, we treat them as attachment migration under the Files object mapping. We preserve note creation timestamps to maintain audit ordering in the Salesforce activity timeline.

Corteza Quotes migrate to Salesforce Quote (available from Sales Cloud Professional onward). Quote headers, terms, and expiration dates migrate directly. Quote PDFs and signed documents migrate as ContentDocument linked to the Quote record. If the customer does not have Quote enabled in their Salesforce edition, we flag this during scoping and recommend a Quote Custom Object configuration as the fallback.

Corteza Quote Line Items map to Salesforce OpportunityLineItem when the Quote-Opportunity relationship is active. We resolve the Pricebook2 reference, Product2 reference, and parent OpportunityId at migration time. Quantity, UnitPrice, and TotalPrice migrate directly. If the customer does not use Salesforce standard Pricebooks, we create a migration-specific Pricebook2 and populate PricebookEntry records before line item import.

Corteza Products map to Salesforce Product2 with ProductCode, Name, Description, and IsActive preserved. We create Standard Price Book entries for each Product2 record during import. Product families map to Salesforce Product Family picklist values. If Corteza stores product images as attachments, we migrate them as ContentDocument linked to the Product2 record.

Corteza Pricebooks map to Salesforce Pricebook2. The default pricebook flag migrates from Corteza. PricebookEntry records map to Salesforce PricebookEntry with Product2 reference, Pricebook2 reference, CurrencyIsoCode, and UnitPrice. We create the Pricebook2 records before Product2 import so that PricebookEntry references are satisfied at insert time.

Corteza's low-code module builder creates entirely custom objects that may have non-standard field types, custom validation rules, or non-standard relationship structures. We pre-create the Salesforce custom object schema (with __c API name suffix matching the Corteza module name) before any data import, including all custom fields, field types, lookup relationships to standard objects, and validation rules. Custom picklist values migrate as Salesforce picklist values. Any Corteza-specific field types without a Salesforce equivalent (such as Corteza's page reference fields) are flagged for customer review during scoping.

Corteza file fields (attachments stored per module) map to Salesforce ContentDocument with ContentVersion for versioning. We migrate the file binary, filename, content type, and size. Folder structure from Corteza does not map directly to Salesforce libraries; we either flatten into a single library or create Salesforce libraries named after the Corteza module for organizational clarity depending on customer preference. Files are linked to parent records via ContentDocumentLink.

Corteza workflow definitions do not migrate to Salesforce Flow because the automation models are architecturally incompatible. We capture all active Corteza workflows during the discovery phase — including triggers, conditions, actions, and Prompt or Delay step configurations — and deliver a written Flow inventory document that maps each Corteza workflow to a recommended Salesforce Flow type (record-triggered, scheduled, or screen) with a rebuild guide. The customer or a Salesforce partner implements the rebuilt flows post-migration. Note that Corteza workflows using Prompt or Delay steps become asynchronous and can no longer invalidate transactional actions; this limitation is documented in the handoff for the rebuild team.

Corteza organizes CRM content into namespaces that can be exported and imported between instances. Namespace configuration (pages, module layouts, access control rules) does not migrate directly to Salesforce. We document the namespace structure during discovery, flag orphaned page references (a documented Corteza export failure condition where pages referencing deleted modules prevent namespace export from completing), and clean up these broken links before attempting any Corteza export. The resulting documentation of page layouts and module configurations is delivered as a written reference for the customer's Salesforce admin to implement in Lightning Page Builder or Experience Cloud as applicable.