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 Affinity. Where Affinity 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 Affinity, review sample records from it and propose how it can be represented, based on what Affinity 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 Redtail CRM, 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 Redtail CRM, 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 Affinity 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 Affinity will send messages about the migrated data: we import with notifications switched off wherever Affinity 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 Affinity can't take in through an API?
In many cases, yes. Where something can't be written through an API, we recreate it through Affinity'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 Redtail CRM since our last migration?
Yes. We find the exact point in Redtail CRM 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 Affinity requires fields our Redtail CRM 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 Affinity 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 Affinity get duplicated?
They don't need to be. We can check each contact against the contacts already in Affinity 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 Redtail CRM pipeline stages and statuses map into Affinity?
Yes. You tell us where each stage, status and field should land in Affinity, 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 Redtail CRM custom fields in Affinity after the migration?
Yes. We agree with you beforehand where each custom field lands in Affinity and what it is called. We map fields by their internal ID rather than their label, so renaming them in Affinity after the migration doesn't affect your migrated data.
Can you map my Redtail CRM data into the custom fields I already use in Affinity, so my workflows and automations keep working?
Yes. We map your Redtail CRM data straight into the fields you already have in Affinity 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 Affinity?
We can mark every migrated record in Affinity, for example with a custom checkbox field such as "Migrated from Redtail CRM", 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 Affinity.
We use a lot of custom fields in Redtail CRM. Can you map them to Affinity?
Where Affinity 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 Affinity's model rather than forced through an import template. Where field types differ, such as a value stored as text in Redtail CRM that Affinity 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 Affinity organizes leads, contacts and accounts differently from Redtail CRM?
We map your records to the way Affinity structures them, so each type of record lands where Affinity 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 Redtail CRM records?
Yes, on a best-effort basis where Redtail CRM has no clean way to export it. For team members who are still with you, Affinity 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 Redtail CRM or your Exchange server, so the history stays intact and attributable.
Can you migrate our Redtail CRM sales sequences, email templates and automation flows to Affinity?
Partly, depending on Affinity. 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 Affinity'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.
Do you migrate our Redtail CRM 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 Affinity has no place for them.
Can you migrate the history of our Redtail CRM deals' stage changes to Affinity, not just their current stage?
Yes, where Redtail CRM records stage changes and Affinity can hold them. Deal-stage history is scoped like any other data: we check what Redtail CRM keeps for each deal's stage transitions, agree with you how that history is represented in Affinity's data model, and you review it in the sample migration before the full run.
Can you migrate emails that are private to individual Redtail CRM users, not just the emails linked to contacts and deals?
Yes, where Redtail CRM'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 Affinity, so we agree with you where they go, for example on a dedicated contact for each user, with the email content kept searchable.
Can you migrate our Redtail CRM products and customers' purchase history to Affinity, not just contacts?
Yes, where Redtail CRM'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 Affinity has no native home for purchase history, we agree another form with you, such as a custom field or a note on the contact.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
