# Safe Website Provider Handoffs for Domains and Platforms > Plan a website provider handoff with clear deliverables, tests of the new setup, a switchover sequence, and deliberate account closeout. Canonical: https://vassalmarketing.com/information/website-stewardship/safe-website-provider-handoffs/ **Maintained by Vassal Marketing** ยท Last updated on September 26, 2026 Reviewed at least quarterly and whenever a platform or rule it cites changes. General information, not legal or professional advice. Check rules that affect your business with a qualified professional. Changing website providers is easier when the incoming team knows what they are receiving and the outgoing team knows what remains to be done. Agree the accounts, files, responsibilities, tests, and timing before cancelling the working service. ## Why this matters The website may depend on accounts and services that do not appear in the page editor. DNS records can route business email. A form may send to an inbox owned by the old provider. A design feature may rely on a license that cannot transfer. These connections need to be identified before the move. A handoff is the actual transition project. Exit planning is the preparation you keep in place before a move is needed. During the handoff, work from a shared deliverables list, test the destination, and agree when it is safe to close old access and billing. ## Responsible practices ### Agree what is changing Name the business decision-maker and both providers' contacts. Specify whether the job changes hosting, the website platform, the domain, email, or only who maintains the site. These are separate changes. Moving hosting often does not require a registrar transfer, and unrelated changes should be separated where practical. ### List what the next provider needs The handoff manifest is the checklist of accounts, files, configuration, and instructions being transferred. Include current content, media rights, supported exports, redirects, forms, analytics, licenses, billing, and known problems. Record who supplies each item and how the incoming team will confirm it is usable. ### Set up the destination before switching Keep the business in control of new accounts and invite providers through named roles. The technical team should build and test the destination with realistic content and integrations. Preserve the current site and an appropriate recovery copy. Agree a rollback trigger: the condition that means the team should return to the working version. ### Schedule a controlled cutover Cutover is the moment traffic or responsibility switches to the new setup. Agree who authorizes it, who makes the change, and who watches the result. A short change freeze prevents staff editing different copies during the final transfer. Preserve email-related DNS records and communicate any temporary customer impact. ### Accept the result, then close old access Check important pages, old links, forms through delivery, booking, email dependencies, and business access. Assign unresolved items before declaring the move finished. After acceptance and the agreed rollback window, remove outgoing users, keys, tokens, and obsolete services. Confirm that necessary billing and renewals now reach the right people. ## Worked example: A handoff timeline with clear decision points Illustrative sequence rather than a promised duration. Contract terms, platform limits, domain-transfer requirements, and testing needs determine the actual timetable. ### Before scheduling Confirm account control, deliverables, export limits, open work, and who can approve changes. Keep the existing service active. ### Before cutover Test the new destination and preserve the working source. Agree the final synchronization point, change freeze, rollback trigger, and monitoring contact. ### At cutover The authorized operator makes the scoped changes. Both teams know how to report a failure and who can decide to roll back. ### Before cancellation The business accepts the tested result. Resolve or assign exceptions, retain the agreed recovery window, then close only the old services and access that are no longer needed. A folder of files is one deliverable. The handoff is complete when the next team can run the agreed services and the business retains control. ## Handoff runbook checklist ### What you can check 1. Name the person at the business who can approve the move. 2. Request the deliverables list and ask about anything that cannot transfer. 3. Agree the test window, customer communication, and earliest safe cancellation date. 4. Confirm the business can access its critical accounts after the handoff. ### What to ask your provider to handle 1. Inventory dependencies, preserve backups and DNS records, and test the destination before cutover. 2. Coordinate final content or data synchronization, redirects, certificates, forms, monitoring, and rollback. 3. Document acceptance, remove outgoing access at the agreed time, and hand over the instructions needed to maintain the new setup. ## Avoid these failures - Cancelling the source before the destination, exports, and recovery path have been checked. - Sharing personal passwords instead of arranging authorized business-controlled access. - Moving email, domain, hosting, design, and tracking together without a clear reason and test plan. - Leaving former provider users or tokens active after the agreed closeout. Good website care lowers risk, but no provider can guarantee uninterrupted service. ## Questions business owners ask ### Does a provider change require a domain transfer? Often it does not. Identify whether the registrar, DNS, hosting, or maintenance responsibility is changing. Review any transfer requirements separately before altering the registration. ### What should the new provider receive? The agreed accounts, current content and supported exports, configuration, redirects, integration details, licenses, recovery instructions, and known issues. Each item should have a delivery owner and a way to confirm it works. ### When should the old provider lose access? Use limited transition access and remove it at the agreed point after acceptance and any necessary recovery window. Risky or compromised access may need earlier action. Review users, keys, tokens, billing roles, and recovery contacts together. ### What happens if the new site fails a check? Use the agreed rollback or repair decision. The plan should name who can authorize it, what working version remains available, and how staff and customers are informed when needed. ## Primary guidance - [ICANN: FAQs for registrants transferring a domain name](https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en) - [Google Search Central: How to move a site](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) - [NIST SP 800-146: Cloud Computing Synopsis and Recommendations](https://www.nist.gov/publications/cloud-computing-synopsis-and-recommendations) - [CISA: Use strong, unique passwords and a password manager](https://www.cisa.gov/secure-our-world/use-strong-passwords) ## Connected guidance - [Domain, hosting, and account ownership](https://vassalmarketing.com/information/website-stewardship/domain-hosting-account-ownership.md): Find the accounts behind your site and confirm who can access or recover them. - [SEO migrations](https://vassalmarketing.com/information/seo-migrations.md): Plan redirects, launch checks, and monitoring when the site or its URLs move. - [Website backups and restoration](https://vassalmarketing.com/information/website-stewardship/website-backups-and-restoration.md): Check what your backups include and practice restoring a working site. - [Agency offboarding checklist](https://vassalmarketing.com/information/resources/agency-offboarding-checklist.md): Step through access, exports, and billing when you leave a marketing or web provider. - [Marketing account ownership inventory](https://vassalmarketing.com/information/resources/marketing-account-ownership-inventory.md): List every marketing account your business uses and who controls it.