Migrate from Stonly to Gorgias

Stonly Guides map to Gorgias Knowledge Base Articles. We export the full guide content including step text, media attachment URLs, custom CSS blocks, in-guide variable values, and guide metadata (slug, URL path, published status, targeting rules). The guide's category hierarchy in Stonly maps to Gorgias Knowledge Base category structure. Branching logic (decision-tree paths) is exported as structured JSON and reconstructed as linked article sequences or as Gorgias Flow rules that replicate the conditional branching logic.

Stonly Knowledge Bases map directly to Gorgias Knowledge Bases as the top-level organizational container. We export KB name, description, slug structure, ordering, and the full category-subcategory hierarchy. The mapping of which guides live under which categories transfers as article placement within Gorgias KB categories. Multi-language Stonly KBs map to Gorgias multi-language KB configuration (Gorgias supports language selection per article).

Stonly's branching decision tree is the most significant structural difference from Gorgias. We export the full branching map as structured JSON (step name, parent step, child paths, conditional criteria, step text, media). In Gorgias, we create a linear or linked-article sequence where each article represents a decision path, and we create Gorgias Flows with conditions that route the customer to the appropriate article based on their selections. The customer's content team reviews and finalizes the branching logic in the Gorgias Flow builder because branching re-authoring requires editorial judgment on path naming and decision criteria.

Stonly Triggers (URL-based, property-based, or event-based guide targeting rules) map to Gorgias Automations and Macros. We export trigger name, condition type, condition criteria (URL contains, user property equals, event fired), and the guide assigned to each trigger. Triggers with a single guide assignment map to a Gorgias Macro. Triggers with complex multi-condition logic map to Gorgias Automations with a condition group. The customer configures trigger-to-automation mapping in Gorgias during the automation rebuild phase.

Stonly custom user properties (subscription level, account type, plan tier, next billing date) map to Gorgias Customer Custom Fields. We export the complete property schema including names, data types, and value mappings, then create matching Gorgias Custom Fields with the same type (string, number, boolean, date) on the Customer object. During migration, we populate these fields on existing Gorgias Customer records if the customer has an existing Gorgias instance. If no Customer record exists, we document the property schema for the customer's admin to apply during onboarding.

Stonly User Events (tracked actions like purchased_product, created_ticket, upgraded_plan) map to Gorgias event-tracking integrations and Automation triggers. We export the event names, event schemas, and any event-based guide routing rules as structured data. In Gorgias, events are captured through the Gorgias app integration (for Shopify, Magento, or BigCommerce events) or via the Gorgias REST API. The event routing logic that sent customers down specific guide paths in Stonly becomes Gorgias Automation rules triggered by those events.

The Stonly Widget is a site-side JavaScript snippet that Stonly does not expose as a portable configuration file. It cannot be programmatically extracted and re-deployed as a Gorgias widget. We document every Stonly widget placement point (URL path, page element, trigger context) in our migration manifest. The customer's developer team installs the Gorgias Chat widget using the Gorgias Chat settings panel and configures the Chat trigger conditions to replicate the original Stonly targeting behavior. The Stonly widget snippet is removed from the site at cutover.

Stonly AI Answers (the AI-powered search bar surfacing guide content) does not have a programmatic export. We export the list of guides included in the AI Answers scope, the query routing rules, and fallback behavior as structured data. The customer's Gorgias admin re-configures AI-powered self-service by selecting the migrated Knowledge Base Articles in the Gorgias AI Agent settings and defining the same FAQ scope. We deliver a gap analysis noting any Stonly AI Answer features that do not have a direct Gorgias equivalent.

Stonly full-path analytics (guide completion rates, step-level drop-offs, usage trends, view counts by guide and time period) export as CSV snapshots at migration time. We capture the most recent 12 months of analytics data where available. These CSV snapshots cannot be programmatically re-imported into Gorgias because Gorgias does not expose a bulk analytics import API. We deliver the analytics CSV to the customer's admin team for manual record-keeping or for import into a BI tool like Looker or Google Sheets.

Stonly team members (name, email, role: Admin/Editor/Viewer, KB-level access permissions) export as CSV. Stonly Admin and Editor roles map to Gorgias Agent with appropriate permission sets. Stonly Viewer role has no Gorgias equivalent because Gorgias's permission model is agent-centric (admin/agent/viewer on the helpdesk, not on the knowledge base). We document the role mapping and flag that Gorgias KB-level access permissions require manual configuration post-migration.

Images, screenshots, and documents attached to Stonly guide steps export as files with their original URLs and metadata. We download media assets and re-upload them to Gorgias Article media attachments, preserving alt text from the Stonly step description. Any externally hosted media (images linked to third-party CDNs) are re-hosted or linked directly in Gorgias depending on the customer's preference.

Stonly PDF exports (available on Business and Enterprise plans) do not have a migration path into Gorgias because Gorgias does not have a native PDF export feature for Knowledge Base articles. If the customer used PDF exports as their primary external documentation format, we flag this gap and deliver the PDF generation source (the article content and structure) so that the customer's admin can generate PDFs using a third-party tool or a custom script post-migration. We confirm the customer's current Stonly plan tier during scoping to identify whether any affected guides exist.