Migrating off a spreadsheet: a church data migration checklist

Most churches do not move from one system to another. They move from a spreadsheet, two spreadsheets, a WhatsApp group, the previous administrator's laptop and a filing cabinet — into one system. That is a different exercise from a migration, and it fails in different ways.

This is the checklist, in the order that actually works.

Before you export anything

1. Find every source. Ask the question out loud at a staff meeting: where is member information kept? The honest answer usually includes two places nobody listed.
2. Decide what not to bring. A membership list from 2014 with no contact details is not data, it is archaeology. Migrating it costs you cleanup time forever.
3. Name one owner. Migrations fail when three people each clean a different copy.
4. Agree the household model first. How families are represented is the single hardest thing to change afterwards.

Every hour spent deciding what not to migrate saves three hours of reconciling things you should have left behind.

Cleaning, in this order

• Deduplicate people before households. Merging duplicates after you have built family links creates orphaned relationships.
• Normalise phone numbers to international format. +27 rather than 0. This matters enormously for WhatsApp delivery, and fixing it later means re-verifying the whole list.
• Split full-name columns into first and last before import, not after.
• Standardise dates. A spreadsheet holding both 03/04/2019 and 2019-04-03 will import silently and wrongly.
• Mark deceased and departed members rather than deleting them. Giving history and 18A records still reference them.

Giving history is the hard part

Member data is forgiving; giving data is not. It feeds tax certificates, and a mistake becomes a statutory document sent to a member.

Reconcile each month of giving history to the bank statement before go-live. It is tedious and it is the step that prevents a February crisis.

Pastoral records need a decision, not a default

Counselling notes and pastoral case files should not be bulk-imported without thought. Some were written on the understanding that they lived in one pastor's notebook.

Decide deliberately what moves, who can see it in the new system, and whether the people concerned should be told. Then confirm the new system can actually enforce that boundary — see who should see what.

The consent and POPIA pass

1. Record where each person's data came from and on what basis you hold it.
2. Capture children's consents separately, from a competent person, with photography treated as its own permission.
3. Carry opt-outs across. An unsubscribe in the old system that does not survive migration is a fresh breach on day one.
4. Update your privacy notice to name the new processor before you load the data, not after.

The framework is in POPIA and your church database.

Go-live

1. Import into a test tenant first and have two people who know the congregation read fifty records at random.
2. Run both systems for one giving cycle. Not three months — one cycle is enough to catch structural errors and short enough that nobody quietly keeps using the old one.
3. Freeze the old system to read-only on a named date, announced in advance.
4. Export a full backup of the old system and store it where the church, not an individual, controls it.
5. Train on the two tasks people do weekly, not on the full feature set. Everything else can wait.

The question to ask before you start

Ask the new vendor how you get your data *out*. Format, completeness, timescale, and whether giving history and pastoral records are included.

A vendor confident about export is a vendor expecting to earn your renewal. It is also the cheapest insurance available, and it costs nothing to ask before signing — which is the only time you have leverage.