How to switch church management software without losing your data (or your mind)

Switching church management software is one of those projects that everybody dreads and most churches do roughly once every five to seven years anyway. The dread is fair. Done badly, you lose data, frustrate your staff, confuse your volunteers, and spend the next twelve months explaining why this seemed like a good idea.

Done well, it's a six-week project that ends with a better tool, cleaner data than you had before, and a team that's relieved. The pattern below is what consistently works.

Before you switch: three honest questions

Why are we actually switching?

If the answer is 'the new tool has a better app' or 'the website looks nicer', you're going to be disappointed in six months. Real reasons to switch: the current tool is failing on a job you can't work around (compliance, giving processing, integrations), support quality has degraded, or the cost has grown out of proportion to the value.

If your real reason is 'we want a fresh start', that's fine, but acknowledge it. Migrations driven by frustration with the old tool tend to surface every accumulated annoyance and turn into 'while we're at it' projects. Those run twice as long as they should.

What does success look like?

Define this concretely before you start. 'Better' is not a measurable outcome. 'All current rosters intact, giving processing live by the first Sunday of next month, no volunteer locked out for more than 24 hours, board reporting unchanged in format' is measurable. Write these down.

Who is going to do the work?

This is the question that quietly determines whether the migration succeeds or fails. Migration is real work. If your part-time church admin is supposed to do it on top of their existing 20 hours a week, it will not happen on time. Either allocate dedicated time, bring in a volunteer with relevant skills, or pay for migration assistance.

The 6-week migration plan

Week 1: export everything from the old system

Before anything else, export every dataset from your current ChMS. People records, giving history, group memberships, attendance records, workflows, custom fields, integrations list. Save the exports somewhere durable with a date stamp.

While exporting, take screenshots of every custom field, every workflow, and every integration setup. The exported CSV won't capture how things were configured. The screenshots will.

Week 2: choose the new system and run a pilot import

Start a free trial with one platform. Don't sign a paid contract yet. Use the trial to test the data import on a sample: 50 to 100 real records including some edge cases (volunteers with multiple roles, families with merged duplicate records), one month of giving history, and at least one workflow.

Look for: data integrity (do the records match the source?), field mapping (did everything land in the right column?), and edge case handling. Most data loss in migrations happens here. Catch it on a sample, not on the full dataset.

Week 3: map fields and clean source data

Migration is the rare moment where data cleanup actually happens, because nobody wants to import garbage into the new system. Three cleanup jobs to do in the source CSV:

• Merge duplicate people records. Most ChMS instances accumulate duplicates over years.
• Mark inactive members as inactive. If someone hasn't engaged in 24 months, they don't need to be migrated.
• Fix data quality: missing emails, malformed phone numbers, members without households.

Week 4: migrate workflows, giving, and integrations

People data is the easy part. Workflows, giving setup, and integrations are where the real work sits.

Workflows usually don't migrate cleanly between platforms. Plan to rebuild your top three to five workflows from scratch in the new system. Use this as a moment to ask whether each workflow still serves the church.

Giving setup is the highest-stakes part of any migration. Run a test transaction. Verify the receipt looks right (DGR fund handling, ABN, tax statement). Verify funds route to the correct account. Verify data shows up in reporting. Don't go live with giving on a Sunday morning. Go live midweek.

Integrations break. Inventory them: email platform, accounting software (Xero or MYOB for most AU churches), calendar sync, livestream platform. Confirm the new platform supports each integration before you commit.

Week 5: train the team

Two staff training sessions, an hour each. First session covers daily workflows: pulling reports, updating member records, sending communications. Second session covers the less-frequent jobs: workflow setup, giving administration, troubleshooting. Record both sessions.

Most volunteers only need to know how to log in, view their roster, and accept or swap shifts. A one-page printed cheat sheet with screenshots usually does it.

Week 6: switch over and run parallel

New system is the system of record from the previous Monday. Old system is read-only after Sunday morning, kept available for two more weeks for reference, then archived.

The Sunday is a stress test. Things will go wrong. Plan for them: one person on call who knows both systems, a printed roster as paper backup, the previous Sunday's check-in data accessible if the new system has a problem during kids ministry.

The data-loss traps to avoid

Trap 1: custom fields the new system doesn't support

Old system had a 'Baptism Date' custom field. New system doesn't have that exact field. The migration drops the data because there's no obvious destination. Catch this in field mapping, not after the import.

Trap 2: multi-value fields collapsing

A volunteer with three ministry roles in the old system imports with one role in the new system because multi-role handling differs. The other two are silently dropped. Audit a sample of multi-role volunteers after import and verify the count matches.

Trap 3: giving history not importing

Some platforms allow full giving history import. Some don't. If your new platform doesn't, you'll lose visibility into multi-year donor patterns. If that matters for stewardship reporting, factor it into the decision before you sign.

Trap 4: communication history disappearing

Email opens, SMS sends, and read receipts almost never migrate. If your communication strategy depends on engagement history, accept that you're starting fresh on day one. This is sometimes a good thing (stale lists get pruned) but plan for it.

The staff and volunteer conversations

Staff: name the project, set the timeline, assign roles. The migration owner is accountable for the timeline. The technical lead handles imports and integrations. The training lead handles staff and volunteer training. These can be the same person in a small church, but the roles need to be named.

Volunteers: light touch, advance notice, simple instructions. Tell them three weeks ahead that the system is changing. Tell them what they need to do (usually nothing until switchover Sunday). Don't oversell the new system. Volunteers care about whether they can see their roster on a Saturday night, not about new features.

Members: usually no conversation needed unless you're moving to a new member-facing app. In that case, send one clear email two weeks ahead and a reminder on switchover day with the new app store link.

Frequently asked questions

Can we migrate without losing any data?

Realistically, no. You will lose some peripheral data (communication history, fine-grained engagement metrics, possibly some custom field data). You should not lose any core data (people records, giving totals, group memberships, current rosters). If your migration plan can't guarantee the core, push back hard before signing.

Should we migrate ourselves or pay for help?

If your current system has fewer than 200 active records and minimal customisation, do it yourself. If you have more than 500 records, multiple integrations, or accumulated workflow customisation, pay for help. The cost is small compared with the time you'd spend.

How do we keep giving running during the switch?

Plan a one-week overlap. Old giving system is live until the previous Sunday. New giving system goes live the following Monday. Communicate the change to recurring donors a fortnight in advance. Most recurring donors will need to re-set their transactions.

Will Floways help us migrate?

Yes. Basic data migration is free on every plan. If you want us to configure your modules and train your team, we offer a paid implementation service, scoped and quoted after we talk. There is also an optional Dedicated Support add-on (A$799 per year plus GST) that can be added to any plan, covering priority email and phone support, a named support contact, and responses within 4 business hours. We've helped churches migrate from Elvanto, Planning Center, Tithely, Pushpay, Subsplash, and various spreadsheets. Book a walkthrough at floways.co.

Where to from here

If you're seriously considering a switch, start with the export. It costs you nothing, gives you a complete data snapshot, and turns the abstract decision into a concrete one. Once the export is done, the rest of the project becomes manageable.

If Floways is on your shortlist, book a 20-minute walkthrough at floways.co where we'll show you exactly how the migration would look for a church your size, with your existing tool.