Moving a member roster without losing anybody

Every ministry has the same migration problem: years of member records spread across spreadsheets, an old admin system, and somebody's email. Moving that without losing anyone is unglamorous and genuinely difficult, and it is where most software projects in this category quietly stall.

This is what actually goes wrong, whatever tool you use.

Dates are the first thing to break

A real roster will contain 1979-04-12, 3/2/1981, and "Jan 5 1968" in the same column. Worse, it will contain 3/2/1981 and 25/12/1988 — one unambiguous, one not. Anything importing US-format dates will silently swap a day and month somewhere in your file.

Check dates of birth after any import by sorting on them and looking at both ends. Members born in the future or aged 120 are the ones a swapped format produces.

Deduplicate carefully, and prefer a duplicate to a merge

Match on email first — it is nearly always decisive. Phone is strong but households share landlines, so require the surname to agree before treating a phone match as the same person. Name plus date of birth is the fallback for the many rosters with no contact details at all.

Be extremely wary of fuzzy name matching. Treating "Jon" and "John" as the same person catches some real duplicates and silently merges some real siblings. Merging two people who are different people destroys information you cannot recover; importing a duplicate creates work a human notices and fixes. Those are not comparable errors and should not be traded off as if they were.

Reject almost nothing

A roster is somebody's entire membership. Refusing to import a family because a zip code has a typo is worse than importing them with the problem recorded.

The only row that genuinely cannot become a member is one with no name at all. Everything else — a malformed email, a short phone number, no household, an unrecognized relationship — should import with the issue attached so somebody can fix it with the member in front of them.

Preview before you commit, and keep the original

Never let an import write to your member list without a human seeing what it plans to do to every row. And keep the file exactly as it was uploaded — when the mapping turns out to be wrong three weeks later, you want to re-run against the original bytes rather than asking the ministry to export again.

One more rule worth holding: in an update, a blank cell means "not provided", never "delete what you already know". Getting that backwards turns a routine refresh into data loss.