It’s a quiet afternoon a few weeks before the move. Someone on your team has pasted every export into one spreadsheet and sorted it by last name, and the same name comes up three rows in a row. Is that one person or three? Nobody in the room is quite sure.
Every migration guide says to clean your data. Few say what that means. Most of the work is that one problem: the same person, in several lists, looking slightly different in each.
If you run giving in one tool, check-in in another, groups in a third and email in a fourth, each one has its own copy of each person. Moving everything into one place for everyone means those copies have to become one person again. Get it wrong one way and you have two Sarahs, with half her history each. Get it wrong the other way and you’ve merged a mother and daughter who share a name and an address.
This post covers how duplicates happen, how to decide what counts as a match, and why the final call should always be a person’s. It applies whatever you’re moving from and whatever you’re moving to.
Why the same person shows up twice
- Name variations. Jon and Jonathan. Liz, Beth and Elizabeth. A maiden name in giving and a married name in groups.
- Shared contact details. A couple using one email address. A family phone on three children’s check-in records.
- Old details. An address from two moves ago in one tool and the current one in another.
- Typing. A connect card read by one person and typed by another. A space in the wrong place.
None of these are anyone’s fault. They are what happens when separate tools each collect their own version of a person for years.
First, map the columns
Before you can compare records, the fields have to line up. One export calls it “Mobile”, another “Cell”, a third has “Phone 1” and “Phone 2” and nobody remembers which is which. Dates arrive in three formats. Names come as one field in one tool and two in another.
Mapping is tedious and easy to get subtly wrong. Software can suggest a mapping from the column names and a sample of the values. A person who knows the data should confirm it, especially the odd columns: the custom field someone added in 2019, the notes column that turns out to hold allergy information.
Then decide what counts as a match
Agree on the rules before anyone looks at a single pair. It stops the decision changing depending on who is doing it and how tired they are.
| Signal | Examples |
|---|---|
| Strong | Same email and same last name. Same mobile number and same date of birth. |
| Worth a look | Same last name and address, different first name. Same first name and phone, different last name. |
| Not enough on its own | Same name only. Same household email only. Same address only. |
Your rules will differ. A church with many multi-generation households needs to be careful with shared addresses. An association where every member has a unique license number can match on that and very little else.
Review in pairs, with the reason
A good review shows two records side by side, with the reason they were paired: “same mobile number, first names Jon and Jonathan, same street.” The reviewer can see at a glance whether it’s obvious or needs a closer look. Without the reason, they have to work it out every time, and they start guessing.
Each pair ends in one of four decisions.
- Merge: the same person, with one record kept and the history from both brought together
- Keep separate: two different people who happen to look alike
- Link as a household: different people who share an address, an email or a phone
- Come back later: not enough to decide, so it goes to someone who knows the person
The fourth option matters. A reviewer who is forced to choose will choose wrong sometimes. Send the unsure pairs to the person who knows the member: the group leader, the finance lead, the chapter secretary.
Why nothing should merge automatically
Automatic merging is tempting when there are thousands of pairs. The trouble is the cost of a wrong merge. Two people’s giving history combined means a wrong giving statement. A parent merged with a child means the wrong person is authorized to pick up from check-in. A wrong merge can be hard to spot and harder to undo.
A missed duplicate, by contrast, is cheap. It shows up later, someone notices, and it gets merged then. So the default should lean toward asking. Whatever tool you use, keep your original exports untouched, and keep a note of every merge: which two records, who decided, and when.
Doing it without any new software
You can do a first pass in a spreadsheet. Combine the exports into one sheet with a column saying which tool each row came from. Sort by email, then by mobile number, then by last name and street. Mark pairs as you go. It’s slow, and it will show you quickly how many of your people exist in more than one place.
What we build
Our assistant helps with exactly this, and it’s part of every build (import help: maps spreadsheet columns, finds likely duplicates, asks before merging). It suggests the column mapping for a person to confirm, pairs likely duplicates with the reason for each, and waits. Nothing is merged until someone on your team says yes. Every suggestion and every send is logged. Any feature can be turned off, and usage cost is visible every month.
More on how the assistant works, and the rules it keeps, is on the AI Assistant page. For the rest of the move, the migration guides go phase by phase.
- Leaving One Church Software: what to plan for
- Replacing Planning Center without losing a Sunday
- How to migrate from Hivebrite
- What the assistant does, and the rules it keeps
If you’d rather talk it through with us, Book a 30-minute call.