A local business website is portable when the business can move its public identity, content, media, data, and essential customer workflows to a suitable replacement without losing control or relying on the former vendor's live account. Ownership is not a single checkbox. The domain, hosting contract, source or theme, content, forms, bookings, analytics, email, integrations, credentials, and backups can each have a different owner.
Build an ownership map before comparing platforms
List the domain registrant and registrar, DNS account, hosting account, content-management administrator, source repository, design files, photos and licenses, analytics, search tools, maps listing, form inbox, booking or commerce service, payment account, email sender, customer records, plugins, APIs, and backup location. For each, record the legal owner, administrator, recovery contact, export route, renewal date, cost, and replacement path.
Red flags include a developer registered as the domain holder, one personal administrator, a vendor-controlled analytics property, unlicensed stock media, forms delivered only to a vendor mailbox, or backups stored only inside the same hosting account. Ask for evidence rather than relying on “you own your site” language.
Verify domain control separately
ICANN's Auth-Code guidance explains that an authorization code helps identify the registered holder and is required to transfer a generic top-level domain between registrars. Confirm the business is the registrant where the applicable record permits, controls the account and recovery route, can unlock the domain, and can obtain the transfer code.
Do not publish the code or store it in an ordinary project document. Record only that a controlled verification succeeded. Also verify renewal, privacy service, DNS export, nameservers, DNSSEC status, mail records, and any transfer lock. Moving a website without preserving mail and verification records can disrupt more than the public pages.
Test content export and import
WordPress's Tools Export documentation describes a WXR XML export for posts, pages, comments, custom fields, terms, menus, and custom post types. That is useful evidence, but it is content-focused. It does not by itself prove that themes, plugins, media binaries, user accounts, forms, redirects, or external integrations are independently preserved.
WordPress's Tools Import documentation documents importing posts, comments, custom fields, pages, and categories from a WordPress export. Perform an authorized test import or neutral parse. Compare counts, slugs, dates, authors, taxonomies, links, formatting, metadata, menus, and a media sample. Platform claims should be tested on the intended plan and actual content types.
Inspect code, design, media, and licenses
Determine whether the option provides source code, templates, style tokens, scripts, build instructions, configuration, redirects, schemas, and dependency versions, or only rendered pages. For a managed builder, identify proprietary components that cannot be exported. For custom code, confirm repository ownership, licenses, documentation, and a reproducible build.
Create a media manifest with original filename, current URL, file hash, caption, alternative text, license, creator, and permitted uses. Check fonts, icons, photography, videos, reviews, and customer-provided material. A technical copy without reuse rights is not a portable asset library.
Follow customer workflows and data
Map every form, booking, newsletter signup, checkout, chat, map, review, and call-tracking route. Identify where submissions are stored, who can export them, what format is available, how consent and suppression records travel, and what must remain in a regulated provider. Use invented submissions to verify receipt, export, deletion, and destination behavior.
NIST SP 800-146, Cloud Computing Synopsis and Recommendations, notes that SaaS formats and provider-specific workflows, settings, scripts, extensions, and add-ons can impede transfer. A site export is incomplete if its appointment flow, redirects, structured data, consent, or lead routing cannot be reconstructed.
Compare backup and recovery evidence
Ask whether backups include database, media, code, configuration, DNS, certificates, redirects, and integration definitions. Record frequency, retention, encryption, off-account copy, restore access, and cost. A provider's disaster recovery is not necessarily a customer-controlled backup.
Run a restore to an isolated destination using non-production secrets and safe data. Check key pages, mobile layout, accessibility, forms, redirects, metadata, analytics isolation, and private-route protection. Measure elapsed time and manual repair. Do not point the live domain or send customer messages during a portability test.
Score contract and operational control
Compare minimum term, renewal, cancellation, export assistance, professional-service fees, storage and bandwidth, API limits, collaborator access, audit history, security updates, incident response, end-of-service retention, and deletion commitments. Include the labor required to maintain the system, not just the subscription price.
Use separate scores for domain control, content completeness, code and design portability, media rights, customer-data export, workflow replacement, credentials, backup restore, contract exit, and documentation. Preserve unknowns. The strongest conclusion names the exact plan and evidence: the business controls these accounts and assets, this test migration recreated these functions, and these components remain proprietary or unverified. That supports a real decision without pretending every website option is equally movable.
Sources
- Tools Export screen — WordPress.org
- Tools Import screen — WordPress.org
- About Auth-Code — ICANN
- NIST SP 800-146: Cloud Computing Synopsis and Recommendations — National Institute of Standards and Technology