Helpdesk migration
Field-level mapping, validation, and rollback between Vivantio and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
Vivantio
Source
Zoho Desk
Destination
Compatibility
8 of 14
objects map 1:1 between Vivantio and Zoho Desk.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from Vivantio to Zoho Desk is a schema translation across two fundamentally different helpdesk models. Vivantio organises around Teams, Roles, and unlimited ticket types with deep workflow configuration; Zoho Desk uses a Department-centric hierarchy with Business Rules, Workflow Rules, and Time-Based Rules scoped per module and per department. We map each Vivantio ticket type to a Zoho Desk department with its own ticket form and status values, resolve legacy Vivantio Service Desk custom fields that cannot be used in Zoho Desk Business Rules, and sequence the load as Agents first, then Accounts, Contacts, Tickets, SLA Policies, Knowledge Articles, and Attachments last. Workflows, Business Rules, and Self Service Portal configuration do not migrate as code; we deliver a written inventory for your admin to rebuild in Zoho Desk's rule builder.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Vivantio object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Vivantio
Agent
Zoho Desk
Agent
1:1Vivantio Agents map directly to Zoho Desk Agents. We resolve by email match against the destination Zoho Desk agent list. Any Vivantio Agent without a matching Zoho Desk Agent is held in a reconciliation queue for the customer's admin to provision before record import resumes. Concurrent license holders from Vivantio are flagged separately since Zoho Desk does not have a concurrent license model; each active agent maps to a named Zoho Desk seat.
Vivantio
Organisation
Zoho Desk
Account
1:1Vivantio Organisations map to Zoho Desk Accounts with their name, phone, email, website, industry, and address fields preserved. The organisation-contact association graph is maintained so each Account in Zoho Desk links to its related Contacts at migration time. Account is loaded before Contacts so the AccountId lookup is satisfied on Contact insert.
Vivantio
Customer / Caller / Contact
Zoho Desk
Contact
1:manyVivantio Customers (also called Callers or Clients depending on the instance) are canonicalised as Zoho Desk Contacts. Each Contact record is linked to its parent Account via AccountId. Phone, email, mobile, address, and social profile fields migrate directly. The Vivantio distinction between Customer and Caller types is preserved in a custom field original_type__c on the Zoho Desk Contact for audit purposes.
Vivantio
Ticket (all types)
Zoho Desk
Ticket
1:1All Vivantio ticket types (Incident, Problem, Change, Service Request, and unlimited custom types) map to Zoho Desk Tickets. Each Vivantio ticket type maps to a Zoho Desk Department, and the type name is preserved in a custom field original_type__c on the ticket. Priority, status, and category values are mapped to Zoho Desk's status and priority picklists. Teams from Vivantio are mapped to Zoho Desk Teams via a team lookup field. SLA timers are recalculated based on the destination SLA calendars at migration time, not copied as static timestamps.
Vivantio
Custom Fields
Zoho Desk
Custom Fields
lossyVivantio custom field types (Single Line Text, Multi Line Text, Drop Down List, Radio Button, Check Box, Check Box List, Date Picker, Date and Time Picker) map to Zoho Desk equivalent data types (string, textarea, picklist, radio, checkbox, multi-checkbox, date, datetime). We detect legacy Vivantio Service Desk custom fields during discovery and remap them to modern Zoho Desk custom fields; legacy fields that cannot function in Business Rules or Self Service Portal are flagged as requiring archive or rebuild in the mapping document.
Vivantio
Knowledge Article
Zoho Desk
Knowledge Base Article
1:1Vivantio Knowledge Articles (internal/private and customer-facing/public) map to Zoho Desk Knowledge Base articles. Public/private visibility is mapped to Zoho Desk's Article Status (Draft, Published, Archived). Article body, categories, publication date, and author information are preserved. Note: Zoho Desk's native import tools do not migrate knowledge base attachments. We handle KB attachments as a separate migration item, downloading each file and re-attaching it to the correct article in Zoho Desk using the Zoho Desk REST API. Article publication dates are preserved as custom fields if the native import resets them to migration date.
Vivantio
Team / Resolver Group
Zoho Desk
Team
lossyVivantio Teams (resolver groups with workload balancing rules) map to Zoho Desk Teams. Team membership and routing rules are documented in the mapping inventory. Vivantio's workload balancing configuration does not have a direct Zoho Desk equivalent, so it is noted as a configuration item for the customer's admin to rebuild in Zoho Desk's team settings. Teams must be created before Agents in Zoho Desk so that the Team assignment on Agent records is satisfied.
Vivantio
SLA Policy
Zoho Desk
SLA Policy
1:1Vivantio SLA configurations including priority-based response and resolution windows and business-hour calendars map to Zoho Desk SLA Policies scoped per department. The priority matrix (P1/P2/P3/P4 to First Response Time and Resolution Time) migrates directly. Holiday lists from Vivantio are recreated in Zoho Desk's business-hour configuration. Note: Zoho Desk's SLA limits vary by pricing plan (e.g., number of SLA policies per department) and the destination plan tier is verified during scoping.
Vivantio
Workflow / Business Rule
Zoho Desk
Business Rule, Workflow Rule, Time-Based Rule
lossyVivantio Business Rules (routing, escalations, and automated actions) do not migrate as code to Zoho Desk because the rule engine architecture is structurally different. Vivantio rules are field-triggered with global scope; Zoho Desk splits automation across Business Rules (filter-based triggers), Workflow Rules (ticket actions and email notifications), and Time-Based Rules (resolution reminders). We deliver a written inventory of every active Vivantio Workflow with its trigger conditions, actions, and a recommended Zoho Desk equivalent (Business Rule, Workflow Rule, or Time-Based Rule per module and department). The customer's admin rebuilds the rules in Zoho Desk's rule builder. Legacy custom fields from Vivantio Service Desk are explicitly flagged as incompatible with any Zoho Desk rule rebuild.
Vivantio
Self Service Portal
Zoho Desk
Customer Portal (Zoho Desk)
lossyVivantio's multiple Self Service Portals (each with its own Service Catalog and request forms) map to Zoho Desk's Customer Portal structure. Portal form definitions, ticket submission forms, and category trees are documented in the mapping inventory. Visual branding elements (logos, colour schemes, CSS) do not migrate and are noted as requiring manual recreation. Zoho Desk's single-portal-per-instance model differs from Vivantio's multi-portal approach, so the portal strategy (combining all Vivantio portals into one or separating by department) is a scoping decision made with the customer.
Vivantio
Attachment
Zoho Desk
Attachment
1:1File attachments linked to tickets, contacts, accounts, and knowledge base articles are extracted from Vivantio, chunked in batches to avoid API timeout, and re-uploaded to Zoho Desk via the REST API with the correct parent record reference. Large file batches are processed in 50-file chunks with exponential backoff on rate limit responses. Note: Knowledge base article attachments require special handling because Zoho Desk's native migration tools (Zwitch and CSV import) do not support KB attachment migration; we treat KB attachments as a separate migration phase with explicit record-level tracking.
Vivantio
Asset
Zoho Desk
Asset
1:1Vivantio Assets (linked to tickets and organisations) map to Zoho Desk Assets where the destination plan supports the Asset module. Asset name, type, serial number, purchase date, and linked organisation migrate as typed fields. Assets without a matching Zoho Desk Asset (plan tier limitation) are mapped to a custom field original_asset_id__c on the parent ticket for reference.
Vivantio
Company Hierarchy
Zoho Desk
Account Hierarchy
1:1Vivantio Organisation hierarchies (parent-child relationships between Organisations) map to Zoho Desk Account hierarchies via the Parent Account lookup field. The top-level organisation becomes the root Account, and child organisations are linked via Parent_Account_ID. We preserve the full hierarchy depth during migration so the Account tree in Zoho Desk reflects the Vivantio structure.
Vivantio
Survey / CSAT
Zoho Desk
Customer Satisfaction (CSAT)
lossyVivantio caller surveys (CSAT ratings and free-text responses linked to tickets) map to Zoho Desk's Customer Satisfaction module where available on the destination plan. Survey question text is preserved in a custom field for rebuild in Zoho Desk's CSAT configuration. Vivantio's custom survey form definitions are documented in the mapping inventory for manual recreation in Zoho Desk.
| Vivantio | Zoho Desk | Compatibility | |
|---|---|---|---|
| Agent | Agent1:1 | Fully supported | |
| Organisation | Account1:1 | Fully supported | |
| Customer / Caller / Contact | Contact1:many | Fully supported | |
| Ticket (all types) | Ticket1:1 | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required | |
| Knowledge Article | Knowledge Base Article1:1 | Fully supported | |
| Team / Resolver Group | Teamlossy | Fully supported | |
| SLA Policy | SLA Policy1:1 | Fully supported | |
| Workflow / Business Rule | Business Rule, Workflow Rule, Time-Based Rulelossy | Fully supported | |
| Self Service Portal | Customer Portal (Zoho Desk)lossy | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Asset | Asset1:1 | Fully supported | |
| Company Hierarchy | Account Hierarchy1:1 | Fully supported | |
| Survey / CSAT | Customer Satisfaction (CSAT)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Vivantio gotchas
Legacy custom fields are migration-critical
API rate limits are not publicly documented
AD connector instance name must match on migration
Scheduled Export requires your own SQL target
Zoho Desk gotchas
Agent email identity determines comment ownership after migration
Blueprints and SLA policies do not export via API
File upload capped at 10GB per migration batch
Tier-gated export and migration capabilities
Inbound migration is two-phase with a hard Phase 2 cutoff
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the Vivantio instance across all active modules: Agents and Teams with Roles and concurrent license flags, Organisations and their hierarchy, Contacts with their account links, all ticket types (Incident, Problem, Change, Service Request, and custom), Custom Fields with field type and usage detection (including legacy Vivantio Service Desk field detection), SLA policies with priority matrices and business-hour calendars, Knowledge Articles with article categories and publication status, and Self Service Portal structure. We also verify the Vivantio API availability for the export phase and confirm the target Zoho Desk plan tier to validate SLA policy limits and rule capacity. The discovery output is a written migration scope document with the record count per object, a list of detected legacy custom fields, and the recommended Zoho Desk department structure.
Schema design and department mapping
We design the Zoho Desk destination schema before any data moves. This includes provisioning Zoho Desk Departments (mapped from Vivantio ticket types), Roles (mapped from Vivantio Roles with their permission levels), ticket status picklist values (mapped from Vivantio status values per type), custom fields with Zoho Desk field types matched to Vivantio field types, SLA Policies per department with holiday lists and business-hour calendars from Vivantio, and Teams with membership and routing configuration documented from Vivantio. Legacy Vivantio Service Desk custom fields are flagged for exclusion from Business Rules in the mapping document. Schema is validated in a Zoho Desk sandbox before production migration begins.
Sandbox migration and reconciliation
We run a full migration into a Zoho Desk sandbox environment using production-like data volume. The customer's Vivantio administrator reconciles record counts (Agents in, Accounts in, Contacts in, Tickets in, Articles in), spot-checks 25-50 random records against the Vivantio source for field-level accuracy, validates that ticket type-to-department mapping is correct, and confirms that SLA policy names and priority thresholds match the Vivantio configuration. The customer signs off the sandbox validation before production migration begins. Any mapping corrections are applied in this phase.
Agent and team provisioning
We extract every distinct Vivantio Agent and map them to Zoho Desk Agents by email match. Vivantio Teams are provisioned in Zoho Desk as Teams with their membership documented. Any Vivantio Agent without a matching Zoho Desk Agent is held in a reconciliation queue for the customer's Zoho Desk administrator to create before the production migration resumes. This step is a hard dependency: Agents must exist in Zoho Desk before Tickets can be assigned. Teams must be created before Agents in Zoho Desk so that the Team field on Agent records is satisfied.
Production migration in dependency order
We run production migration in the following record-dependency order: Agents (validated and provisioned), Accounts (from Vivantio Organisations with hierarchy preserved), Contacts (with AccountId resolved and original type preserved), Tickets (with TeamId, AgentId, priority, status, and original type mapped; conversation threads and inline images preserved via REST API; Created_Time set from source timestamps), SLA Policies (per department with holiday lists), Knowledge Articles (with categories and publication status; article attachments handled as a separate phase), and Attachments (ticket attachments, contact attachments, and KB article attachments chunked and uploaded via REST API with parent record resolution). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta migration, and workflow inventory handoff
We freeze Vivantio write access during the cutover window, run a final delta migration of any records created or modified during the migration window, validate record counts against the source, then enable Zoho Desk as the system of record. We deliver the Workflow and Business Rule inventory document to the customer's Zoho Desk administrator, specifying which Vivantio rules map to Zoho Desk Business Rules, Workflow Rules, or Time-Based Rules, and flagging any legacy custom fields that cannot be used in Zoho Desk automation. We do not rebuild Vivantio workflows as Zoho Desk workflows inside the migration scope; that is a separate engagement. We support a one-week hypercare window where we resolve reconciliation issues raised by the support team during the first week of live operation.
Platform deep dives
Vivantio
Source
Strengths
Weaknesses
Zoho Desk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Vivantio and Zoho Desk.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Vivantio: Not publicly documented. Vivantio's API documentation lives at webservices-na01.vivantio.com/Help and does not publish a hard per-minute limit. We pace our exports and pre-coordinate any large sync with Vivantio support..
Data volume sensitivity
Vivantio doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Vivantio to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your Vivantio to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Vivantio
Other ways to arrive at Zoho Desk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.