Migrate from Vivantio to Salesforce Service Cloud

Vivantio Tickets map to Salesforce Case. Each Vivantio ticket type (Incident, Problem, Change, Service Request, and unlimited custom types) becomes a Salesforce Case Record Type, with its own Page Layout and Status values migrated as picklist entries. Priority and Impact/Urgency matrices map to Case Priority and a custom Case Impact field. Closed ticket status values migrate with their original resolved timestamp preserved as ClosedDate.

Vivantio Contacts (also called Callers) map to Salesforce Contact. The Contact is the parent record for Case via the ContactId field. We canonicalise terminology during mapping and resolve any AD synchronisation links to prevent duplicate Contact creation in Salesforce. If Vivantio uses a shared Contact record across multiple Companies, we flag this for manual resolution since Salesforce enforces a primary Account relationship.

Vivantio Organisations map to Salesforce Account. The organisation-to-account graph is preserved so the destination reflects the same customer hierarchy. We use Organisation name as the dedupe key during import. Account is created before any Contact or Case import so that the AccountId lookup is satisfied at the moment of insert.

Vivantio Agents map to Salesforce User records. We resolve Agents by email match against the Salesforce User table. Concurrent license holders in Vivantio (agents sharing a pooled seat) are flagged during scoping and require explicit Salesforce User provisioning decisions. Any Agent without a matching User goes to a reconciliation queue for the customer's admin before record import resumes.

Vivantio Teams route tickets to the correct resolver group. We map each Team to a Salesforce Public Group or Case Queue depending on the customer's routing model preference. Team membership migrates as GroupMember records. Workload balancing rules from Vivantio are documented as a written configuration note; Salesforce handles equal-case distribution natively within Queues.

Vivantio Knowledge Articles migrate to Salesforce Knowledge. Article body, categories, status, and publication date transfer. Public/private visibility from Vivantio maps to Salesforce Knowledge visibility settings (internal vs customer-facing) controlled at the article and data category level per profile. Articles in draft status migrate as Draft in Salesforce Knowledge. We note any embedded images for re-upload as Salesforce ContentDocument records.

Vivantio SLA configurations including priority-based response and resolution windows map to Salesforce Entitlement and Business Hours objects. We preserve the priority matrix, First Response Time and Resolution Time targets, and any business-hour calendars attached to the SLA. Business Hours are reconfigured in Salesforce as distinct calendar entries (holidays, shifts) per queue or entitlement. Multiple SLA tiers per customer map to multiple Entitlement records per Contact or Account.

Modern Vivantio custom fields on Tickets, Contacts, and Organisations map to Salesforce custom fields on the equivalent object. We use Salesforce field types that best match Vivantio's field type (picklist, text, number, date, checkbox, etc.). All custom fields are pre-created in the destination schema before data import using the Salesforce metadata API or change set into a Sandbox first.

Legacy custom fields from Vivantio Service Desk cannot be used in Salesforce Business Rules, Roles, or the Self Service Portal, and are not supported in the FLEX UI. We detect legacy field types during the discovery scan and present them as explicit migration items that must be remapped to modern field equivalents or archived before the load. If imported as-is, they will result in broken Flow triggers and permission set failures in Salesforce. This is one of the highest-severity migration risks for teams migrating from older Vivantio Service Desk instances.

Files attached to tickets, articles, and contacts are extracted, downloaded, and re-uploaded to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case, Contact, or Account. Large file batches are chunked to avoid API timeout. We preserve the original filename and content type. Attachments over Salesforce's 25 MB per file limit are flagged for the customer to store in an external DMS with a link stored in Salesforce.

Vivantio ticket conversation threads (agent responses, customer replies, internal notes) map to Salesforce EmailMessage records linked to the parent Case. We preserve the original timestamp, author (Agent or Contact), direction (inbound/outbound), and body content. Internal-only comments from Vivantio migrate as EmailMessage records with IsClientPrivate set to false but with a custom field indicating the internal-only origin for admin reference.

Vivantio Workflows and Business Rules drive ticket routing, escalations, and automated actions but are not migratable as code to Salesforce Flow due to structural differences in trigger models and action types. We do not migrate them. We deliver a written inventory of every active Vivantio Workflow and Business Rule with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration. Legacy custom fields referenced in Business Rules are flagged in the inventory as requiring a field substitution step before the Flow is activated.