Will the original assignees, message authors and created dates be preserved when we migrate to Gorgias?
Yes. Created-time metadata is carried across, and so are assignees and message authors who have a user account in Gorgias. Where Gorgias cannot store one of them natively, it is kept as embedded metadata on the migrated record.
If Gorgias can't natively support an old record type, what are my options?
We handle it case by case. While mapping your data, we identify every record type without a direct counterpart in Gorgias, review sample records from it and propose how it can be represented, based on what Gorgias supports: map it to the closest native object, create a custom field or object, fold it into the parent record as text or a note, attach it as a file, or keep it in a read-only archive. You choose the approach, we write the migration scripts to place the data there, so it comes across in the form you choose instead of being left behind, and you see how it looks in a sample migration before we run the full set.
What happens to tickets assigned to agents who have left the team or don't have an account in Gorgias?
They still come across. Before the migration runs, you decide where they go: to a fallback owner you choose, or left unassigned where Gorgias allows it. Either way, each ticket can get a tag with the original agent's name, for example Assigned_to_Jane, so your team can still see and filter who handled it and reassign them later.
Will all our ticket tags carry over to Gorgias, and can migrated tickets be marked so we can tell them apart?
The tags on the tickets being migrated carry over. Tags come across as part of each migrated ticket, so a tag that isn't on any migrated ticket isn't created in Gorgias, and you can also limit the migration to a list of tags you choose in the migration checklist. Each migration is a custom script, so we can stamp every imported ticket with a tag such as "migrated", or, where Gorgias has custom ticket fields, a field value you choose, so they are easy to filter, and if you ask for a change after reviewing migrated tickets, we re-sync those tickets with the update. The sample migration shows exactly how your tags appear before the full run.
Will migrating to Gorgias send emails or notifications to customers, our team or anyone else?
No. Before the sample or full migration starts, we confirm with you that nothing in Gorgias will send messages about the migrated data: we import with notifications switched off wherever Gorgias allows it, and pause any automation that could send them or give it a condition that skips migrated records. We only proceed once you have confirmed it. If you want anyone told about the move, that message is sent separately, once the migrated data has been checked.
Can we migrate only the contacts who have tickets to Gorgias, not our whole contact list?
Yes. We pull your tickets first, collect the distinct requesters from them, and migrate only those contact records. Contacts with no ticket history are not added to Gorgias.
Can you migrate data that Gorgias can't take in through an API?
In many cases, yes. Where something can't be written through an API, we recreate it through the application itself where the interface allows it, and where that work is repetitive we script and automate it. We tell you up front which items are handled this way, because recreating them through the interface can add time to the schedule.
How do you check that our tickets in Gorgias match the originals?
We run verification checks that compare each migrated ticket in Gorgias with its original in your current help desk. They cover message content, HTML rendering, inline images and attachment checksums.
Will our full ticket conversations come across to Gorgias, or only notes on each ticket?
We migrate the full conversation on each ticket, not a summary saved as notes. Where your current help desk's API doesn't expose part of the history, our engineers retrieve it from your current help desk directly and work out a route to load it into Gorgias. You check the result in a sample migration before the full run begins.
What happens if Gorgias requires fields our current data doesn't have?
We check Gorgias for required fields your current data cannot fill and bring each one to you before those records are migrated. Together we agree how each one is handled, such as a mapping from an existing field, a default value, or, where Gorgias lets that field be made optional, setting it to not required for the migration so you can make it required again once the migration is complete. The migration then runs with that rule applied, so no records are rejected or left behind.
Do internal notes and system-generated notes migrate to Gorgias, or only customer-facing replies?
Internal notes can come across, and so can system-generated notes where your current help desk's API makes them available. During scoping you choose which notes to include, so Gorgias holds the history your team will actually use.
Will our custom ticket fields map to the right fields in Gorgias?
Yes. Before anything runs, we map each of your custom fields to its destination field in Gorgias and confirm the mapping with you. You then review a sample migration so you can check that the values land where you expect, and we make any mapping changes before the full migration.
Can you migrate hundreds of thousands of tickets and contacts to Gorgias?
Yes. Every migration is a custom script built for your project, so volume is something we plan for, not a limit on what can move. At large volumes, run time is set mainly by how fast your current help desk's and Gorgias's APIs accept requests, and we plan the full run around that. Before the full run, we test the mapping and throughput with a sample migration.
Will our canned responses come across as macros in Gorgias?
Yes. Saved replies migrated from your current help desk arrive as macros in Gorgias. They can be included in the sample migration, so your team can check them before the full migration runs.
Can you bring our custom contact fields into Gorgias?
Yes. You create the customer fields in Gorgias and tell us which of your current fields map to each one, and we populate them as part of the migration. If you add fields after some contacts have already been migrated, we update those existing contacts too.
What happens to attachments larger than Gorgias allows, like videos?
Every attachment within the file size Gorgias accepts migrates onto its ticket. Larger files, such as videos, are collected and delivered to you in a separate file once the full migration is complete, so you keep a copy of every attachment.
What happens to multi-select fields when they move to Gorgias?
We map each multi-select field to a text custom field in Gorgias, with all of the selected values joined by a | separator. Every value on the ticket is kept, rather than being reduced to a single choice.
How are ticket statuses other than open and closed handled in Gorgias?
Gorgias tickets are either open or closed, so you decide which of the two each of your other statuses becomes. We can also tag each ticket with its original status, so you can rebuild your views in Gorgias straight away. The mapping is agreed with you before the migration runs.
Will our macros keep their formatting in Gorgias?
The macros you choose to migrate arrive in the format they have in your current help desk, so their content reads as your team wrote it. If you want them restructured or reformatted on the way over, tell us the layout you prefer or share a CSV with it, and we migrate them in that format.
Will links between our records still work after we migrate to Gorgias?
Yes. We move your data in two passes. The first pass creates every record in Gorgias and stores its new ID. The second pass goes back and points each reference at the new record, so links between records lead to the right place.
Will our internal notes stay private to agents in Gorgias, and will they appear in the right order?
Yes. Internal notes migrate as Gorgias internal notes, so only your agents can see them, and Gorgias shows them with its usual yellow highlight. They sit in chronological order in the ticket alongside the customer messages. You check this on a sample migration before the full run.
Can several of our ticket fields be combined into one field in Gorgias?
Yes. We can combine several source ticket fields into a single Gorgias field, for example folding separate product-issue fields into one Contact Reason field. The mapping is agreed with you before the migration runs. Gorgias dropdown fields hold one value per ticket, so where a ticket has values in more than one of the merged fields, we settle with you which value carries over before anything moves.
Can you combine data from several support tools into one Gorgias account?
Yes. Each tool's data is extracted separately and written into the same Gorgias account. How records from the different tools fit together is settled in the data mapping before the build. The sample migration includes data from every source, so you can check the combined result before the full run.
Will our ticket formatting, including HTML content, carry over to Gorgias?
Yes. The migration script converts ticket content, including HTML, into the format Gorgias expects, and our verification checks compare migrated tickets with the originals, including how the HTML renders. The sample migration lets you compare migrated tickets side by side with the originals before the full run, and if anything renders differently, such as HTML appearing as raw text, we adjust the script and re-run the samples until you sign off.
Will the migration create duplicate tags or custom fields in Gorgias?
It shouldn't. We map your data onto the tags and custom fields that already exist in Gorgias rather than creating duplicates alongside them, and we can write the scripts so they leave your existing custom field setup unchanged. If any duplicate tags do turn up after a run, we merge them.
What data will be migrated to Gorgias, and how will each type of record map?
It depends on your current platform and the scope you choose, but it is usually the core records and everything attached to them. Before anything runs, we send you a migration checklist showing where each type of record lands in Gorgias, including anything that won't move, and you confirm the scope.
How do you migrate dependent fields into Gorgias, where one field's options depend on another?
We migrate the parent field and its dependent field together, so each record keeps a valid pair of values. For that to work, the same parent and child options need to exist in Gorgias, with each child option set up under the right parent value; otherwise the dependent value may not be saved. The sample migration shows whether the pairs land correctly, and if they don't, the options are aligned and we re-sync before the full run.
Are attachments migrated to Gorgias, and how do you make sure none are missed?
Yes. Attachments are downloaded from your current platform and uploaded to Gorgias as real files on the same records, wherever Gorgias accepts files on that type of record and within its file size limit, not left as links back to the old system. To make sure none are missed, your Migration Validation Report checks attachment integrity by checksum alongside the record-count comparison, and we can also run an attachment count check against your source and share the results. You can review attachments in the sample migration before the full run.
What happens to custom fields that have no matching field in Gorgias?
You choose how each one is kept. We can create a matching custom field in Gorgias, map it onto the closest existing field, or write its values onto each migrated record as an internal note laid out as readable field-and-value pairs, so the information stays visible without cluttering your new setup. Every field without a match is listed in the migration checklist, and we agree the approach with you before the sample migration.
Will inline images still display after we migrate to Gorgias, or will their links break?
They keep displaying once they are re-hosted, and we plan for that. Where inline images are stored by your current platform, we can download them, upload them to Gorgias and point each image link at its new location, so it no longer depends on your old account. Images embedded directly in email bodies can still be served from your old account, so before you shut it down we can identify the affected records and re-import them with their images re-hosted, and our verification checks on the sample migration include inline images.
Can you set the same value on a field for every record you migrate to Gorgias, such as labelling every contact's phone as 'Mobile'?
Yes, as long as Gorgias lets that field be set through its API. Each migration is a custom script, so we can apply a fixed value to a field on every migrated record. We first test that Gorgias accepts the value, confirm with you, and then apply it across the board, including on records that have already been migrated.
What happens if some of our field values are longer than Gorgias allows?
We handle it in the migration scripts. Fields where Gorgias's limit is shorter than your data are identified while we map your data, the handling for each one is agreed with you before the migration runs, and you can check the result in the sample migration before the full run.
Can you migrate our workflows and automations into Gorgias, or only our data?
Both can be in scope. Your records are the core of the migration, and workflows, rules and automations can be added: we recreate them in Gorgias using its own conditions and actions, since automations don't copy across platforms as they are. Where Gorgias's API can't create them, they are set up through its interface instead, and we agree during scoping exactly which ones we rebuild and which your team or implementation partner will handle.
Do you migrate our users, or do we need to create them in Gorgias before the migration?
Usually your team creates them, but we can do it for you. We recommend setting up your users in Gorgias before the full migration, so every record can be attributed and assigned to the right person; the sample migration uses a default user, so it doesn't need them. If you'd rather we create the accounts, send us the list of users and their roles and we provision them for you, where Gorgias allows it.
Will the migration delete or overwrite any data that's already in Gorgias?
No. The migration adds your records alongside what is already in Gorgias, and nothing there is deleted without your confirmation. Where an incoming record matches an existing one, we link to the existing record rather than creating a second copy, and corrections to migrated records are made as updates wherever possible rather than by deleting and recreating them.
What happens if Gorgias rejects some of our records during the migration?
We log each rejected record, fix the cause and push it again. Common causes, such as a required field your data doesn't fill or a value in a format Gorgias doesn't accept, are agreed with you and handled in the migration scripts, and the scripts can be re-run safely without creating duplicates. When the migration finishes, you get a list of every migrated record and of anything left out, with the reason.
Will the data we migrate count toward Gorgias's plan limits or storage charges?
It depends on your Gorgias plan. Migrated records arrive as regular records in Gorgias, so whether they count toward its record or storage limits is set by Gorgias's pricing, and its own team or your implementation partner can confirm how your plan treats them. If limits are a concern, you can reduce what moves, for example by migrating only the last one or two years of history.
Are deleted tickets included when we migrate to Gorgias?
Only if you want them. You decide during scoping whether deleted and spam tickets are included, and we apply that choice to every run, including the final delta sync. Some platforms keep deleted tickets as scrubbed records with no remaining content; we flag any we find and migrate them only if you ask.
Do you migrate live chat, SMS and messaging conversations, such as WhatsApp, into Gorgias, and do they keep their original channel?
Yes. Chat conversations and messages from channels such as WhatsApp or Instagram are migrated as tickets alongside your email history, where your current platform makes them available through its API or an export. Gorgias may not let imported tickets keep every original channel: some platforms take most imported tickets in through a general API channel instead. So we keep the original channel wherever Gorgias allows it, and can tag each ticket with its original one, such as chat, SMS or WhatsApp, so your team can still find and filter them. If an export leaves out the message content for some channels, we tell you and agree another way to retrieve it.
If our exported tickets have no status, what status will they get in Gorgias?
We set them to closed by default, unless you choose another status. Without a status to map from, migrated tickets are treated as history and kept out of your team's live queues. If you want some of them open, tell us which ones and we set those as open, and if you change your mind after the migration, we can update their statuses in bulk.
Will our tickets end up with duplicate comments after we migrate to Gorgias?
Not normally, and we check for it. Our verification checks compare each migrated ticket with its original, including the message content, and each delta round is checked against what earlier rounds already migrated. If a ticket is found with duplicated comments, we can delete and reimport it, and it keeps its original creation time and conversation timestamps.
Will tickets that have no customer email address still be migrated to Gorgias?
Yes, if you want them. Some help desks need an email address or telephone number to create the customer a ticket belongs to, so we flag every ticket whose requester has neither, including where your current platform's privacy settings hide the email from its API, and send you the list. You can then give us the right email for each requester, or have the tickets migrated with placeholder email addresses, and we migrate them that way. Before flagging a ticket, we also look for its contact elsewhere in the ticket's data.
If our spam tickets are migrated to Gorgias, will they still be marked as spam?
Yes, they can be. If you choose to include spam tickets, we mark them, for example with a spam tag, alongside a migration tag if you use one, so they stay easy to find and filter in Gorgias, and we include some in the sample so you can check them. If you'd rather leave spam behind, we agree a filter during scoping and it isn't imported.
Can you migrate our customer satisfaction (CSAT) survey responses into Gorgias?
Yes, where Gorgias can store them. Where it accepts satisfaction ratings, we migrate them with their tickets, which can need an extra permission on the new account's connection. Where it has no native place for historical ratings, we bring the scores across another way, such as a custom field or a tag on each ticket, agreed with you during scoping.
Can the activity history on each ticket, such as status changes and assignments, be migrated to Gorgias?
Usually not as a native timeline. Event history such as status changes and assignment timestamps stays with your old account and generally isn't something a help desk accepts on import, so it is left out of the migration. Each ticket still arrives with its full conversation, status and assignee, and with its original timestamps where Gorgias accepts them, and parts of the history that matter to you can be kept another way, such as a tag with the ticket's original status or an internal note.
Can you migrate tickets that belong to private or restricted categories into Gorgias?
Yes, once the migration's connection can reach them. If a category or group is private or restricted in your current help desk or in Gorgias, the account we connect with may not be able to read or create tickets in it, so we flag every ticket this affects. You can then lift the restriction or give the connection the access it needs, such as an admin-level account, and we migrate the remaining tickets, or tell us to leave them out.
If we have social media messages, such as Facebook and Instagram comments, will they keep the right author and show where they came from when we migrate to Gorgias?
Yes, as far as your current platform records it. Each message is attributed to the author your current platform's API reports, and messages from your team show under the right agent as long as that agent's account exists in Gorgias before the tickets are migrated; otherwise they fall back to the default agent. We also carry over the message source in as much detail as the API provides, for example telling comments on Instagram posts apart from comments on Instagram ads.
Can you migrate email threads that never became tickets from our email account, such as Gmail, into Gorgias?
Yes. Once your email account, such as Gmail, is connected, we can pull selected email threads directly from it, for example for a date range you choose, and migrate them into Gorgias as tickets. We share the list of threads with you to confirm before anything moves. Because they were never tickets, some details can look different from tickets migrated from your help desk.
Will tickets that have no messages or comments still be migrated to Gorgias?
Yes, if you want them. Some help desks can't create a ticket without at least one message, so we flag every ticket that has none and send you the list rather than skipping them silently. We first check whether the content is stored elsewhere in your current platform, such as a ticket description we can use as the first message. Otherwise we can migrate the ticket with a placeholder message, or leave it out if you prefer.
Can our macros or saved replies keep their folder structure in Gorgias?
Usually, in a form Gorgias supports. Each macro's folder is captured in the migration checklist, and you can rename folders there before the run. Where Gorgias has no folders for macros, we apply a tag named after each original folder, so your team can filter and find them grouped the way they're used to. Where it does have folders, we can place the migrated macros in a folder you choose.
Can you migrate our phone and voice call tickets into Gorgias, including call recordings kept in a separate phone system?
Yes. Tickets from your phone or voice channel are migrated with the rest of your history, and call logs from a separate phone tool can be brought in alongside them. Call recordings stored outside the help desk, for example in a cloud storage bucket your phone system writes to, can be matched to their tickets wherever a match exists. We agree with you in the mapping where calls and recordings will appear in Gorgias, and you check them in the sample migration.
At what stage of the migration to Gorgias are our macros moved over?
Usually during the historical migration, before the final delta sync at go-live, though the timing is agreed with you. Macros can also go into the sample migration so your team can review them before the full run. Any you decide you want after go-live can be migrated then.
What happens to a conversation that mixes email and chat messages if Gorgias keeps those channels separate?
We agree the approach with you during scoping. One option is to split the conversation into a ticket for each channel, each carrying the same subject, tags and other details, so the two are easy to find together on the same customer. If you'd rather have a single thread, we confirm during scoping whether Gorgias can hold it that way, and you check the result in the sample migration.
Why might some of our macros not migrate to Gorgias?
Usually because something a macro depends on isn't in Gorgias yet. A macro whose actions reference a team, field or other setting that doesn't exist there can't be created until that item is set up, so we list those macros for you to create the missing items or tell us how to adjust them. Others may have been left out by choice in the migration checklist, not returned by your current platform's API, or blocked by a limit on how many macros your Gorgias account can hold. Any you want later can still be migrated.
Will a customer with several email addresses or telephone numbers end up as duplicate contacts in Gorgias?
Not if we agree the merges with you first. We identify records that share an email address or telephone number and propose merges in the migration checklist, where you confirm each one and choose which address stays primary. Each merged set becomes one contact holding all of that customer's tickets and, where Gorgias allows it, all of their email addresses. We don't merge on a guess, so records you don't confirm stay as they are.
If we use a chatbot, do you migrate it and its conversation flows into Gorgias, or only the conversations it handled?
We migrate the conversations it handled, not the chatbot itself. Every chat conversation the bot took part in comes across with your ticket history, while the chatbot's own setup isn't migrated as data and is set up again in Gorgias where it offers one. Workflows and automation rules are a separate item, and the ones you have today can be recreated in Gorgias as agreed during scoping.
Will our customers be able to see their migrated conversations in Gorgias, for example in a customer portal?
It depends on Gorgias. Migrated tickets are attached to each customer's contact record like any other ticket, so where Gorgias has a portal that shows customers their own tickets, the migrated ones can appear there, while internal notes stay private to your agents. Some portals only show tickets or replies set up in a particular way, so we confirm during scoping how imported tickets show to customers in Gorgias and check it in the sample migration.
Can our agents reply to customers from migrated tickets in Gorgias?
Yes, where Gorgias treats migrated tickets as regular tickets and your support email is connected to it. An agent's reply from a migrated ticket then goes out to the customer, and the customer's next reply continues on that same ticket. Some help desks keep imported tickets read-only, so we confirm this for Gorgias and test it on your account before your team relies on it.
Will the information that integrations show in our tickets be migrated to Gorgias?
Not if that information lives in the integration rather than in your help desk. This information is often drawn live by the integration, and where your current platform doesn't store that data or return it through its API, it can't be migrated with the tickets. The tickets and their conversations migrate as normal, and your team reconnects each integration to Gorgias after cutover.
Will fields Gorgias fills in automatically, such as AI-detected intent or sentiment, be set on our migrated tickets?
Not with your old values. Where Gorgias fills a field with its own AI, such as intent or sentiment, we leave that field out of the mapping, because the platform sets it itself: AI intent, sentiment and call status fields, for example, may not be writable through the API. The platform's own AI can still act on migrated tickets, though. Rules that analyse open tickets may tag them by detected intent and sentiment, and AI triage features can fill these fields when a note is added, so we agree with you beforehand whether those rules should skip migrated tickets.
Are there limits on how many custom fields or macros we can bring into Gorgias?
Yes. Gorgias caps the number of active custom fields an account can have, with separate limits for ticket fields and customer fields, and the fields already in your account count toward them. It also caps the number of macros. If your selection would go over a limit, we ask you to choose which fields come across, and values from the others can still be kept as tags. You can also archive unused fields, or remove macros you no longer need, in Gorgias to make room.
Why do some numbers in our migrated tickets, such as order or RMA numbers, show up partly masked in Gorgias?
Because Gorgias masks them when the messages arrive, not because of the migration. We send these numbers in full, but Gorgias automatically masks any number of 13 to 19 digits that passes a standard card-number check, keeping only the last four digits, so a long order or RMA number can be caught by it. Gorgias does this before the message is stored, so the full number isn't kept in Gorgias; its documentation describes the check as automatic, so ask Gorgias support if your team needs these numbers shown in full.
Claude
ChatGPT
Cursor
Notion
Slab
Confluence
Google Docs
