Migrate your Stonly data

Guides are the primary content unit in Stonly. We export full guide content including step text, media attachments, branching logic, targeting rules, custom CSS, and in-guide variable configurations. Guide metadata (title, description, version history, publish status) is preserved 1:1. Branching tree structure is exported as a structured JSON representation that we document in our mapping manifest.

Knowledge Bases are the organizational containers for guides. We export the full KB hierarchy including category names, descriptions, slug structure, ordering, and the mapping of which guides belong to which KB. KB-level settings such as branding, language, and visibility are preserved in our export.

The Stonly Widget is the embeddable JavaScript component that launches guides on external websites. Widget installation involves a site-side snippet that Stonly does not expose as a portable configuration file. We export the widget configuration settings (colors, position, launcher behavior) but the actual deployment of the snippet to the destination website must be done manually by the customer's engineering team.

Triggers define when and to whom guides are shown based on URL, user actions, or user property conditions. We export trigger rules as structured data including the targeting criteria, guide assignments, and display conditions. Since triggers depend on the destination website's URL structure and user data layer, re-implementation of trigger rules in the destination platform is required and documented in our runbook.

Custom user properties describe attributes like subscription level, next billing date, or account type. We export the complete property schema including property names, data types, and any value mappings used in guide targeting. These are portable as a reference schema for the destination team to re-implement in their own user data layer.

User events are actions tracked by the Stonly widget such as 'purchased_product' or 'created_ticket'. We export the event names, event schemas, and any event-based guide routing rules. This gives the destination team a complete event catalog to re-implement in their own analytics or CRM.

Stonly's AI-powered search bar surfaces answers from guide content. We export AI Answer configurations including the knowledge base scope, query routing rules, and fallback behavior. Since AI Answer accuracy depends on the destination platform's own AI capabilities, we provide a content export and recommend the destination team re-configure AI Answer behavior post-migration.

Stonly provides full-path analytics including guide completion rates, step-level drop-offs, and usage trends. We export analytics snapshots as CSV at the time of migration. Note that historical analytics cannot be re-imported into most destination platforms; we preserve them as an audit artifact and recommend reviewing them before final cutover.

Team members include their 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 the destination platform's must be reviewed manually during scoping, as permission models vary significantly.

Custom properties set at the widget level rather than the guide level (e.g., widget display name, default language) are exported as part of the widget configuration export. These are straightforward key-value pairs portable to any destination configuration system.

PDF export is available only on Business and Enterprise plans. If the customer used PDF exports as their primary external documentation format, we note this as a feature gap — most migration destinations do not support Stonly's native PDF format and will require re-export or manual document recreation.