Migrate from SYDLE ONE to Salesforce Service Cloud

SYDLE ONE Contact records with standard fields (name, email, phone, lifecycle stage) and custom properties map directly to Salesforce Contact. The email field serves as the dedupe key during import. We flag any custom Contact fields that require a new custom field in the destination org before migration begins. Account-Contact relationship is preserved by resolving the SYDLE ONE Account reference to the destination AccountId.

SYDLE ONE Account/Company records map to Salesforce Account. The SYDLE ONE company identifier becomes an external ID field in Salesforce for lookup resolution during Contact and Case import. Account is loaded before Contacts to satisfy the required AccountId lookup.

SYDLE ONE Service Desk Tickets map to Salesforce Case. SYDLE ONE status values (Open, In Progress, Resolved, Closed, or any custom status names) vary by tenant configuration, so we build an explicit status-to-Status mapping table during scoping. Ticket priority maps to Case Priority. Ticket owner maps to Case OwnerId via User email resolution. Each SYDLE ONE ticket thread (comments, internal notes) migrates as CaseComments attached to the Case.

SYDLE ONE ECM Documents migrate to Salesforce ContentVersion (file content) and ContentDocument (version-aware document record). We capture the document's metadata — owner, created date, last modified date — and write a ContentDocumentLink to the parent Contact, Account, or Case using the association metadata captured during export. Without this linkage metadata preserved in the export, documents become orphaned files.

SYDLE ONE BPM Process definitions are exported as structured JSON capturing BPMN notation, form layouts, and execution rules. These do not migrate to Salesforce Flow because the models are architecturally different (BPMN vs record-triggered Flow). We deliver a written Process Inventory listing every active Process, its trigger conditions, form fields, assignee logic, and a recommended Salesforce Flow equivalent for the customer's admin to rebuild.

SYDLE ONE Service Portal page configurations and routing rules are exported as JSON. Because routing rules reference Ticket and Contact IDs that change during migration, these configurations cannot be re-imported directly. We deliver a written Service Portal Inventory with page structure, navigation maps, and routing rule logic for rebuilding in Salesforce Experience Cloud or as a custom Service Cloud console configuration.

SYDLE ONE Chatbot flows built for WhatsApp, Facebook, Telegram, and other channels store as process-like JSON structures. We export the flow logic, intent definitions, and response templates as a written Chatbot Inventory. Rebuild in Salesforce uses Einstein Bot or a third-party chatbot platform (LivePerson, Quiq) with the inventory as the specification.

SYDLE ONE Deal records with stage, value, owner, and close date map to Salesforce Opportunity. SYDLE ONE pipeline stage names map to Salesforce StageName values via an explicit stage-mapping table. Opportunity owner resolves via User email matching. If the destination org includes Sales Cloud alongside Service Cloud, we preserve the full Opportunity history.

File attachments on any SYDLE ONE record (Contact, Account, Ticket, Process) migrate as ContentVersion records with a ContentDocumentLink to the parent record. We write a cross-reference mapping table during export that records the original SYDLE ONE record type, record ID, and attachment filename so that the lookup resolves correctly post-migration.

Tags applied to Contacts, Accounts, Tickets, and Processes in SYDLE ONE migrate as label sets. We normalize tag names that contain special characters or spaces before importing to avoid Salesforce field validation errors. The customer chooses at scoping whether tags map to Salesforce Topics (for knowledge-content classification) or to custom multi-select picklist fields on the relevant object.

SYDLE ONE HR Recruitment (available on Planet and Star tiers) includes Candidate records, job openings, and application statuses. These map to Salesforce custom objects with a recruitment-specific data model if no dedicated ATS is in scope. If the customer has a target ATS (Greenhouse, Lever, Workday), we migrate Candidate and Opening records to the ATS via its native import API and deliver an inventory for the ATS admin.

SYDLE ONE Agile PM Projects, sprints, and task records migrate to Salesforce custom objects or to Salesforce Tasks with a Project custom object as the parent. Sprint velocity and burndown history require a separate export sequence to preserve historical data integrity because these metrics reference calculation formulas rather than raw records.