Provider Rescue · Practical guide

How to leave a website provider without losing your website, domain, or customer path.

The safest exit starts before the cancellation email. First recover authorized control, preserve evidence, identify what the current provider actually supplies, and build a destination that has been tested without disturbing the live business.

This guide is for a legitimate business owner or authorized operator planning a responsible exit—not for bypassing account security or taking assets the business does not own.

Provider Rescue control map

Move the website without losing the business.

A responsible rescue maps control of the domain, DNS, hosting, source, forms, and analytics before anyone starts moving files or changing records.

Website dependency map connecting domain, DNS, hosting, source, forms, and analytics with example control states and a five-step safe move order.
Boho evidence plateIllustrative control map · Every real rescue begins with a current inventory

Decide what problem you are actually leaving.

Write the reason in one sentence: the provider is too expensive for the work delivered; access is withheld; the site is neglected; reports replace implementation; the cannot support the business; communication has failed; or the company simply wants a different operating model. The reason determines what must be recovered, repaired, rebuilt, or terminated.

Review the current contract, invoices, renewal dates, cancellation terms, ownership language, licenses, and outstanding obligations. Technical control and legal ownership are related but not identical. Do not let a new provider guess what the agreement says.

Collect the eleven things a website exit usually depends on.

1. Domain registrar

name, registrant, account owner, recovery email, renewal method, transfer lock, expiry date, and the authorized path for receiving an Auth-Code.

2. DNS configuration

Current name servers and a complete export or record of A, AAAA, CNAME, MX, TXT, CAA, and other records. may also control email and third-party verification.

3. Hosting or platform

Production account, billing owner, plan, platform, or project identifier, method, method, limits, and cancellation consequences.

4. Website administration

Authorized administrator access, user list, recovery path, plugins, themes, licenses, , scheduled jobs, and any provider-owned components that will not transfer.

5. Source and deployable copy

or source export, where applicable, configuration, build instructions, environment requirements, and a backup that another qualified operator can actually restore.

6. Content and media rights

Current page copy, images, video, brand files, fonts, downloads, product or service data, and confirmation that the business may reuse them.

7. URLs and redirects

A crawl or inventory of , high-value , downloads, URLs, , , and any old domains still sending visitors.

8. Forms and transactions

Every form, booking, quote, payment, checkout, application, newsletter, phone, and chat path—plus where submissions go and how failure is detected.

9. Analytics and search

, , tag management, business profiles, , , advertising accounts, configured events, and historical exports.

10. Email and integrations

Mail provider, MX records, SPF, DKIM, DMARC, CRM, payment provider, scheduling, maps, reviews, feeds, , , and recovery contacts.

11. Operating records

Contracts, invoices, renewal dates, support contacts, change history, incident notes, platform notices, and the approvals that establish authority to act.

Request exact transfers and use the official recovery path.

  1. Name the missing asset

    Ask for the transfer, administrator invitation, backup, content export, export, analytics access, or other specific item. 'Give me everything' is hard to verify and easy to misunderstand.

  2. Show authorized ownership

    Use the business records, payment history, registrant information, contracts, government business records, platform correspondence, and approved contacts the provider's recovery process requests.

  3. Make the request in writing

    State the requested action, destination account or authorized recipient, any relevant deadline, and a practical way to confirm completion. Keep the tone factual and preserve every response.

  4. Escalate through the platform

    If the business is the verified owner, use the registrar, host, , analytics, or platform provider's official recovery or ownership-transfer process. Do not attempt to work around .

  5. Preserve the live business

    Do not cancel hosting, remove billing, change nameservers, or revoke the current operator until the destination, backup, email dependencies, and rollback plan are understood.

  6. Separate technical help from a legal dispute

    A technical provider can inventory, recover through authorized processes, rebuild available assets, migrate, and verify. A disputed contract, ownership claim, or demand for damages belongs with qualified legal counsel.

Do not point the domain at a promise. Point it at a tested system.

Prepare the replacement away from production. Confirm responsive behavior, accessibility, content, images, , internal navigation, contact information, privacy and legal pages, , confirmations, analytics, integrations, and the ability to deploy or roll back. Test the real business actions, not only the homepage.

If the old provider owns a proprietary theme, plugin, builder license, hosted form, stock-photo license, or code component, decide whether to purchase a client-owned replacement, rebuild that function, or remove it. A screenshot of the old website is not a complete or automatically reusable website.

Map old URLs to useful destinations and verify the move in public.

  1. Inventory the current URLs

    Combine a site crawl with , analytics, Search Console, , and business-record evidence where available. Do not assume the visible navigation contains every useful URL.

  2. Keep stable URLs stable

    When a valuable page can retain its current path and purpose, changing it creates unnecessary migration work. A new design does not require a new URL for every page.

  3. Create one-to-one redirect decisions

    Send each removed or changed URL to the most relevant replacement. Use server-side permanent redirects for permanent moves and avoid or a blanket redirect to the homepage.

  4. Update the new site itself

    Update , canonicals, metadata, , hreflang where applicable, and the XML sitemap so the destination describes its own current URLs.

  5. Verify Search Console and submit the sitemap

    Make sure the authorized business retains access to the relevant Search Console properties, submit the current sitemap, and use the Change of Address tool when Google's documented conditions for a domain move apply.

  6. Monitor after launch

    Check important URLs, indexation signals, crawl errors, redirects, impressions, clicks, forms, analytics, logs, and customer reports. Keep redirects for at least a year when practical and longer when old links still matter.

Change the smallest responsible set of systems, then verify every critical path.

Record the final pre-launch configuration and backup. Confirm the person approving the change, the window, the trigger, the previous working state, and who is watching forms, email, analytics, errors, and customer-facing routes after the change.

Avoid changing the domain, DNS provider, platform, , every URL, all content, business email, analytics, and customer systems simultaneously unless there is no safer route. Google's migration guidance recommends changing one major thing at a time when possible because fewer simultaneous variables are easier to diagnose.

A rescue is complete when the business is less dependent than before.

Client-owned control

The business controls the agreed domain, production account, analytics, , source or deployable export, content, integrations, billing, and recovery contacts.

Current documentation

The handoff names providers, accounts, dependencies, renewals, backups, deployment process, form destinations, analytics setup, licenses, limitations, and recovery paths.

Verification record

The launch record states which routes, redirects, forms, inboxes, integrations, , devices, and ownership transfers were checked—and what remains unresolved.

A future exit path

The business knows what it can move, how to export it, which third-party costs continue, what support is separate, and what another qualified operator would need next time.

You do not need to diagnose all of this before asking for help.

Send the current website, the provider situation, and the access you know you have. Boho's free review identifies the visible risks and the missing facts. Paid Provider Rescue starts only after the smallest responsible scope is clear.

Primary references

Sources and further reading

These references support the platform, ownership, and migration guidance above. Your contract and account records control your specific situation.