Migrate from Re:amaze to HubSpot Service Hub

Re:amaze Conversations map to HubSpot Service Hub Tickets. Each conversation's subject, status (open/resolved), assignee, category, and timestamps migrate to the corresponding Ticket fields. We pull /conversations with full message threads, then insert Tickets in the destination using the HubSpot Conversations API (messaging) or Tickets API (ticketing). The conversation message body becomes the ticket thread, with author, timestamp, and attachment metadata preserved as message records linked to the Ticket.

Re:amaze Contacts map to HubSpot Contacts. We extract all contact records including name, email, phone, and custom attribute values. The HubSpot Contact is created first so that its ID is available as a lookup when Tickets are imported in the second pass. We resolve duplicate contacts by email dedupe key during import and flag any contacts with conflicting values for customer admin review.

Re:amaze stores company data as attributes on Contact records rather than as a separate object. We detect company-named attributes (company name, domain, billing address) on each contact record, extract them into distinct HubSpot Company records, then link the original Contact to the Company via the company_id association. This produces a proper Contact-Company relationship that HubSpot reporting depends on.

Re:amaze does not expose a Custom Field definition endpoint. Custom fields created in the embed builder are stored as attributes on contact records. We discover them by pulling a statistical sample of 50-100 contact records, extracting all non-standard keys, and building a field map before migration. Fields present in the sample are created as HubSpot Contact Properties (type-mapped to text, number, date, or enumeration as appropriate) before contact import begins. Fields with null values across the full sample are still included in the map and mapped explicitly during import.

Re:amaze tags are flat string labels applied to conversations by agents and admins. We export all unique tag values, then re-create them at the destination as HubSpot Ticket Properties of type enumeration or multi-select picklist depending on whether a single tag or multiple tags were applied per conversation. Tag application migrates as the tag value(s) on each Ticket record.

Re:amaze Quick Answers are canned response templates with title, content body, category, and optional shortcode. We export the full content including HTML formatting. At the destination, Quick Answers are re-created as private Knowledge Base articles (draft status) so that agents can access them inside HubSpot's help pane. We preserve the category grouping and shortcode as article metadata. The customer admin republishes and organizes these post-migration.

Re:amaze FAQ articles are searchable, category-grouped, and embeddable. The API surfaces articles with their content, category, and publish status. We migrate articles preserving the category hierarchy and publish status. HubSpot Knowledge Base articles use a different content model (article sections with different block types), so article body text migrates as-is and images are re-uploaded to HubSpot's file manager during import. We do not migrate embedding configuration or published URL slugs; these are rebuilt by the admin post-migration.

Re:amaze agent profiles include name, email, role (admin, agent), avatar, and availability status. We export all agent profiles and map agent emails to HubSpot Users at the destination. Role-based access control maps from Re:amaze admin and agent roles to HubSpot Super Admin and regular User roles. Agents without a matching HubSpot User are placed in a reconciliation queue for the admin to provision before ticket import resumes.

Re:amaze multibrand accounts host multiple customer-facing brands under one account with separate inboxes, contacts, and reporting. Each brand is scoped by a unique subdomain. We migrate each brand as a separate API pass, extracting contacts, conversations, and knowledge base content per brand subdomain. At the destination, each brand's data is imported into a separate HubSpot Team or, for accounts with multiple HubSpot portals, into the corresponding portal. We coordinate brand-to-destination mapping during scoping.

Conversation messages and contact profiles may include file attachments. We export attachment URLs and metadata from Re:amaze. Where Re:amaze stores attachments behind signed URLs or on their CDN, we download the file content and re-upload to HubSpot's file manager, then attach to the corresponding Ticket message record. Files exceeding HubSpot's attachment size limits are linked via URL reference in a custom Ticket property.

Re:amaze integrations with Shopify, BigCommerce, Magento, and other e-commerce platforms store connection state server-side, including webhook URLs, API credentials, and sync configuration. These do not transfer to HubSpot Service Hub because they require re-authentication and reconfiguration at the destination. We document every active Re:amaze integration as a line item in the migration scope so the customer's admin knows which connections to rebuild in HubSpot after cutover.

Re:amaze conversation message threads are extracted per conversation with body content, author type (customer, agent, bot), timestamp, and read status. Each message is inserted as a Ticket communication record at the destination using the HubSpot Conversations API for chat-style messages or the Tickets API for email-style threads. Message ordering is preserved by timestamp. Internal notes from Re:amaze are imported as private Ticket notes in HubSpot.