Answers
Moving between Keap and HighLevel
People move both ways and both work. What follows is the same either way; only the names swap.
Clean up first, even with one CRM
Before anything moves, decide what is worth moving. Turn on CRM Migration in Settings → Modules with only your current CRM connected, and its Clean-up review lists four things: contacts that share an email address or a phone number, contacts with no email or phone at all, the junk by rules you choose (tags, owners, contact type), and the contacts with no paid order and no deal in the years you pick. Every list downloads whole, and on Keap every name opens the record in Keap in a new tab, so you merge, fix or delete it there with the reason in front of you. The review reads the copy of your contacts we already keep and changes nothing in your CRM. A fixed email or phone shows with the next data refresh, and a record you merge away or delete leaves the lists after the nightly full read of your contacts. Inactive is judged on paid orders and deals; when your revenue counts from QuickBooks, it is not built at all, because the review cannot yet tell which contact paid which invoice. It is for owners and admins, because every list carries emails and phone numbers.
On Keap, the review also reads each contact the way it was typed (names, addresses and phone numbers) once a night, and adds every finding up into your migration plan: one recommendation per contact, so dirty records do not travel into the new system. Leave behind is for contacts with no real way to reach them, test entries and names a web form bot made. Fix first is for an address typed whole into one field (split back into street, city, state and ZIP using the cities your own clean addresses already use), a state your CRM did not recognise or a blank one the ZIP can fill, and a phone number that is not one. Merge first is for duplicates. Keep is for your own team, learned from the email domains of the people who sign in here and the users in your CRM. A reason to keep always wins: a contact who has paid you, or who is on your own domain, is only ever marked check by hand, never leave behind, because deleting a contact deletes its order history too. The plan and each of its lists download whole. Contacts carrying your Do Not Contact tag are flagged on every row and never left behind, so the new system can be told never to contact them. The first plan arrives with the nightly full read after CRM Migration is turned on. After cleaning up, press Refresh from Keap above the tabs to read Keap again right away rather than waiting for the night: contacts the clean-up tagged count as done, and contacts merged away leave the lists and the ProDBX file.
Clean up in Keap. Under the plan, an owner or admin can have the fixes written into Keap. Nothing is written until you allow it once, and then every batch is a dry run first: it reads each contact in Keap as it is now and lists exactly what would change, from what to what. Only when you tick the box under that list and press Apply is anything written, and only where Keap still holds what the dry run read. Addresses typed into the wrong fields are split back into their fields, state spellings corrected, and phone numbers with +1 in front written the way most of your own numbers are. Nothing is ever deleted: contacts to leave behind or check by hand get a tag (Migration: leave behind, Migration: check by hand), and you delete in Keap by that tag when you are sure. Every batch can be undone, and every write is in the activity log.
Merge duplicates in Keap. Below that, the same person’s records can be merged into one: records that share an email, or carry the same last name, the same phone number and the same first name or its short form (Jeff and Jeffery, or Joy beside a “Joy & Cary” record). A phone shared under two different names is most often a family member or an office line, so it is never merged here and the plan marks those to check by hand. The contact with a paid order is kept, else the one holding the most, and Keap’s own merge carries the others’ tags, notes and orders onto it. Any email or phone the kept contact lacks is written onto it first, so nothing is dropped, and an address that was opted in stays opted in. It uses the same permission as the clean-up, and every batch is a dry run first and your confirm second. A duplicate holding a subscription is left for you to merge by hand. A merge cannot be undone: Keap deletes each duplicate. What each one held is kept, so it can be entered again by hand.
Moving to a system we do not connect to? The review is still where to start. Moving to ProDBX from Keap, the plan ends in Download the ProDBX file: every contact you keep, in ProDBX’s own upload layout, with customers (anyone with a paid order) and leads on separate tabs and a third email or phone onward on its own tab. Contacts tagged Migration: leave behind are left out, as Keap holds that tag when you download, unless they are on your Do Not Contact list; placeholders are left blank; US phones are written 479-555-0100 and dates MM/DD/YYYY, as ProDBX asks; customerid is left for ProDBX to assign, and each row carries the contact’s Keap id in legacy_customer_number, so alternate contacts, notes and jobs moved later can find their customer. It only reads: nothing in Keap changes. Pairing your deal stages with the new system’s stages is not built yet.
Connect both first, and decide which one wins
Connect the new CRM alongside the old one. As soon as both are live, MyVitalAssistant asks a question it will not answer for you: which is the source of truth. The other becomes read only, and from that moment nothing is written there. Two systems writing the same contact is how a record ends up with two versions of the truth and no way to tell which is newer.
Answering “I am still deciding” is a real answer. It parks the question for thirty days and stops asking, then raises it again on its own, because somebody comparing two systems has answered and pestering them to hurry teaches them to lie to the screen.
Do a dry run, and actually read it
The migration shows you exactly what it would do before it does anything: how many contacts move, which ones already exist on the other side, and which will be skipped. Read it. This is the one step people skip and the one where a surprise is cheap to fix and expensive to discover afterwards.
What moves and what does not
Contacts move, with their attribution, so a customer who arrived from a Google ad two years ago still says so afterwards. Historical revenue does not move, and should not: it already exists in your reports here, and copying old orders into a new CRM creates records its automation may act on, which is how somebody gets a receipt for a sale from last March. Your dashboard keeps the whole history regardless of which CRM is connected today.
The part that actually bites: whether they can be emailed
A contact created without consent evidence lands unmailable, and stays that way until somebody notices the sequence never ran. The migration does not carry consent across: it cannot read why each person agreed to be emailed, so every contact it creates in Keap arrives unmailable, on purpose, because inventing consent during a migration is the one mistake nobody can undo. Plan how you will confirm consent again on the other side before your first campaign there.
Once you have moved
Disconnect the old CRM when you are done, not before. Disconnecting offers to remove the tracking fields it holds; leave that unchecked unless it is a permanent goodbye, because the attribution values on your contacts go with them and Keap will not give the field names back if you want them again.
Your tracking snippet, your forms, your call number map and your reports do not change. They point at the account, not at the CRM.