A website handover checklist for Arizona business owners

Your website is live. You have a login and a folder of design files. That can still leave important parts of the business in somebody else's account.

A useful handover lets your business keep operating when a person, payment card, or service provider changes. It should explain who controls each part of the site and what to do when something stops working.

For an Arizona business, this is worth checking at launch, when changing developers, or before the person handling the website leaves. You do not need to become the webmaster. You need a clear way to get help and authorize the right person.

Map the accounts behind the website

Start with a list of services, not a collection of passwords. The company that registered your domain may be different from the company hosting your site or email.

Ask your developer to walk through the actual setup. Record the service name, sign-in address, responsible person, billing contact, and recovery route.

Keep passwords and recovery codes in an appropriate password manager or other secure storage. The handover document can point to that location without containing the secrets themselves.

Include connected services only if you use them: booking, payments, email delivery, forms, analytics, or a customer database. For each one, record what stops working if the account closes.

If your site runs under an agency's shared account, ask what access your business receives and how a future move would work. An agreed managed service can be perfectly reasonable. An unexplained dependency is harder to plan around.

Check domain access and renewal responsibility

Your domain is the address people use to reach you. Confirm which registrar handles it and which account can manage it.

Review the registration contact information, renewal date, payment method, and notices with the responsible person. Make sure your business can reach that person and receive the information it needs.

ICANN advises keeping domain contact and payment details current, tracking expiration dates, and understanding the registrar's renewal terms. Auto-renew still needs a working payment method. Read ICANN's renewal guidance.

If somebody else pays the registrar and invoices you, record that arrangement and the escalation contact. “Included in hosting” should have a named person behind it.

Ask who manages DNS, the records that direct your domain to website and email services. Do not change those records just to prove you have access. Have the current provider explain them and record the configuration before any planned move.

A handover does not automatically require moving the domain. Account access, billing responsibility, a registrar transfer, and a hosting move are separate decisions. Agree on the necessary changes before anyone cancels a service.

Test your own account and its permissions

Open a fresh browser session and sign in with your own account. A screen share where the developer is already logged in does not demonstrate your access.

Check the role you have, not just whether the dashboard opens. Can the authorized business administrator manage users and billing where needed? Can an editor perform everyday changes without broad administrative access?

Google Analytics makes the distinction explicit: an Administrator can manage users, while an Editor cannot. Roles can apply at the account or property level. Seeing reports alone is not proof that you can manage access. Google explains Analytics roles.

Use the roles appropriate to each person's job. Keep a documented administrative and recovery route under the agreed business arrangement. Check how access would be recovered if the usual administrator were unavailable.

Where a service offers multi-factor authentication, set it up with a recovery plan. Avoid making a departing staff member's personal phone the only way back into a business account. Do not disable a working security control to make the handover easier.

Our guide to everyday website edits covers what staff should be able to change. This check is broader: who can maintain the accounts that make those edits possible?

Ask for recovery evidence, not just an export

A folder called “website backup” does not tell you what it contains or whether anyone has restored it successfully.

For WordPress, the built-in export creates a file of site content such as posts, pages, comments, and categories. It is useful for moving that content. WordPress documents the export format.

A typical WordPress restore needs both the database and the site files. Treat a content export as different from that full backup. The WordPress backup guide explains the two parts.

For a hosted website builder, ask what its backup and export features actually cover. For a custom site, ask where the source code, deployment instructions, and required service configuration are kept. The answer will depend on your setup.

Have the person responsible demonstrate recovery in a separate test environment where practical. Never overwrite the live site simply to prove a backup exists. Prevent the test copy from sending real customer emails or processing payments.

Record the backup date, what was restored, what was checked, and what remains outside that recovery process. Decide how much recent work your business could afford to re-enter if the latest backup were used.

Write down what continues after launch

List recurring charges and who receives each renewal notice. Include hosting, domain registration, paid themes or plugins, booking tools, and any other service the site depends on.

Ask which licenses belong to your business and which are supplied through the developer's plan. If support ends, does the site keep working, lose updates, or require a replacement subscription? Get a specific answer for each dependency rather than one promise covering everything.

Record the support contact, coverage hours, and route for urgent problems. Distinguish an outage from a routine content request. Only rely on a response promise that is actually part of your agreement.

Our website maintenance service explains ongoing care separately from a new build. Your own handover should make that separation clear too: what is included now, what is recurring, and what needs a new quote.

Keep the agreed deliverables and usage terms with the project records. Account access alone does not explain every right attached to code, photography, or licensed software.

Finish with a short handover rehearsal

Set aside time with the person delivering the site. Work through the list from your side of the screen.

• Sign in to the relevant business accounts and confirm your role.
• Find the domain renewal date and the person responsible for payment.
• Locate the support contact and recovery instructions.
• Preview a small content edit, using a test page where possible.
• Review the latest recovery test and any unresolved dependencies.
• Confirm which provider access remains necessary for ongoing support.

Write down missing items with an owner and a due date. A temporary access gap is easier to resolve when everyone knows what is outstanding.

Remove obsolete access only after the replacement arrangement works. If a connection uses the old provider's account, migrate that dependency first. Avoid turning a tidy-up into an outage.

If your website is being rebuilt, make this list part of the project brief before launch. If it is already live, start with the domain and the most important account you cannot currently reach.

For Arizona web design, a good finish includes more than a working homepage. Talk to Brandon about a website handover your business can actually use.