Resources 9 min read

How to Leave Subsplash Without Losing Your App

August 10, 2026

Short answer

You can leave Subsplash without losing your church app audience. Start before your service ends. First, confirm the contract and notice window. Secure the Apple and Google developer accounts. Export the data and media your agreement allows. Keep giving live while you rebuild and test the replacement. Then release the new app in stages. Do not cancel the old service until the new app and final exports are verified.

Most churches do not fear the rebuild. They fear losing the app listing, donor habits, sermon files, or member records along the way. Those risks are real, but they can be managed. The safest migration is a controlled handoff with two systems running for a short time.

This guide uses a 30-day working plan. Your contract may require more notice, so read the signed agreement first and confirm dates with Subsplash Client Success or Support. A public guide cannot change your exact service terms.

Before day 30: confirm the exit rules

Find the signed order form, service agreement, renewal date, and any later amendments. Put these answers on one page:

  • What is the current service end date?
  • How much notice is required to prevent renewal?
  • Who must receive the notice, and in what form?
  • Which data, media, and reports can the church export?
  • How long will access remain available after notice?
  • What transition help is included or available for a fee?

Send the cancellation or non-renewal notice through the method named in the agreement. Ask for written confirmation of the final date. Keep that confirmation with the project plan.

Days 30 to 24: map every account

The most important migration document is not a feature list. It is a one-page list of every account and who controls it. Use our companion guide, Who Owns Your Church App?, and record the legal owner, admin contact, recovery email, and billing contact for each system.

Apple and Google developer accounts

Confirm whose organization name appears in Apple Developer and Google Play Console. If the church controls the accounts and listings, a replacement app may be able to ship as an update to the existing listing. That can preserve the familiar app name, reviews, ratings, and installed audience.

If the listing is under another account, ask what transfer path is available. Apple and Google each set technical and eligibility rules for transfers. Do not promise staff that a transfer will work until both the current holder and the new developer have checked the live store requirements.

Domains, analytics, and communication tools

Check the domain registrar, DNS, website analytics, email sender, SMS provider, livestream accounts, podcast feeds, and push notification credentials. The new app can work and the move can still fail because a former volunteer owns the recovery email.

Days 23 to 18: export and verify

Export everything the agreement and admin tools allow before service ends. Keep the original files unchanged and make a working copy for the migration team.

  • People and groups: member records, group rosters, volunteer lists, and permission fields.
  • Giving: donation history, fund names, recurring gift reports, payout records, and reconciliation reports. Saved card and bank details may not be exportable.
  • Media: sermon video, audio, artwork, descriptions, speaker names, dates, series, captions, and podcast information.
  • Events and forms: upcoming dates, registrations, form fields, and response exports.
  • Communications: message templates, audience segments, email records, and SMS or push history where available.
  • App records: screenshots, store descriptions, icons, privacy links, support links, and release notes.

Count the rows and files. Open a sample from every export. A folder full of files is not a verified backup. Write down any missing field while the old system is still available.

Days 17 to 12: protect giving continuity

Giving should never be a launch-day surprise. Decide whether the church will keep Subsplash Giving for a period, move giving at the same time, or use its existing processor inside the new app.

If recurring gifts must move, ask the current and future giving providers for the exact process. Saved card and bank details are sensitive. They often cannot move through a normal spreadsheet file (CSV). Some transitions require donor action. If so, plan a clear message, a simple new form, and staff support.

Keep the old giving link live until the new one has passed small test gifts, receipts, refunds, fund mapping, deposits, and reconciliation. Never change the Sunday link first and test it later.

Days 11 to 7: rebuild the member journey

Do not copy every old screen because it exists. Rebuild the journeys people use:

  1. Find service times and locations.
  2. Watch or listen to the latest message.
  3. Give to the right fund.
  4. Register for an event.
  5. Join a group or ask for help.
  6. Receive a useful alert.

Record the old app on a real phone before access ends. Capture sign-in, screens with no content, errors, and each key flow. Those recordings make a better handoff than a list of feature names.

If you are choosing a new platform, compare the wider set in Subsplash alternatives for multi-campus churches. If your real need is a custom app that staff do not have to operate, review Rehost Faith.

Days 6 to 3: test with a small church team

Invite a pastor, a staff administrator, a finance user, a media volunteer, and two regular members. Give them tasks instead of asking whether the app looks good. Ask each person to donate a small amount, find a sermon, register for an event, update a profile, and open a push alert.

Test on at least one current iPhone, one older iPhone, one current Android phone, and one lower-cost Android phone. Check text size, screen readers, slow connections, password recovery, privacy links, and support contact details.

Days 2 to 0: release in stages

If the app can update the existing store listing, use Apple and Google staged rollouts. These send the update to a small group first. Watch crashes, sign-in failures, giving errors, and support requests. Increase the rollout when the first group is stable.

If a new listing is required, use the old app, email, the website, Sunday slides, and staff announcements to move people. Keep the old experience available long enough for active members to see the message.

On the final day, take one last export, compare the counts, confirm deposits and communications, and store the archive securely. Only then end the old service.

What not to do

  • Do not cancel before you know the export and access dates.
  • Do not assume the app listing can transfer without checking store rules.
  • Do not move recurring giving from a spreadsheet alone.
  • Do not rebuild unused features before the key member journeys work.
  • Do not launch to every member before a small group has tested real tasks.

FAQ

Can we keep our App Store reviews when leaving Subsplash?

Often, the best chance is to release the replacement through the existing listing or complete an eligible app transfer. The result depends on who controls the listing and the current Apple or Google rules. Confirm both before setting the launch plan.

Can we export all Subsplash member and giving data?

Export availability depends on the product, permissions, and agreement. Member records and reports may be available, while payment credentials and some platform data may not be. Request a written export list and verify each file before service ends.

Should we move giving and the app on the same day?

Usually not unless the old and new app teams have tested the full process. Keeping the current giving flow live during the app change lowers risk. Move the payment experience only after test gifts, receipts, deposits, refunds, and fund mapping work.

How long does a Subsplash migration take?

A focused app migration can fit inside 30 days when accounts and exports are ready. Contract notice, data cleanup, complex integrations, or a new store listing can add time. Start from the renewal date, not from the desired launch date.

Do we need to rebuild every feature?

No. Start with the member journeys used in the last 90 days. Move the data and flows people rely on, then add lower-use features after launch.

The bottom line

A safe Subsplash exit is less about speed than order. Confirm the agreement, secure the accounts, export and verify, protect giving, test real member tasks, and release in stages. If you want a team to map the move and run the replacement for you, book a migration review. Bring the agreement, renewal date, account list, and export questions. We will tell you what can move, what needs a different plan, and when staying on Subsplash is the safer choice.

Need help with the next step?

Tell us what is not working. We will help you figure out what to do next.