Will the original assignees, message authors and created dates be preserved when we migrate to Desk365?
Yes. Created-time metadata is carried across, and so are assignees and message authors who have a user account in Desk365. Where Desk365 cannot store one of them natively, it is kept as embedded metadata on the migrated record.
If Desk365 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 Desk365, review sample records from it and propose how it can be represented, based on what Desk365 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.
Will migrating to Desk365 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 Desk365 will send messages about the migrated data: we import with notifications switched off wherever Desk365 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.
Will you migrate our knowledge base articles to Desk365 as well as our tickets?
Yes. Knowledge base articles can be part of the same migration as your tickets, and move into your Desk365 knowledge base.
Can we migrate only the contacts who have tickets to Desk365, 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 Desk365.
Can you migrate data that Desk365 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 Desk365 match the originals?
We run verification checks that compare each migrated ticket in Desk365 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 Desk365, 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 Desk365. You check the result in a sample migration before the full run begins.
What happens if Desk365 requires fields our current data doesn't have?
We check Desk365 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 Desk365 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 Desk365, 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 Desk365 holds the history your team will actually use.
Will our custom ticket fields map to the right fields in Desk365?
Yes. Before anything runs, we map each of your custom fields to its destination field in Desk365 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 Desk365?
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 Desk365'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 links between our records still work after we migrate to Desk365?
Yes. We move your data in two passes. The first pass creates every record in Desk365 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.
Can you combine data from several support tools into one Desk365 account?
Yes. Each tool's data is extracted separately and written into the same Desk365 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.
Can you fix tickets that are linked to the wrong company as they move to Desk365?
Yes, where Desk365 lets a company be set on each ticket. Each migration runs as custom scripts against the source and destination APIs, so we can set the correct company on each ticket as it is written to Desk365. We agree the assignment rules with you first. The corrected links show up in the sample migration, so you can check them before the full run.
Can ticket watchers or followers be migrated to Desk365?
Yes, where your current platform records them. We read the watcher list from each ticket and, where a watcher has an agent account in Desk365, matched by email, add them as a watcher on the matching migrated ticket. You confirm the result on the sample migration before the full run.
Will our ticket formatting, including HTML content, carry over to Desk365?
Yes. The migration script converts ticket content, including HTML, into the format Desk365 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.
What data will be migrated to Desk365, 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 Desk365, including anything that won't move, and you confirm the scope.
Are attachments migrated to Desk365, and how do you make sure none are missed?
Yes. Attachments are downloaded from your current platform and uploaded to Desk365 as real files on the same records, wherever Desk365 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.
Do we need to create our custom fields in Desk365 before the migration, or do you create them?
Usually we create them as part of the migration. Where Desk365 has no API for creating fields, we set them up through its interface, using admin access you grant us. On some platforms we ask your team to create certain fields and tell us which source field maps to each one, and we confirm which applies to Desk365 during scoping.
What happens to custom fields that have no matching field in Desk365?
You choose how each one is kept. We can create a matching custom field in Desk365, 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.
Can you migrate our data into Desk365 if another team already uses it, and merge it with the records already there?
Yes. Before creating anything, we check each incoming record, such as a company or contact, against the records already in Desk365, using a matching rule we agree with you, such as an email address or an ID. Where a match is found, the migrated data is attached to the existing record. Records with no match are either created as new records or set aside on a list for your team to review, whichever you prefer, and if you already keep a mapping between the two systems' names or IDs, we can apply it in the migration scripts. We also map your data into the fields the other team already uses rather than adding duplicate fields alongside them.
Can you set the same value on a field for every record you migrate to Desk365, such as labelling every contact's phone as 'Mobile'?
Yes, as long as Desk365 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 Desk365 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 Desk365 allows?
We handle it in the migration scripts. Fields where Desk365'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 Desk365, 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 Desk365 using its own conditions and actions, since automations don't copy across platforms as they are. Where Desk365'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 Desk365 before the migration?
Usually your team creates them, but we can do it for you. We recommend setting up your users in Desk365 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 Desk365 allows it.
Will the migration delete or overwrite any data that's already in Desk365?
No. The migration adds your records alongside what is already in Desk365, 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 Desk365 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 Desk365 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 Desk365's plan limits or storage charges?
It depends on your Desk365 plan. Migrated records arrive as regular records in Desk365, so whether they count toward its record or storage limits is set by Desk365'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 Desk365?
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.
If our exported tickets have no status, what status will they get in Desk365?
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 tickets that have no customer email address still be migrated to Desk365?
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.
Can you migrate tickets that belong to private or restricted categories into Desk365?
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 Desk365, 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 Desk365?
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 Desk365 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 Desk365?
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 Desk365 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 Desk365?
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.
Will a customer with several email addresses or telephone numbers end up as duplicate contacts in Desk365?
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 Desk365 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 Desk365, 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 Desk365 where it offers one. Workflows and automation rules are a separate item, and the ones you have today can be recreated in Desk365 as agreed during scoping.
Will our customers be able to see their migrated conversations in Desk365, for example in a customer portal?
It depends on Desk365. Migrated tickets are attached to each customer's contact record like any other ticket, so where Desk365 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 Desk365 and check it in the sample migration.
Can our agents reply to customers from migrated tickets in Desk365?
Yes, where Desk365 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 Desk365 and test it on your account before your team relies on it.
Will the information that integrations show in our tickets be migrated to Desk365?
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 Desk365 after cutover.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
