Somebody has been quietly running the church database for two years, and now they are moving, or stepping back, or just tired. The database itself will survive the transition fine — it is a record, not a person. What will not survive on its own is everything that lived only in that volunteer's head: which families are actually one household split across two records for a reason, why three people show as inactive when they still come most Sundays, who was supposed to call the visitor from three weeks ago.
A good handoff is not a farewell speech. It is a short, specific document plus one walkthrough, aimed at making sure the new person inherits the judgment calls, not just the login. Here is what belongs in it.
Start with the open loops, not the whole system
The instinct is to explain the entire database from the top: here are people, here is giving, here are groups. Resist it. The new volunteer will learn the screens by using them. What they cannot learn by clicking around is what is currently unfinished — the guest who was supposed to get a call, the volunteer whose background check is pending, the pledge that still needs correcting from a data-entry slip in March.
Walk the outgoing admin through the follow-up board first and have them narrate every card that has no clear next step. This is where things quietly die during a transition — not because the new person is careless, but because a guest who exists only as a name in someone's memory does not exist to the person taking over at all.
Write down the household exceptions
Every church database accumulates a handful of households that do not fit the pattern: the couple who separated and now need two records instead of one, the adult child still listed under a parent's household out of habit, the blended family with two last names and one address. None of this is wrong, exactly, but none of it is obvious either. If you have opinions about how households should be structured in your church specifically, write them down as a short list of examples rather than a rule, because the exceptions are almost always what trips up the next person.
The same goes for anyone marked inactive who is not actually gone. Churches use inactive status for all kinds of reasons — a six-month mission trip, a member who asked to be left off the mailing list but still attends, a family that only comes at Christmas and Easter and does not want weekly contact. A new volunteer who does not know the reason behind each one will either leave them alone indefinitely or start reactivating people who asked not to be, and either mistake is avoidable with two minutes of explanation.
Explain the giving records before you hand over the keys
Giving is the part of the database where a handoff mistake actually costs money, so it deserves its own conversation rather than a line in a general walkthrough. Show the new volunteer where contributions are entered, how a correction gets made if an amount was typed wrong, and where the giving goals live. If your church has just come through a year-end statement run, mention it explicitly — the next person should know that statements for the prior year already went out, so they are not tempted to regenerate them and confuse anyone.
This is also the moment to say out loud who else can see this information. SundayBridge does not have staff roles or separate logins — it is one shared login per church — so giving records sit behind the same access as everything else. If your church has an informal rule about who actually opens that screen, the new volunteer needs to hear it from you, not discover it later.
Hand over serving teams with the context, not just the roster
A list of volunteers and their roles is easy to read straight off the screen. What is not on the screen is why a particular person has not been scheduled in three months, or which background-check alert on the dashboard is a paperwork delay versus something that actually needs following up. Go through the serving team list together and flag anything that looks like it needs a decision rather than a click.
If your church has a rhythm for scheduling volunteers — a Tuesday check on the coming Sunday, a monthly look at who is overdue for a break — write down when it happens and who currently does it. A schedule that lives only in one person's calendar disappears with them.
Do a walkthrough of the weekly and monthly habits
Every church database develops a weekly admin rhythm: something checked every Sunday, something reviewed once a month, something that only comes up at year end. If your church has already written that rhythm down, that document is most of your handoff already done. If it has not, this is the moment to write it, because you are about to lose the person who has been carrying that rhythm in their head.
Sit down together and click through an actual week: what gets entered after the Sunday count, what the follow-up board looks like on Monday, what gets reviewed before the monthly meeting. Reading a list of tasks is not the same as watching someone do them in order, and the order matters more than people expect.
Do not skip pastoral care and groups
Pastoral care is the module most likely to get glossed over in a handoff, usually out of good intentions — the outgoing volunteer does not want to gossip, so they say little, and the new person inherits a set of cases with no sense of which ones are settled and which ones are still open wounds. Say plainly which cases need a comment added soon, which ones are closed but should stay visible for context, and who besides you has ever needed to see this information. Discretion matters, but silence is not the same thing as discretion, and a case that quietly stalls because nobody told the new admin it existed helps no one.
Groups deserve a similar pass, even though they change hands more casually. Confirm which groups are actually meeting versus which ones exist in the database from two years ago and never got closed out, and make sure the new volunteer knows who the current leaders are, since that is the piece most likely to have drifted since the last time anyone updated the list. The same goes for any upcoming gathering on the calendar with registrations already coming in — the new person should know it is there before a registration question lands in their inbox with no context at all.
Give the reports a tour, not just a mention
The database holds twelve reports across attendance, giving, serving, and groups, and most churches only use two or three of them regularly. Tell the new volunteer which ones your church actually looks at and why — the giving trend before a budget meeting, the attendance chart the pastor likes to see monthly — rather than leaving them to discover all twelve on their own. Show them how to add or edit a missing Sunday with a named roster or headcount, and explain that the reports built from those records remain read-only.
Show them the CSV export on the directory too. It is the quiet safety net under the whole handoff — a plain spreadsheet of every person in the database, sitting outside SundayBridge, that the new volunteer can pull anytime they want a second copy of the list to check against.
Leave a short written document, not a long one
Everything above turns into a document of maybe two pages: the open follow-ups, the household exceptions, who sees giving, the serving notes, the weekly rhythm, which reports matter. Longer than that and nobody rereads it after the first week, which defeats the point. Put it somewhere durable — a shared drive folder, not an email that will get buried — and date it, so six months from now the next person after this one can tell whether it is still current or needs a rewrite of its own.
A church database is never really finished changing hands. Someone will hand it off again in a year or three, and the document you write this week is the thing that makes that next handoff faster than this one was.