What “ownership” actually means
A church website is three things stacked on top of each other. There’s the code that builds the page your visitors see. There’s the content stored inside that code: sermons, photos, blog posts, your member directory. And there’s the domain, the address that tells the internet where to find you. Each of those three lives somewhere. The question is whose name is on the lease.
Vendors love the word “ownership” because it sounds settled. In practice it’s three separate conversations. A platform can let you keep your sermons and still own the rendering engine that displays them. Your name can be on the contract while the registrar account quietly belongs to someone else. The reassurance that lands well on a sales call usually doesn’t survive five minutes of reading the actual terms of service.
Here’s what each layer means, what each vendor tier actually grants in writing, and the questions worth asking before you sign anything.
Code ownership
Code ownership is whether the underlying files that build your website (HTML, CSS, JavaScript, the database schema, the custom integrations) can travel with you when you leave the vendor.
The short version: with most all-in-one church platforms, the answer is no. The platform is a managed software service. You’re paying for access, not assets. When you cancel, the deactivation note doesn’t include a zip file of your website’s source code, because the code was never yours.
This isn’t always obvious from the marketing copy. Sites get built. They look bespoke. Some platforms even let you tweak fonts, swap layouts, or paste in custom CSS. None of that means the underlying engine, the part that translates your content into the live page, is something you’d be allowed to host elsewhere.
A few examples drawn directly from the platforms’ published terms:
- Subsplash states in its Terms of Service that “the Subsplash Media App is owned by Subsplash” and “may not be lawfully used outside of the Service.” Cancellation results in deactivation, not export.
- Wix has no functionality to export a website’s design into standard HTML or CSS. The platform owns the rendering technology end-to-end. Migrating off Wix means rebuilding from scratch on whatever you choose next.
- Squarespace offers an XML export of your text content (blog posts, gallery items, page bodies). Templates and design elements are explicitly proprietary. The visual identity stays with Squarespace.
- Tithe.ly Sites grants that “no rights are granted to you here under other than as expressly set forth here in.” The platform reserves discretion to redesign or remove services at its sole discretion.
The contrast worth knowing: WordPress.org (the self-hosted version, not WordPress.com) is open-source software released under the GPL. The themes, plugins, and database schema are yours. You can move the whole installation to any host. WordPress.com is a hosted service with a different posture. You can export content but not the underlying code.
A custom-built site on a standard stack, whether that’s WordPress.org or Next.js or Laravel, sits in the WordPress.org camp. The code lives in a Git repository in your church’s name. Any developer who knows the framework can pick it up. The repo is the deed.
When I built Stanley Avenue Church’s site, the GitHub repository was created under their organization, the database hosting is on an account in their name, and the domain registrar account is theirs. If they ever wanted to walk away, to a different developer or anywhere else they want to go, they walk away with all of it. That’s not generosity on my part; it’s just what code ownership means when the deal is honest.
Church website code ownership comes down to a single question worth asking any vendor proposing a custom site or a hosted bundle: Can we keep the code if we end the relationship, in a form another developer could actually use? The answers fall into two camps. Vendors in the first camp say “yes, here’s the GitHub repository.” Vendors in the second camp talk around it. The second answer is the answer.
Content ownership
Content ownership is whether the data inside your website (sermons, blog posts, photos, member records) is yours to take with you, in a usable format, on demand.
Most vendors will tell you yes. Most of them mean it the way a hotel means it: yes, your luggage is yours. They just don’t always make it easy to take with you.
The technical reality, by category:
- Sermon archives. Audio and video files are usually the largest part of a church’s digital footprint. When a vendor hosts media on a proprietary streaming platform, bulk extraction is rarely a one-click operation. The vendor’s API may not even be exposed to departing customers. In practice, churches end up manually downloading hundreds of files one at a time.
- Blog posts and page content. Squarespace and WordPress.com both offer XML exports. Wix offers virtually no meaningful export of standard site structures. Subsplash does not provide bulk page export. The quality of the export determines how much manual cleanup the migration requires on the other side.
- Image and media libraries. This is the gotcha that surprises people. An XML export of a blog post often contains links to the images, not the images themselves. The image files stay on the vendor’s CDN. If you migrate too slowly, or if the vendor closes your account before you’ve crawled and re-imported every image, the photos disappear permanently.
- Member and giving data. If your website integrates with a Church Management System, you’re now juggling two ownership conversations: one for the website, one for the database. Member directories, giving histories, attendance records: the export quality varies dramatically by vendor, and recurring donor profiles almost never migrate cleanly because of payment-processor rules.
There’s also a legal blind spot here that almost nobody discusses, and it deserves naming.
In Europe, the GDPR gives individuals a right to data portability. You can demand your data back in a structured format and the company has to comply. In the United States, the closest equivalent is the California Consumer Privacy Act. But the CCPA explicitly exempts non-profit organizations. The act applies only to entities “organized or operated for the profit or financial benefit of its shareholders.” A church doesn’t qualify.
Practically, this means your church has no statutory right to demand bulk data export from a US vendor. Whatever the contract says is what you get. If the contract is silent, the vendor has no legal obligation to hand anything over beyond what their terms of service describe.
Don’t panic about it. Read the contract before signing, specifically the data export language. If a vendor’s only export option amounts to “you can copy and paste your content out manually,” that’s the answer. There’s no law that’s going to upgrade it later.
The version to ask out loud: If we leave, what do we get back, in what format, and how long does it take? The vendor should be able to answer in one sentence. If the answer is fuzzy, or routes through “contact our migration team,” that’s a fuzzy answer for a reason.
Domain ownership
Domain ownership is who is legally listed as the registrant of your church’s web address — the name on the deed, in domain terms.
Of the three layers, church domain ownership is the one where churches get hurt the most. The domain is the only piece of your digital identity that can’t be replaced. Lose it, and your search engine ranking, your email routing, your printed bulletins, your business cards, and a decade of signage all break at once.
Domain ownership turns on two questions: who is the registrant, and who controls the DNS.
The registrant is the legal owner of the domain, listed in the WHOIS database. When a church buys an “all-in-one” bundle from a vendor, the vendor sometimes registers the domain in their name as a convenience. They handle the renewal, the DNS, the email routing, all transparently. It feels like a service. Then comes the day the church wants to leave, and the vendor’s name on the WHOIS record means the vendor’s name on the deed.
This is not always malicious. It’s often just how the vendor’s onboarding flow works. But the legal effect is the same. If you’re not the registrant, you don’t own the domain.
The Methodist denomination’s general finance agency, the GCFA, recommends that the church always be the registrant — using an administrative email like admin@yourchurch.org, never a volunteer’s personal email or a developer’s agency email. This sounds obvious. It’s also the most common ownership mistake churches make.
DNS control is who gets to point the domain at a website. Even if you own the domain, if the vendor controls the DNS settings and refuses to update them, your new website cannot go live. There are documented cases of churches caught in exactly this bind.
In February 2025, BridgePoint Bible Church was locked out of its own domain (bridgepointbible.org) for months. An old account they no longer had access to carried an unpaid invoice of $1,323. The church couldn’t add the domain to a new account without paying the invoice, and they had no way into the legacy account to settle it. The domain sat hostage to a billing dispute while the website ran at risk of going dark.
In the indie or custom-build version of this, the developer creates the registrar account in the church’s name, with the church’s email and credit card on file. The developer accesses the account by being added as a delegated user, never as the owner. If the relationship ends, the developer’s access ends. The church keeps everything.
There’s one more landmine specific to the domain layer. ICANN, the global authority that governs domain names, has a rule that any change to a domain’s registrant information triggers a mandatory 60-day transfer lock. The lock exists to prevent hijacking. It also catches a lot of churches by accident.
Here’s how it bites. A church decides to leave their vendor. They look at the WHOIS record and realize the vendor’s email is on it. They ask the vendor to update the contact information to the church’s email. That update triggers the lock. The church is now legally prohibited from transferring the domain to a different registrar for two months. No registrar can override it.
The fix is doing the steps in the right order: transfer the domain to a registrar in the church’s name first, then update the contact information. Done correctly, no lock fires. Done backward, the church waits two months while their old vendor still controls the domain.
(ICANN voted in March 2025 to remove this 60-day lock. Implementation will take eighteen months or more, which means as of mid-2026 the lock is still in effect.)
Find these answers before you talk about leaving: Whose name is on the domain registration? Whose credit card is on file? Can we log in directly to the registrar account today?
Common ownership gotchas
A few patterns show up often enough in church website ownership that they deserve names. Before the patterns, here is how the major platforms stack up across the three layers:
The bolded rows are the only configurations that grant ownership across all three. Everything above them is some version of rented infrastructure with the lights on.
The registrant bait-and-switch
A vendor offers a “free domain” with the bundle. They register it in their corporate name to simplify setup. The church reads “free domain” and signs. Two years later the church wants to leave; the vendor calls the URL their property and asks for a release fee.
The subdomain staging trap
Vendors often build the church’s site on a staging URL like yourchurch.platformname.org and treat it as the live site for weeks or months while domain configuration drags. Search engines index the staging URL. Members start sharing links to it. The church accumulates SEO equity and inbound links on a domain the vendor controls. By the time anyone realizes, the cost of cutting over feels too steep to bother.
The bundled media black hole
Many church bundles unify website hosting, sermon streaming, online giving, and the church management system into a single contract. A church wants to switch only the website to a different developer. The vendor explains that all four services are tied together: leaving the website means leaving the giving processor too, which means the donations team has to manually move every recurring donor. The friction is the contract, not the technology.
The “design elements” clause
Most platforms grant content ownership while explicitly carving out the templates, layouts, and stock imagery as the platform’s intellectual property. You can take the words. You cannot take the look. Leaving means a ground-up redesign on whatever comes next.
None of these are illegal. None of them are even unusual. Reading the contract before signing is the only protection.
A short checklist before you sign
Five questions, asked in writing, that filter out the worst contracts. Any vendor who calls themselves church-friendly should answer all five clearly. If a vendor hesitates, redirects, or routes a question through “let me check with my manager,” that hesitation is the answer.
- Is the domain registered in our church’s name, with our email and credit card on file? Will we have direct registrar login from day one?
- If we cancel, do we receive a complete copy of the website’s source code in a form another developer could host elsewhere?
- What does our content export include? Sermons, blog posts, images, page content, member data — itemized, with file formats and a target turnaround time, in writing.
- Are the website, giving, sermons, and ChMS bundled into a single contract? Can we leave one service without losing the others?
- Who controls the DNS records? Will we have direct DNS access at our registrar, or do we route changes through your support team?
A good vendor answers these in five sentences. A bad one needs five paragraphs.
For a wider read on what each tier of vendor actually charges, the previous post in this series, Church website cost: what to actually pay in 2026, walks through the four pricing tiers and what each one bundles in.