Migrate from Re:amaze to Gorgias

Re:amaze Conversations map directly to Gorgias Tickets. Each conversation's subject, category, message thread, assignee, status, and timestamps transfer. The channel metadata (email, chat, SMS, social) is preserved as Gorgias channel tags on the ticket. We extract all messages including internal notes and agent-customer exchanges, and attach the original timestamps to maintain the conversation timeline. Re:amaze conversation IDs are stored in a custom Gorgias ticket field reamaze_conversation_id__c for audit reconciliation after cutover.

Re:amaze Contacts migrate to Gorgias Customers. The customer name, email, phone, location, browser, and last-seen attributes map to Gorgias customer fields. Custom fields (discovered via sampling, see gotchas) map to Gorgias customer properties as string, boolean, date, or select fields depending on the inferred data type. Re:amaze contact tags attach to the Gorgias customer record. Where a Re:amaze contact has multiple associated brands, the customer is created in each relevant Gorgias store under the multi-brand configuration.

Re:amaze Agents (Staff Members) with their name, email, role (admin, agent), avatar, and availability status map to Gorgias Users. We resolve by email match. Role-based access (admin vs agent) sets the Gorgias permission_level accordingly. If a Re:amaze agent is inactive or deleted at migration time, we flag the record and assign their conversations to a default Gorgias agent specified during scoping.

Re:amaze multibrand accounts require a separate migration pass per brand. Each brand is scoped via its subdomain in the Re:amaze API (brand.reamaze.io) and maps to a separate Gorgias store under the customer's multi-store configuration. Knowledge base articles, conversations, contacts, and agents are exported and imported per brand so that cross-brand data does not bleed between stores. Multi-brand Re:amaze accounts incur additional scoping and QA time, which is reflected in the price estimate.

Re:amaze conversation tags export as a flat string list and re-create as Gorgias Tags. Tag names are preserved verbatim. Tag hierarchy is not supported in Re:amaze, so no hierarchy mapping is required. Tags used for conversation routing or SLA categorization are documented in the migration inventory so the customer can re-apply them to Gorgias workflow rules post-migration.

Re:amaze custom fields have no dedicated API resource and are stored as attributes on contact records. We discover them by pulling a statistical sample of 50-100 contacts, extracting all non-standard keys, and inferring field type from value patterns (boolean, date, string, select). Fields with null values across the sample are still included in the map. Each discovered field is pre-created in Gorgias as a customer property before customer migration begins, using the inferred type and field name as the Gorgias property key.

Re:amaze Quick Answers (canned response templates grouped by category) map to Gorgias Macros. The title, content body, and HTML formatting transfer. Shortcodes from Re:amaze are documented as macro shortcuts in the handoff inventory. Macro conditions (which Re:amaze does not support natively but agents may have implemented via workarounds) are documented for the customer's admin to rebuild as Gorgias macro conditions, which allow if/then logic per channel and ticket attribute.

Re:amaze FAQ articles migrate to Gorgias Help Center articles with category hierarchy preserved. Published public articles map to Gorgias Public status, private articles to Unlisted, and drafts to Draft. The Gorgias Help Center has a native import path for Re:amaze accessible from Settings > Channels > Help Center, which we use as the primary import method for articles and categories; for accounts with large KB volumes or complex nested categories, we supplement with API-based import to handle edge cases the native tool misses.

Re:amaze article categories map to Gorgias Help Center top-level and sub-categories with name, position, and parent-child hierarchy preserved. Categories with translations (if the Re:amaze account uses multi-language KB) map to Gorgias Help Center translations per category and article.

Conversation message attachments and contact profile attachments export as file URLs with metadata (filename, MIME type, size). Where Re:amaze serves attachments behind signed URLs or on their CDN, we download the file content and re-upload to Gorgias. Inline images embedded in message bodies are extracted and re-hosted in Gorgias. Attachments exceeding Gorgias file size limits are flagged and documented for the customer to store externally.

Re:amaze e-commerce integrations (Shopify, BigCommerce, Magento) store connection state, OAuth tokens, webhook URLs, and channel credentials server-side and are not accessible via the API. These integrations do not migrate. We document every active Re:amaze integration (name, trigger events, data flow) in the handoff inventory, and the customer's admin reconnects them in Gorgias manually. This is a known manual step and is scoped separately from the data migration.

Re:amaze workflows, automation rules, and SLA configurations are not migrated. They are structurally incompatible with Gorgias workflow rules (which use conditions, actions, and multi-step branches by channel and customer attribute). We deliver a written inventory of every active Re:amaze automation with its trigger type, conditions, actions, and recommended Gorgias equivalent as a handoff document for the customer's admin or a Gorgias partner to rebuild post-migration.