Migrate from Stonly to Zendesk

Stonly Guides map to Zendesk Guide Articles. We export full step text, media attachments (images and embedded video URLs), branching logic as structured JSON, custom CSS, and in-guide variable configurations. Since Zendesk does not natively support Stonly's branching decision-tree format, we preserve the complete branching map in the export manifest so the authoring team can recreate decision paths manually in the destination. Guide published status maps to Article draft vs. published. Multi-language guides export as separate Article records tagged with the Zendesk locale identifier.

Each Stonly Knowledge Base maps to a Zendesk Help Center. We export the KB hierarchy including category names, descriptions, slug structure, ordering, and the mapping of which guides belong to each category. Zendesk Help Centers support multiple locales per article but share a single section-category tree; we map the Stonly KB's top-level structure to Zendesk Categories and any sub-categories to Sections. If the customer maintains multiple Stonly KBs, we discuss whether to consolidate into one Zendesk Help Center or create separate Help Centers per locale or brand.

The Stonly Widget is a site-side JavaScript snippet that Stonly does not expose as a portable configuration file. We document the widget installation scope (which sites, which pages, which KB scope) in the migration manifest so the destination team can deploy the Zendesk Web Widget or Sunshine Conversations Conversations SDK. Widget-level custom properties (display name, default language, brand colors) are exported as key-value pairs and documented for manual re-entry in the Zendesk Web Widget admin panel. This is not an automated migration step; we provide the precise installation scope and configuration values required.

Stonly Triggers define when and to whom guides are shown based on URL conditions, user actions, or user property values. We export trigger rules as structured data including targeting criteria, guide assignment, and delivery priority. Zendesk Automations support ticket creation conditions and agent notifications but do not natively deliver Help Center articles to end-users based on property conditions. If the customer uses Sunshine Conversations (Zendesk's messaging layer), we can discuss mapping targeting rules to Conversations Segments; otherwise, we document the trigger logic as a written specification for the Zendesk admin to implement with available tools or a third-party personalization layer.

Stonly custom user properties (such as subscription level, plan tier, account type, or next billing date) used for guide targeting export with property names, data types, and any value mappings. These map to Zendesk Sunshine Conversations User Profile Fields if the destination uses the Conversations SDK. If the customer does not license Sunshine Conversations, we document the property schema and recommended implementation path (Zendesk User Fields or organization fields) rather than leaving the targeting data orphaned.

Stonly User Events track actions like purchased_product, created_ticket, or feature_enabled that trigger guide delivery or branching logic. We export event names, event schemas, and event-based guide routing rules as structured JSON. Zendesk Sunshine Conversations supports event tracking via the Conversations SDK, but without Conversations, there is no native equivalent for event-triggered content delivery in Zendesk Guide. We document every event and its associated guide routing so the destination team can either implement event tracking via Conversations or document the event logic as a manual reference for agents.

Stonly's AI-powered search bar surfaces answers from guide content with configurable query routing and fallback behavior. We export the AI Answer configuration including the knowledge base scope and any custom answer routing rules. Zendesk AI Answer Bot (available on Suite Professional and above, or as an add-on) uses a different AI model and requires a separate content indexing process. We document the Stonly AI Answer configuration as a written spec so the Zendesk admin can configure Answer Bot to use the migrated Help Center articles as its knowledge source.

Stonly provides full-path analytics including guide completion rates, step-level drop-offs, and usage trends by guide, path, and user segment. We export analytics snapshots as CSV at the time of migration, capturing the customer's historical usage baseline. Note that historical path-level analytics cannot be programmatically re-imported into Zendesk Explore; Explore provides forward-looking live reporting only. We recommend the customer reviews the CSV baseline before migration cutover so they retain the Stonly-era benchmark.

Stonly team members include names, email addresses, assigned roles (Admin, Editor, Viewer), and KB-level access permissions. We export the team roster as CSV. Role name mappings between Stonly's permission model and Zendesk's Agent, Admin, and Light Agent roles are documented in the migration manifest. Zendesk user provisioning is a manual step that the customer's Zendesk admin performs before or during migration; we flag any roles that require specific Zendesk permissions (such as Guide editing) in the manifest.

If the customer used Stonly's PDF export feature (Business or Enterprise tier only), we document the guide IDs and names that were exported. Zendesk Guide articles include a built-in PDF export available on all plans, so individual article PDFs can be regenerated in Zendesk by the content team post-migration. We flag any guides that were regularly exported as PDFs so the customer can confirm those articles are migrated and verified in Zendesk first.