Migrate from Novo Customer Support to Salesforce Service Cloud

Novo Tickets map directly to Salesforce Case. Ticket status (Open, Pending, Resolved, Closed) maps to Case Status picklist values that we configure during schema setup. Priority, assignee (resolved to Salesforce User via Agent mapping), custom fields, and tags migrate 1:1 where field types are compatible. We audit custom ticket field types before migration and handle conversions such as multi-select dropdown to multi-select picklist, date format alignment to Salesforce ISO8601, and checkbox to boolean.

Novo Customer records map to Salesforce Contact. Email, name, phone, and address fields migrate directly. The customer's role-based permissions in enterprise Novo deployments with AD field mapping require translation to Salesforce Contact ownership and sharing model. Any custom fields on Customer (such as account type or tier flags) map to custom Contact fields __c on the destination org.

Novo Company records map to Salesforce Account. Company name and domain become Account Name and Website. The Company-to-Contact relationship in Novo (where multiple customers can link to one company) maps to the Account-to-Contact parent relationship in Salesforce. We create the Account before importing Contacts so that the AccountId lookup is satisfied at the moment of Contact insert.

Novo Agents map to Salesforce Users. We resolve each Agent by email match against the destination org's User table. Role-based permissions from Novo (role names and OU structures) translate to Salesforce Profiles and Permission Sets during scoping. Any Agent without a matching User record goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Novo Teams group agents for routing and reporting. We map Teams to Salesforce Queues with matching membership. Where the destination org does not use Queues, agents are assigned individually and Team membership is preserved as a custom field on the User record. Queue configuration is validated in Sandbox before production migration.

Each Novo Ticket carries a threaded conversation history including agent and customer replies. We migrate full conversation logs in chronological order, preserving timestamps and author attribution, as Salesforce EmailMessage records linked to the parent Case. EmailMessage Body, From, To, and CreatedDate preserve. We use the Salesforce REST API for EmailMessage insertion because the Bulk API does not support this object.

File attachments on tickets and conversations migrate as ContentVersion (file binary) and ContentDocument records linked to the Case via ContentDocumentLink. Large attachment batches require chunked transfer; we flag any size restrictions during scoping and handle files above 25 MB through chunked multipart upload. Attachment filename and MIME type preserve as ContentVersion Title and FileType.

Knowledge Base articles and their category hierarchy migrate as Lightning Knowledge Articles. We map Novo article internal/external visibility flags to Salesforce article status values (Draft, Published, Archived). Category hierarchies become Salesforce Data Categories or custom taxonomy fields depending on the destination org's Knowledge configuration. Article body HTML migrates to the Article's Summary and Body rich text fields.

Novo KB category hierarchies map to Salesforce Data Category Groups and Categories under Lightning Knowledge. We preserve the parent-child structure of the category tree. If the destination org uses a flat taxonomy model instead, we flatten the hierarchy into a custom picklist field on the Knowledge Article.

Tags applied across tickets, customers, and articles in Novo migrate as Salesforce Topics with TopicAssignment records linked to the parent object. Alternatively, if the customer prefers a field-based taxonomy, we map tags to a multi-select picklist custom field on Case. The customer chooses the tag strategy during scoping.

Custom fields on Novo Tickets introduce field-level mapping requirements that we surface in the field map during technical audit. We audit the custom field schema before migration, generate a typed field map for Salesforce (text, number, date, picklist, checkbox, etc.), and handle type conversions where the destination field type differs. Validation rules on the destination org are checked against migrating values to avoid silent rejections.