Ownership is an operational question
A website may work perfectly while every important account belongs to a supplier. The difficulty appears later: renewing the domain, changing a payment integration, recovering a backup or moving support to another team. Ownership should be part of the delivery plan rather than an argument at the end of a contract.
Client-controlled hosting is a useful default for custom production systems, not a universal requirement. A managed service can also be appropriate. What matters is an explicit account owner, documented responsibilities and an exit path that matches the commercial agreement.
Make an account map
List the services required to keep the agreed system running. For each one, record its owner, billing responsibility, administrative access and recovery method. Keep the actual credentials in an appropriate secure store, not in the public handover document.
- Domain registrar and DNS.
- Hosting or cloud account and deployment process.
- CRM, messaging providers and API connections.
- Payment, business email and analytics accounts where used.
- Source repository, content administration and backup storage.
Use access that can be handed over
Give each operator the access required for their role. Separate customer-facing accounts from administrative access, and identify the credentials that must be rotated when support changes. Avoid a design where the departure of one person makes recovery impossible.
A handover should explain where configuration lives and how changes reach production. It should not require copying secrets into a spreadsheet or giving every collaborator the same unrestricted login.
A backup needs a recovery route
Ask what is backed up, where it is stored, how long it is retained and which person can restore it. Source code, uploaded content, database records and external service configuration may need different recovery steps.
For an online store, a code rollback should not replace live order data with an old snapshot. For a lead workflow, a restart should not erase accepted enquiries. Write down the boundary between software releases and the business data they use, then test the agreed restore scenario in a suitable environment.
Define support in terms of the running system
Name the workflow or application covered by support, the alert destination and who decides what happens after an incident. Distinguish maintenance from new development. A new CRM, channel or business rule can change the scope even when it looks like a small screen change.
Sleepy Shop is our own example of a website with catalogue content and a shopping journey. Its case shows the product we built. The general lesson is to plan the operational system behind the page, including content administration and the services that make checkout work.
Ask for a practical handover package
A useful package contains the account map, deployment instructions, data locations, backup and recovery steps, external dependencies, known limitations and support contacts. It should be understandable to another qualified operator.
Review the package before launch with the person who will own the system. If the business is not ready to operate infrastructure, choose an explicit managed arrangement rather than assuming that an account in the client’s name removes all support work.
A checklist for your team
- Is the account owner clear for every essential service?
- Can access be revoked without losing the business account?
- Are software rollback and data recovery separate?
- Has a restore scenario been agreed and tested?
- Could another qualified operator follow the handover?