# How to Switch Shopify Support Apps Without Losing Your Ticket History > The fear of losing years of customer conversations keeps many store owners stuck with expensive, inefficient support tools; here is the store owners' guide to migrating your data without losing it. Source: https://arbyn.app/blog/how-to-switch-shopify-support-apps-without-losing-your-ticket-history- Published: 2026-08-04 --- You know the feeling. It’s the first of the month, the invoice for your helpdesk software hits, and the number is higher than you budgeted for. Again. The per-ticket fees, the surprise overages, the charge-per-resolution from the new AI add-on, it all adds up, turning a tool that was supposed to create efficiency into a significant, unpredictable line item on your P&L. You know there are better, more modern platforms out there, maybe ones with flat-rate pricing that could save you thousands. But then the second feeling hits: the cold, sinking realization that switching means untangling years of customer data. Every support ticket, every conversation, every internal note is trapped inside your current system. The thought of losing that history, of starting from scratch and leaving agents blind to a customer’s past issues, is paralyzing. So you sigh, archive the invoice, and tell yourself you’ll deal with it next quarter. This is the exact inertia that keeps countless Shopify store owners tethered to legacy support apps they've long since outgrown. This operational paralysis isn't an accident; it's a core business model for many SaaS companies. It's called data gravity, or vendor lock-in, and it’s the force that keeps you from leaving even when you know you should. The more of your data a platform holds, customer history, product information, support tickets, the harder it is to leave. The cost and complexity of extracting and moving that data become a powerful moat protecting the provider's revenue. They count on your fear of a messy migration to outweigh the pain of their monthly bill. But that data is yours, not theirs. Migrating your entire support history is not a trivial task, but it is absolutely solvable. It is not a black box of unknowable technical wizardry. It's a series of concrete, executable steps. With a clear plan, you can switch to a new Shopify support app, bring your valuable customer context with you, and finally break free from a billing model that penalizes you for growth. The Data Gravity Problem: Why Leaving Your Helpdesk Feels Impossible The decision to switch support platforms is rarely made lightly. It’s often the result of months, or even years, of growing friction. Maybe the software has become slow and buggy, especially during peak sales periods when you need it most. Perhaps essential features that would genuinely help your team are locked behind an enterprise-tier plan you can't justify. Most often, the trigger is financial. You look at a bill for hundreds or thousands of dollars for a tool that resolves customer issues and realize that money could be spent on inventory, marketing, or hiring. You’re paying a tax on your own customer engagement, and the cost structure of your helpdesk has become a direct impediment to your store's profitability. Yet, the migration project stalls before it even begins, stopped by the sheer perceived weight of the data. This feeling of being trapped is a well-understood phenomenon in the software industry. The technical term is vendor lock-in, and it arises when a business becomes overly dependent on a provider's specific tools, APIs, or data formats, making it prohibitively difficult or costly to move to a competitor. Your ticket history isn't just a collection of conversations; it's stored in a proprietary format, with specific data structures for comments, attachments, tags, and internal notes. An export might give you a file, but it’s often not a clean, complete, or portable record of your operations. This is intentional. The lack of a simple, comprehensive "export everything" button is a feature, not a bug, of many legacy systems. It creates a significant barrier to exit, ensuring customer churn remains low even if satisfaction is also low. This is compounded by the fact that many SaaS vendors' terms of service place the full responsibility for data protection and backup on you, the customer, even while making it technically difficult to perform those backups in a useful way. The risks of a poorly executed migration are real and justify a cautious approach. Data loss is the most obvious fear. Imagine a customer writing in about a faulty product, and your agent has no record of the three previous times they’ve contacted support about the same issue. This instantly creates a frustrating experience and makes your team look incompetent. Corrupted data is another risk, where ticket histories are imported but are jumbled, unreadable, or disconnected from the correct customer records. According to research from Gartner, 83% of data migration projects either fail to meet their goals or run significantly over budget, often due to hidden complexities discovered mid-process. These potential pitfalls, downtime, lost context, frustrated agents, and angry customers, are precisely what incumbents count on to keep you from making a change. But understanding these risks is the first step to mitigating them. A successful migration isn't about hoping for the best; it's about planning for the worst and building a process that ensures continuity. Deconstructing Your Ticket History: What Data Truly Needs to Move? Before you can plan the move, you must first take inventory of what you're moving. A "ticket history" isn't a single monolithic block of data. It's a complex, relational database of different information types, and not all of them have the same value or the same migration difficulty. A critical step that many store owners skip is to strategically decide what data is essential for day-to-day operations versus what is merely archival. Trying to move every single piece of data perfectly from day one can overcomplicate the project. Instead, break your support data down into distinct components and prioritize them. This store owner's audit will form the foundation of your migration plan, whether you're using a simple CSV file or a sophisticated third-party service. You need to know what you have before you can ask how to move it. The first and most critical layer is the core ticket data. This includes the essentials: the ticket ID, the customer's name and email, the subject line, the creation and closing dates, the current status (open, pending, solved), and the assignee. This is the metadata that allows you to find and organize conversations. Crucially, this layer also includes the full message content, the actual back-and-forth conversation between your team and the customer. This is often the trickiest part to export cleanly. Some platforms, like Intercom, have native CSV exports that explicitly do not include the message bodies, requiring you to use their more complex API to get the full transcript. Gorgias allows for exporting message content, but limits it to the most recent 30 days of data in a single export, with a cap of 100,000 tickets. Understanding these limitations is vital; a metadata-only export is useless for preserving conversational context. The second layer is the relational data that adds context to the core tickets. This includes things like tags, internal notes, and attachments. Tags are fundamental for routing, reporting, and automation. Internal notes are where your team communicates behind the scenes, leaving critical context about a customer or a complex issue. Attachments, screenshots from customers, return labels, invoices, are often essential for resolving an issue. These elements are often stored as separate objects in the helpdesk's database that are linked to the parent ticket. A simple CSV export may flatten this structure, either by omitting the data entirely or by cramming it all into a single cell, making it difficult for the new system to parse. For example, Gorgias's macro export provides the reply text but doesn't transfer the automated actions associated with it. You must verify if your chosen migration method will preserve these relationships. Losing your tags can break your reporting, and losing internal notes can erase years of institutional knowledge. The final layer is the broader ecosystem data: your macros or canned responses, your knowledge base or help center articles, and your agent profiles and permissions. Macros are a huge time-saver, and manually rebuilding hundreds of them is a daunting task. While some platforms like Gorgias and Tidio allow you to export macros to a CSV, the import process on the other end might not be straightforward. Your knowledge base represents a significant investment in content creation. Migrating it involves moving articles, images, and preserving the category structure. Agent profiles are less of a data-heavy lift but are critical for getting your team up and running quickly. By categorizing your data this way, from essential ticket content to operational assets like macros, you can make informed trade-offs. You might decide that migrating every closed ticket from five years ago is a low priority, but preserving all open tickets with their full context and all of your active macros is non-negotiable. This clarity is what turns an overwhelming task into a manageable project. Your Three Migration Paths: CSV, API, or a Third-Party Service Once you have a clear inventory of the data you need to move, you can evaluate the primary methods for getting it from your old helpdesk to a new one. There are fundamentally three ways to approach this technical challenge, each with a different balance of cost, complexity, and completeness. There is no single "best" way; the right choice depends on the size of your support operation, your team's technical comfort level, and your budget. The options are the manual CSV export and import, a custom-built API script, or a dedicated third-party migration service. Understanding how each of these works, including their specific limitations with popular platforms like Zendesk, Gorgias, and Intercom, is the key to choosing the path that fits your business. The first and most accessible path is the manual CSV export. Nearly every helpdesk platform allows you to export data as a Comma-Separated Values file, which you can then (in theory) import into your new system. This method's primary advantage is that it’s usually free and doesn't require any coding. You can perform the export yourself directly from the admin panel. However, its simplicity is deceptive, and this path is fraught with peril for all but the smallest stores. As noted before, the contents of these CSV files are often incomplete. Zendesk's native CSV export provides an overview of core ticket data but requires higher-tier plans or API usage for full details like comments and attachments. Gorgias limits message history exports to a rolling 30-day window. Intercom's simplest CSV export explicitly excludes conversation transcripts. Even if you get a complete file, you then face the challenge of mapping the columns from your old system's format to your new system's format, a process that can be tedious and error-prone. For stores with more than a few hundred tickets, the CSV path often proves to be a false economy, saving money upfront but costing enormous amounts of time and resulting in a messy, incomplete data transfer. The second path, for the technically savvy, is using the platforms' APIs (Application Programming Interfaces). An API is a way for different software programs to talk to each other. In this scenario, a developer would write a custom script that connects to your old helpdesk's API, pulls the ticket data piece by piece, and then uses the new helpdesk's API to push that data into the new system. This is the most powerful and flexible method. It allows you to map data fields precisely, handle complex relationships between tickets and contacts, and migrate virtually any data object the APIs expose, including full conversation histories and attachments. The downside is the significant technical expertise required. This is not a task for a non-developer. It involves understanding API rate limits, handling data pagination, and writing code to transform data from one format to another. For example, a script to pull all data from Zendesk would need to use their incremental exports API to fetch ticket events in chunks to avoid timing out. If you don't have a developer on your team, this option means hiring a freelancer or agency, which can be expensive. For a large, complex migration, this could be a project costing thousands of dollars, but it offers the highest fidelity result. This leads to the third and most popular path for serious Shopify stores: using a dedicated, third-party migration service. Companies like Help Desk Migration specialize in exactly this process. They have built connectors for dozens of helpdesk platforms and handle all the complexities of API mapping, data transformation, and error handling for you. You use their web-based tool to connect your source and target accounts, choose which data you want to migrate, and the service handles the rest. They typically offer a test migration so you can see how your data will look in the new platform before committing to the full process. This option provides the best balance of completeness and convenience. It's far more reliable than a manual CSV import and much less effort than building a custom API script. The primary trade-off is cost. These services charge based on the number of records you're migrating. For example, migrating 10,000 records through a service could cost several hundred to over a thousand dollars, depending on the complexity. However, when you compare that cost to the value of your team's time or the cost of hiring a developer, it's often the most pragmatic and cost-effective choice for ensuring a smooth, successful transition. Migration Method Cost Technical Skill Data Completeness Best For Manual CSV Export/Import Free Low Low to Medium (often missing transcripts, attachments, and relations) Very small stores with low ticket volume and simple data. Custom API Script $$$ (if hiring a developer) High (requires coding) High (can be tailored to move almost everything) Large enterprises or stores with unique data structures and an in-house development team. Third-Party Migration Service $$ (pay per record) Low High (service handles all the technical complexity) Most Shopify stores looking for a reliable, complete, and efficient migration without needing a developer. A 7-Step Plan for a Clean Cutover Choosing your migration path is a major decision, but the work doesn't end there. A successful transition from one support platform to another is as much about project management as it is about technical execution. A clean cutover requires careful planning to minimize disruption to your support operations and ensure your team is ready to hit the ground running in the new system. Simply running a migration tool and hoping for the best is a recipe for chaos. Following a structured checklist helps you anticipate issues, coordinate your team, and avoid the common pitfalls that turn a migration into a nightmare. This is the operational sequence that separates a smooth transition from a week of firefighting, lost tickets, and frustrated agents. You need to manage the change for your people, not just your data. First, **assemble your team and define your goals.** A helpdesk migration is not just an IT project; it impacts your entire customer-facing team. Your migration team should include a project lead, a representative from your support team who knows the data inside and out, and any technical resources you’ll be using. Before you move a single ticket, get crystal clear on *why* you are switching. Is the primary goal to reduce costs, gain specific features, or improve team efficiency? Documenting these goals helps keep the project on track and provides a framework for declaring success later. Second, **perform a data cleanup in your current system.** A migration is the perfect opportunity to declutter. Archive old, irrelevant tickets. Standardize your tags. Merge duplicate customer profiles. Moving clean data is infinitely easier than trying to clean it up after it's been shoehorned into a new system. This "spring cleaning" reduces the number of records you need to migrate, which can lower the cost of a third-party service and simplify the entire process. Third, **configure your new helpdesk before migrating data.** Get the new platform set up with user accounts for all your agents, recreate your team inboxes or groups, and set up basic business rules and automations. Don’t wait for the data to arrive to start building your new home. This ensures that when tickets are migrated, they can be assigned to the correct agents and teams immediately. Fourth, **run a test migration.** This step is non-negotiable, especially if you are using a third-party service. Most services will migrate a small subset of your tickets for free. This allows you to spot-check the results. Do the customer records match? Are the tags assigned correctly? Are the full conversation transcripts present and readable? Finding a mapping issue with 100 test tickets is a simple fix; finding it with 100,000 migrated tickets is a disaster. Fifth, **choose a cutover time and communicate the plan.** Pick a time for the "go-live" moment when your team will stop using the old system and start using the new one. This should ideally be during your period of lowest support volume, such as a Tuesday or Wednesday morning, not a Friday afternoon. Create a clear communication plan for your support team, letting them know the timeline, providing training on the new platform, and setting expectations for the cutover day. Sixth, **execute the full migration and switch your routing.** After the test migration is approved, run the full data migration. Once it's complete and you've verified the data has arrived, the critical moment is switching your support channels. You will need to update your email forwarding rules to direct incoming support emails to the new helpdesk's address. You'll also swap out the live chat snippet on your Shopify theme. Finally, **conduct a post-migration validation.** For the first 24-48 hours, keep a close eye on the new system. Have your team work exclusively in the new platform but keep the old one in a read-only state for a week or two as a fallback. Check that new tickets are flowing in correctly and that agents can access historical data as needed. By following these steps, you transform a risky technical task into a controlled, predictable process. Life After Migration: A New Support Operations Model The moment your migration is complete and your team is working in the new platform, a fundamental shift occurs that goes beyond just using a different interface. When you move away from a helpdesk that bills on a per-ticket or per-resolution basis, you escape a mindset of scarcity. You stop making subconscious calculations about whether engaging with a customer is "worth" the cost of the ticket it will generate. This mental overhead disappears, freeing your team to focus entirely on the quality of the conversation and the outcome for the customer, not the cost to the business. Your support function can finally transition from a cost center to be managed down, into a revenue-driving and retention-focused part of the company. This isn’t a small change; it’s a complete re-architecting of your operational philosophy. Without the constant pressure of a running meter, your team can operate more proactively. You can start encouraging conversations that you might have previously avoided. For example, instead of just having a passive live chat widget, you can use proactive triggers to engage customers who are lingering on a product page or have a high-value cart but seem hesitant to check out. In a usage-based billing model, every one of these proactive chats is a potential cost. In a flat-rate model, it's a pure opportunity. Your agents can spend more time with customers, building rapport and uncovering upsell or cross-sell opportunities without a manager worrying about the impact on the monthly software bill. This allows your best agents to become true sales assets, using their product knowledge and conversational skills to increase average order value directly within the support channel. This new model also dramatically simplifies forecasting and budgeting. One of the biggest pain points for store owners on platforms like Gorgias or Intercom Fin is the bill shock that comes after a successful sales period. A great Black Friday weekend can lead to a massive, unexpected support bill the following month. This makes financial planning incredibly difficult. When your support platform is a fixed, predictable cost, it becomes a stable piece of your operational infrastructure, just like your Shopify plan itself. You can budget for the year with confidence, knowing that your support software cost will not change whether you have 500 conversations or 5,000. This stability is invaluable for a growing business, allowing you to invest the savings back into the product, marketing, or other areas that drive growth, rather than feeding an ever-growing software subscription. Choosing a Destination That Justifies the Switch Undergoing a full data migration is a significant operational investment. The process demands careful planning, team coordination, and a clear understanding of the technical pathways. It's a project you only want to undertake once, which makes the choice of your destination platform absolutely critical. The move isn't just about escaping the pain of your old system; it's about landing on a platform that fundamentally changes your capabilities and economics for the better, justifying the upfront effort of the switch. You're looking for a partner that not only solves today's billing headaches but provides a scalable foundation for how you want to manage customer conversations for years to come. This means looking beyond a simple feature list and evaluating the core philosophy of the platform. This is the exact problem Arbyn was built to solve. While many modern AI support tools still rely on complex, usage-based billing models that charge per resolution or cap conversations, Arbyn was designed around a simple, transparent flat-rate price. The Arbyn Agent plan is $99 per month for unlimited conversations and unlimited AI resolutions. There are no overages, no hidden fees, and no separate charges for AI usage. This predictable cost structure directly addresses the primary pain point that forces store owners to consider a migration in the first place. For a store handling 800 conversations a month, the cost difference can be stark: what might cost upwards of $400 on Gorgias is a flat $99 with Arbyn, month after month. This isn't just a cost savings; it's a strategic advantage that unlocks the proactive, revenue-focused support model discussed earlier. Arbyn is more than just a pricing model; it's a complete support and sales agent designed for Shopify. It integrates deeply with your store to handle customer conversations across email and live chat, but it doesn't just answer questions. The AI can take real action. While money-moving actions like issuing refunds or creating discount codes require a single click of approval from you for security, Arbyn executes the task in Shopify and confirms it to the customer. It's not just a chatbot; it's an agent that executes tasks on your behalf. Furthermore, its proactive chat and in-chat product recommendations are designed to turn support interactions into sales opportunities. While the process of migrating historical ticket data into any new system requires a deliberate plan using the methods outlined in this article, the long-term operational and financial benefits make the effort a sound business decision. By making the switch, you're not just changing tools, you're getting off the usage-based treadmill for good. If you're tired of unpredictable support bills and feel locked in by your current provider, the path to freedom is clearer than you think. The technical hurdles of data migration are solvable, and the operational upside of a flat-rate, sales-focused support platform is immense. You can take back control of your support costs and empower your team to deliver better service. If you're ready to make a change, you can install Arbyn from the Shopify App Store and see how a new model can transform your support operations. --- ## Pricing - **Arbyn Starter** - $0/month, permanently free. 150 conversations / month. Resets 1st of each month. - **Arbyn Agent** - $99/month flat, unlimited conversations. Or $990/year (2 months free, saves $198, 17% off). - **There is no trial.** Billing starts immediately on the Agent plan. The free Starter plan is permanent. - The conversation cap is the only difference between plans. There is no feature gating. ## Channels Live today: **support email** and **on-site live chat**. That is the complete list. SMS, Instagram DMs, Facebook Messenger, WhatsApp and Voice are on the roadmap and are NOT live. Arbyn does not edit orders or change line items. Money-moving actions (cancel, refund, discount, gift card, reship, return) require the store owner's approval, and then Arbyn performs them. Running them fully autonomously is a beta authorization and is in development. Shipping address changes are already autonomous. ## What Arbyn does on a Shopify order - **Change the shipping address**: Live. Arbyn does this on its own. Arbyn updates the shipping address on the Shopify order itself, inside the conversation, and writes the change to the order timeline. - **Cancel an order**: Live. You approve it, then Arbyn cancels the order. Anything that moves money waits for the store owner's approval. That is a deliberate control, not a missing feature. Once you approve, Arbyn fires Shopify's order cancellation itself and confirms it to the customer. - **Issue a refund**: Live. You approve it, then Arbyn issues the refund. Arbyn prepares the refund against the original payment method and sends it to you. On approval it files the refund in Shopify. You can cap the value it is allowed to prepare, per channel. - **Apply a discount**: Live. Arbyn creates a real Shopify discount and applies it to the cart, handing the shopper a checkout with the code already on it. It can also issue a discount code on an order once you approve it. - **Send a gift card, or reship an order**: Live. You approve it, then Arbyn does it. Arbyn creates the gift card, or raises the replacement order, in Shopify once you approve. - **Start a return**: Live. You approve it, then Arbyn opens the return. Arbyn opens the return in Shopify on your approval. - **Look up a gift card or store-credit balance**: Live. Arbyn does this on its own. "Do I have store credit left?" is a question most support tools answer with a human. Arbyn reads the balance itself, for a verified customer or from the code they give you, and reports the masked card, the balance and the expiry. If there is no card, it says so rather than guessing. - **Handle a subscription question**: Live. You choose what it does. Arbyn knows which of your products are sold as a subscription, shows that on the product card in the conversation, and sends a subscriber to their subscription management page to pause, skip or cancel. It answers how your subscriptions work from your own knowledge, but it does not read an individual customer's contract, so it will not state their renewal date or status. Most cancels are a customer with product piling up, and the fix is getting them to the page where they can slow the cadence down. Reading the contract itself is on the roadmap. - **Answer support email and live chat**: Live. Arbyn reads every inbound support email and every chat, works out the intent, pulls the live Shopify context, and replies in your brand voice. Money-moving actions (cancel, refund, discount, gift card, reship, return) require the store owner's approval, and then Arbyn performs them. Running them fully autonomously is a beta authorization and is in development. Shipping address changes are already autonomous.