Migrate from Stonly to HubSpot Service Hub

Each Stonly Guide maps to a HubSpot Knowledge Base article. We export the full step text, media attachments, custom CSS, and variable configurations from the guide JSON. HubSpot articles use a flat section structure without native branching, so the branching decision tree is documented in a separate branching-map reference document that your content team uses to either create separate articles per path or restructure the walkthrough as a linear article. Guide title becomes article name, guide description becomes article summary, and step content populates article sections in order.

Stonly Knowledge Bases map to HubSpot Knowledge Bases. We export the full KB hierarchy including category names, descriptions, slug structure, ordering, and the assignment of which guides belong to which categories. HubSpot supports multiple knowledge bases only on Enterprise; Starter and Professional include one knowledge base per portal. If the customer has more than one Stonly KB and is on a non-Enterprise HubSpot plan, we recommend merging into a single KB with category-based separation or discuss a multi-portal strategy during scoping.

Stonly categories within a Knowledge Base map to HubSpot Knowledge Base categories. Category names, descriptions, ordering, and slug structure transfer directly. The category hierarchy depth in Stonly (up to three levels) maps to HubSpot's category and subcategory model.

Step-level images, screenshots, and embedded videos from Stonly guides export as media files. We upload these to HubSpot's file manager and link them within the corresponding article sections. Video embeds transfer as URL-based video blocks if the destination is YouTube or Vimeo-hosted; native Stonly video hosting cannot be transferred and must be re-uploaded to a supported host.

The Stonly Widget is a site-side JavaScript snippet that Stonly does not expose as a portable configuration file. It cannot be programmatically exported and reinstalled in HubSpot. We document the widget's current placement (URL paths, subdomain targeting) and deliver a configuration plan for HubSpot's Conversations inbox widget and help center embed, which your implementation team deploys post-migration. The document covers which pages should receive the HubSpot widget and how to configure routing to the migrated knowledge base.

Stonly Triggers define when and to whom guides are shown based on URL, user property conditions, or user event conditions. HubSpot has no native Stonly-style guide delivery trigger. We export the full trigger rule set as structured data including the targeting criteria, guide assignment, and trigger conditions, and we deliver a written guide delivery rulebook. The customer's HubSpot admin maps these to HubSpot Workflows for ticket creation, email routing, or chatbot routing based on contact properties. No trigger automation is migrated as functional code.

Stonly custom user properties (subscription level, account type, plan tier, next billing date) export as structured data with property names, data types, and value mappings. We create equivalent HubSpot Contact custom properties in the destination portal and import the property values against matching contacts. The Stonly property schema is preserved in our mapping manifest so the destination team knows exactly which HubSpot property each Stonly property maps to and can use them for personalization rules in HubSpot Workflows.

Stonly user events (purchased_product, created_ticket, logged_in, etc.) are tracked actions used for guide targeting. HubSpot does not have an equivalent user event stream for guide delivery. We export the event names, event schemas, and any event-based guide routing rules as a reference document. The customer's HubSpot admin uses this to configure HubSpot Workflow triggers on contact property changes if the same routing logic is needed post-migration.

Stonly AI Answers configurations (knowledge base scope, query routing, fallback behavior, and AI response settings) export as structured data. HubSpot AI Copilot in Service Hub Professional and above uses a different knowledge-base indexing model and does not accept Stonly AI Answer configurations as an import. We document the current AI Answer settings in a configuration reference so the customer's admin can configure HubSpot AI Copilot to cover the same query types from the migrated knowledge base articles.

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. Historical Stonly analytics cannot be re-imported into HubSpot Service Hub as native reporting data because HubSpot does not support external analytics ingestion at the article level. The CSV export preserves the data for reference and for re-upload into a third-party analytics or BI tool if the customer maintains one.

Stonly team members (Admin, Editor, Viewer roles) with their email addresses, names, KB-level permissions, and role assignments export as CSV. We resolve each Stonly team member by email against the HubSpot destination portal's user list. Role names differ between platforms: Stonly Admin and Editor map to HubSpot Super Admin or Standard user roles with content creation permissions; Viewer maps to HubSpot user with read-only access. Permissions are documented in our mapping manifest for your HubSpot admin to assign post-migration.

PDF export is available only on Stonly Business and Enterprise plans. If the customer used Stonly guide-to-PDF export as their primary external documentation format, we confirm this gap during scoping. HubSpot does not natively generate PDFs from knowledge base articles. We recommend exporting the Stonly guides as PDF before migration (if on a qualifying plan) and storing them externally, or rebuilding PDF generation using a third-party integration like PrintFriendly,_pdfcrowd, or a custom document generation flow post-migration.