Migrate from Stonly to Zoho Desk

Stonly Guides map to Zoho Desk Knowledge Base articles. We export the full guide content including step text, media attachments, custom CSS, and in-guide variable configurations as structured JSON, then reconstruct each step as a distinct article section in Zoho Desk. The mapping preserves article title, body content, and internal links. Branching logic does not migrate as executable code — we export the complete branching tree as a JSON map and a visual-reference document the content team uses to re-author decision paths using Zoho Desk article sections or Blueprint processes. Media attachments (images, screenshots) migrate as article attachments; video links migrate as hyperlinks in the article body.

Stonly Knowledge Bases map to Zoho Desk Knowledge Bases. We export the full KB hierarchy including category names, descriptions, slug structure, ordering, and the guide-to-category assignment map. Zoho Desk supports multiple help desk brands under a single account, which maps from Stonly's multi-KB structure for organizations managing multiple product knowledge bases.

Stonly category hierarchy maps to Zoho Desk Knowledge Base categories. We export category names, descriptions, parent-child relationships, and ordering as a category tree manifest. Zoho Desk category creation is done via the KB admin UI or API, and we provide the ordered category list with parent references for manual recreation in the destination.

Stonly branching step logic (decision trees with multiple paths based on user choices) is exported as a structured JSON branching map. Zoho Desk does not natively support interactive branching within articles. We document the full decision tree — step sequence, branching conditions, and path outcomes — as a reference document. The content team recreates the logic either as separate targeted articles linked from a parent article, or as a Blueprint process if the guide applies to ticket workflows. This re-authoring step is manual and cannot be automated.

Stonly guide media attachments migrate as Zoho Desk article attachments. We extract all images and screenshots associated with guide steps and re-attach them to the corresponding Zoho Desk article. Image filenames are preserved; alt text migrates as attachment description where Zoho Desk field allows.

Stonly custom user properties (e.g., subscription level, account type, next billing date) used for guide targeting export with their complete schema including property names, data types, and value mappings. Zoho Desk custom fields are scoped per department, not globally across the KB. We document this structural difference in the mapping manifest and flag each Stonly property that requires department-level custom field creation in Zoho Desk. Properties used for guide personalization without a Zoho Desk equivalent are noted for the admin to handle via CRM attributes or Zoho CRM field sync.

Stonly user events (e.g., purchased_product, created_ticket) track actions that trigger guide delivery. These event definitions and event-based routing rules export as a structured data manifest. Zoho Desk does not have a native user-event tracking model for guide delivery. We document the event schema and routing rules so the Zoho Desk admin can evaluate Zoho Workflow rules, Zoho CRM alerts, or third-party event-tracking integration as replacement triggers.

Stonly AI Answers configurations — including knowledge base scope, query routing rules, and fallback behavior — export as a structured manifest. Zoho Desk's Zia AI handles sentiment analysis, auto-tagging tickets, smart knowledge base search, and proactive customer notifications. Zia does not natively replicate Stonly's guided walkthrough routing or context-aware guide delivery based on user properties. We document the gap and note that AI Answer routing is a candidate for Zoho Creator custom application or a third-party chatbot layer if guided walkthrough delivery is required post-migration.

Stonly triggers define when guides appear based on URL, user actions, or user property conditions. We export trigger rules as structured data with targeting criteria, guide assignments, and activation conditions. Zoho Desk Blueprint and Workflow Rules are different automation models — Blueprint enforces a ticket process with stages and mandatory steps; Workflow Rules fire on ticket field changes. We document each Stonly trigger with its Zoho Desk equivalent (Blueprint for guided ticket flows, Workflow Rule for event-based actions) in the automation inventory for manual rebuild.

Stonly analytics including guide completion rates, step-level drop-offs, and usage trends export as CSV at the time of migration. Historical analytics cannot be re-ingested into Zoho Desk's reporting module, which tracks KB article views and feedback ratings from its own event model. We deliver the analytics CSV as a standalone file alongside the migration manifest so the customer retains the historical data for reference or for import into a separate BI tool.

Stonly team members export with their names, email addresses, assigned roles (Admin, Editor, Viewer), and KB-level access permissions as a CSV roster. Zoho Desk roles are Agent, Light Agent, and Support Administrator. We map Stonly Admin and Editor roles to Zoho Desk Support Administrator for migration scope, noting that the admin may want to refine Light Agent permissions post-migration. Agent provisioning in Zoho Desk requires the admin to create agents with matching emails and assign department access.

The Stonly Widget is a site-side JavaScript snippet that launches guides on external websites. Stonly does not expose widget configuration as a portable export. We document the current widget installation method, the pages where it is deployed, and any custom display settings. Zoho Desk's ASAP (Advanced Self-Service and Portal) plug-in is the equivalent help center embed, deployable from Zoho Desk setup. We flag the widget gap in the mapping manifest and provide the ASAP installation snippet for the destination team to deploy in place of the Stonly widget.