Will original ownership, authorship and created dates be preserved?
Yes. Created-time metadata is carried across, and ownership and authorship are carried across where the original users are set up in Coevera. Where Coevera cannot store one of them natively, it is kept as embedded metadata on the migrated record.
If the new system 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 Coevera, review sample records from it and propose how it can be represented, based on what Coevera 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.
If the same contact appears more than once in Kommo, or several contacts share an email address or telephone number, will the migration create duplicates or merge them?
You decide, and we don't merge records on a guess about which one is correct. Your records come across as they exist in Kommo, so duplicates that are already there can come across too, and if you want them merged, give us the matching rule you want and we apply it as a follow-up pass. The exception is a CRM that checks for duplicates through its API: it returns the existing contact instead of creating a new one, so records sharing an email address or telephone number would otherwise collapse into one contact. Where that applies, we tell you how many records are affected and let you choose. If you want a separate contact for each source record and Coevera has a setting that allows duplicate contacts, your team switches it on while we migrate them, and we tell you when it is safe to switch it off again.
Will the migration set off automations or 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 Coevera will send messages about the migrated data: we import with notifications switched off wherever Coevera allows it, and either pause any automation that could send them for the migration window or give it a condition, such as a suppression tag, that skips migrated records, which lets your live automations keep running for new 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 you migrate data that Coevera can't take in through an API?
In many cases, yes. Where something can't be written through an API, we recreate it through Coevera's user interface 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.
Can you migrate only the data added to Kommo since our last migration?
Yes. We find the exact point in Kommo where the earlier migration ended and move only the records added after it. Records that were already migrated are not brought across a second time.
What happens if Coevera requires fields our Kommo data doesn't have?
We check the destination for required fields your source 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 Coevera 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.
Will contacts that are already in Coevera get duplicated?
They don't need to be. We can check each contact against the contacts already in Coevera before creating it, so a contact the matching rule identifies as already there is matched to the incoming record instead of being created a second time. We agree the matching rule with you before the migration runs.
Can I choose how my Kommo pipeline stages and statuses map into Coevera?
Yes. You tell us where each stage, status and field should land in Coevera, including moving records into a different pipeline or stage name than the one they have today. We build that mapping into the migration scripts, show it to you in a sample migration, and adjust it before the full run if anything needs to change.
Can I rename my Kommo custom fields in Coevera after the migration?
Yes. We agree with you beforehand where each custom field lands in Coevera and what it is called. We map fields by their internal ID rather than their label, so renaming them in Coevera after the migration doesn't affect your migrated data.
Can you map my Kommo data into the custom fields I already use in Coevera, so my workflows and automations keep working?
Yes. We map your Kommo data straight into the fields you already have in Coevera rather than creating duplicate fields or tags alongside them. Your workflows and automations keep reading the same fields they rely on today, and you review the mapping in a sample migration before the full run.
How will we tell migrated records apart from the ones already in Coevera?
We can mark every migrated record in Coevera, for example with a custom checkbox field such as "Migrated from Kommo", so your team can tell migrated data apart from records created there. We agree the marker with you during scoping so it fits how your team uses Coevera.
How do you handle custom objects, pipelines and record relationships when moving from Kommo to Coevera?
Custom objects, pipelines and the links between records are migrated as agreed during scoping, so deals stay attached to their companies and contacts and custom object records keep their associations. We map each object and pipeline to Coevera's data model with you, agree how to represent anything without a direct equivalent, and run a sample migration so you can check the structure before the full move.
We use a lot of custom fields in Kommo. Can you map them to Coevera?
Where Coevera has a place for them, yes. Each migration is a custom script written for your project, so your custom fields and structure are mapped to Coevera's model rather than forced through an import template. Where field types differ, such as a value stored as text in Kommo that Coevera needs as a number, the script converts it. We agree the mapping with you and prove it on a sample migration before the full run.
How will my records carry over if Coevera organizes leads, contacts and accounts differently from Kommo?
We map your records to the way Coevera structures them, so each type of record lands where Coevera expects it instead of being copied field for field. Before we build anything, we send you a migration checklist showing what moves and where each item lands, for you to review. Most data moves through the platforms' APIs; where an API cannot write something, we fall back to CSV import or manual entry.
Can you migrate the email history on our mail server, such as Microsoft Exchange, along with our Kommo records?
Yes, on a best-effort basis where Kommo has no clean way to export it. For team members who are still with you, Coevera may be able to sync their mail itself once each person's email account is connected; for people who have left, we bring their messages in as notes on the right records, retrieving them from Kommo or your Exchange server, so the history stays intact and attributable.
Can you migrate our Kommo sales sequences, email templates and automation flows to Coevera?
Partly, depending on Coevera. Email templates are generally the simpler part to move, while sequences, flows and automations are rebuilt rather than copied, because each CRM builds automations differently. Where Coevera's API lets us create them, we set them up programmatically; where it doesn't, they are built through its interface, by us with a login or by your team, and we confirm which items fall where during scoping.
Will the emails and files stored on our Kommo contacts migrate to Coevera, including for inactive accounts?
Yes. Emails and files stored on your contacts can be part of the migration, including those on inactive accounts, and you choose which records and how much history come across. Files come across as actual files, attached to the matching records in Coevera. Where an email's original user has no account in Coevera, we can bring it across as a note on the contact instead. If Coevera syncs email from connected email accounts, you can leave active users' mail to that sync and have us migrate the rest.
Do you migrate our Kommo bulk marketing emails as well as one-to-one emails with contacts?
It depends on which you need, and we confirm that before anything is pulled. Some CRMs keep bulk marketing emails, such as broadcasts, separately from one-to-one emails with contacts, so we agree with you which types are in scope and share a sample of them to review. One-to-one emails linked to your contacts and companies come across with those records, and bulk marketing emails can be included too, for example as an archive export you keep if Coevera has no place for them.
Can you migrate the history of our Kommo deals' stage changes to Coevera, not just their current stage?
Yes, where Kommo records stage changes and Coevera can hold them. Deal-stage history is scoped like any other data: we check what Kommo keeps for each deal's stage transitions, agree with you how that history is represented in Coevera's data model, and you review it in the sample migration before the full run.
Can you migrate emails that are private to individual Kommo users, not just the emails linked to contacts and deals?
Yes, where Kommo's API gives us access to them. On some CRMs, the API returns only emails linked to a record plus the private emails of the user whose account is connected, so each colleague whose private emails you want included connects their own account. Private emails that aren't linked to any contact or deal have nothing to attach to in Coevera, so we agree with you where they go, for example on a dedicated contact for each user, with the email content kept searchable.
What happens to a file in Kommo that is linked to several records if Coevera only lets a file belong to one?
We can attach a copy of the file to each record it was linked to, so it can still be found from every one of them. If you'd rather keep a single copy, we agree with you which record it lives on. You check how linked files land in the sample migration before the full run.
Can you migrate our Kommo products and customers' purchase history to Coevera, not just contacts?
Yes, where Kommo's API makes them available. Products and purchase records are scoped like any other data: the migration checklist covers products alongside contacts, notes and tags, and we confirm what each platform's API can read and write before anything runs. Where Coevera has no native home for purchase history, we agree another form with you, such as a custom field or a note on the contact.
Do you migrate our Kommo notes, tasks, activities and files to Coevera, or only contacts and deals?
Yes, all of them can come across, not just contacts and deals. Notes, tasks, activities such as events and emails, and files can be included alongside contacts, companies and deals, each linked to the record it belongs to, with owners kept where those users exist in Coevera. Tasks are migrated with the contacts they are linked to. Where Coevera's version of an item holds less, for example lighter tasks, we agree with you how the extra detail is kept, such as a note on the same record.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
