Website stewardship guide 10
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.
← All website stewardship guidanceAgree deliverables
Set up new access
Test the new setup
Switch carefully
Close old access
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
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.
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.
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.
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.
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
Illustrative sequence rather than a promised duration. Contract terms, platform limits, domain-transfer requirements, and testing needs determine the actual timetable.
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
Name the person at the business who can approve the move.
Request the deliverables list and ask about anything that cannot transfer.
Agree the test window, customer communication, and earliest safe cancellation date.
Confirm the business can access its critical accounts after the handoff.
Inventory dependencies, preserve backups and DNS records, and test the destination before cutover.
Coordinate final content or data synchronization, redirects, certificates, forms, monitoring, and rollback.
Document acceptance, remove outgoing access at the agreed time, and hand over the instructions needed to maintain the new setup.
Avoid these failures
Good website care lowers risk, but no provider can guarantee uninterrupted service.
Questions business owners ask
Often it does not. Identify whether the registrar, DNS, hosting, or maintenance responsibility is changing. Review any transfer requirements separately before altering the registration.
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.
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.
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
Plan the next step