A hosting handover your agency and client can both understand

A hosting handover is not a folder of control-panel screenshots. It is a controlled transfer of knowledge, authority and operational responsibility.

The incoming owner should be able to answer:

• What exists?
• Who owns each decision?
• How is authorised access recovered?
• Which suppliers and dependencies matter?
• What work is routine?
• How would we detect, investigate and recover from a problem?
• Which risks or incomplete actions are being accepted?

If the handover only works while the outgoing specialist is on a call, the service has not really been handed over.

Keep two records separate

Create a handover pack for operational knowledge and an approved credential system for secrets.

The handover pack may identify only the account references, roles, owners, recovery contacts and controlled-credential location that authorised substitutes need. It should not contain passwords, private keys, API tokens, recovery codes, copied access links or unnecessary personal data. Keep the pack access-controlled too; separating it from secrets does not make its account map public.

This separation matters because the pack needs to be discoverable by authorised substitutes, while secrets need stronger access controls, rotation and audit. Copying every credential into an ordinary document makes the handover easier to leak and harder to revoke.

1. Service summary and business purpose

Start with a plain-language page:

• service name, public hostname and sanitised canonical paths, without query tokens or unnecessary personal data;
• client and agency owners;
• what the service does for users;
• critical customer journeys;
• normal operating hours, if relevant;
• current lifecycle state;
• known service commitments and their source;
• a diagram or short dependency list.

Describe the business function before the infrastructure. Recovery priorities should follow what the organisation needs to deliver, not whichever server is easiest to restore. Current NCSC guidance recommends identifying critical services, their supporting systems and feasible workarounds so restoration can be sequenced deliberately.

2. Responsibility and decision authority

Use one row per recurring or consequential task. The allocations below are examples to replace with the applicable agreements and named people, not a Novasean service schedule:

Include alternates and thresholds for escalation. “Ask Alex” is not a durable operating model. The NCSC's October 2026 guidance says critical response roles should never rely on one person and that delegated decision authority should still work when senior leaders are unavailable.

3. Ownership and access routes

Record the authoritative owner and access-recovery route for:

• domain registration;
• DNS;
• hosting and cloud accounts;
• source-code repositories;
• deployment service;
• content-management system;
• database administration;
• backup service;
• monitoring and status tools;
• transactional email and other integrations;
• billing and renewal accounts.

For each, note the role, authorised account owner, authentication method, recovery contact, break-glass procedure if one exists and where credentials are controlled. Do not record the secret itself.

Test whether the documented recovery route depends on the same failed system, without exposing or copying recovery secrets into the pack. The NCSC advises keeping access to provider recovery contacts independent of corporate email or identity systems that could be unavailable during an incident.

4. Technical inventory and dependencies

Document enough structure to rebuild or transfer the service:

• hosting region and provider account reference;
• virtual machine, platform or plan identifiers;
• operating system and supported lifecycle;
• web server, runtime and database versions;
• required extensions and packages;
• storage locations and growth constraints;
• certificates and renewal method;
• scheduled jobs and background workers;
• external APIs, identity, payment, mail and analytics services;
• inbound and outbound network dependencies;
• configuration source and deployment sequence.

Keep network and asset information securely available outside production. Current NCSC technical-recovery guidance specifically recommends separate, protected storage for asset records, accurate inventories, dependency documentation and restart sequencing.

5. Routine operation

List work by frequency and trigger:

• security and lifecycle review;
• operating-system and runtime updates;
• application and dependency updates;
• backup checks;
• restore exercises;
• certificate review;
• access review;
• capacity review;
• licence and domain renewal;
• monitoring and alert review;
• client reporting.

Name the owner, expected evidence and next due date. A calendar entry without an accountable owner is a reminder, not an operating control.

6. Monitoring and incident response

For every material alert, record:

• the signal and threshold;
• where the alert is delivered;
• primary and substitute recipient;
• expected first action;
• escalation path;
• provider contact and contract reference;
• client communication owner;
• location of the incident log and runbooks.

Include an out-of-band contact route. An incident affecting email, identity or the main hosting account should not also remove the only way to coordinate the response.

7. Backup and recovery evidence

Do not stop at “daily backups”. Record:

• what is copied and excluded;
• copy frequency and retention;
• storage and administrative separation;
• encryption and key dependencies;
• restore authority and request process;
• available restore targets;
• latest representative restore test;
• data and application validation;
• remaining recovery limitations.

An incoming owner needs to know what was actually tested, on which date and with what result. Do not turn a successful component restore into an unsupported promise about complete future recovery.

8. Change, release and rollback

Explain how a change moves from request to acceptance:

1. who requests and approves it;
2. where it is tested;
3. which dependencies are checked;
4. how the change is deployed;
5. what proves success;
6. when and how rollback is used;
7. who tells the client.

Include current branches, pending migrations and temporary workarounds. A new operator should not mistake an exceptional state for the intended baseline.

9. Supplier and commercial facts

Record the applicable agreement, service schedule, support route, billing owner, renewal date, notice period and exit process for each material supplier. Mark missing or disputed documents as open risks.

Do not infer support coverage from a logo or product label. Distinguish ticket submission, staffed response, restoration work and contractual commitments.

10. Open risks and acceptance

End with a visible list of:

• known defects;
• unsupported versions;
• capacity constraints;
• untested recovery steps;
• access gaps;
• missing documents;
• temporary exceptions;
• decisions still required;
• named owner and target review date.

The outgoing and incoming owners should agree what has transferred and what has not. The client should understand business-impacting limits without needing to interpret internal infrastructure jargon.

Test the handover with a substitute

Give an authorised substitute a bounded, read-only task without coaching from the usual operator. For example:

Locate the provider contract and support route, identify who can approve a DNS change, find the latest recorded restore evidence or mark it missing, and explain who would validate a critical application journey after recovery.

The substitute should use only their authorised access, should not retrieve secrets into the pack, and should not make a production change or perform a restore for this drill. Record whether each item was found, missing or inaccessible, and where the substitute got stuck. Fix the pack, access route or ownership—not the test result. Then review it after people, suppliers, versions or architecture change.

How this relates to Novasean

Novasean's current responsibility page lists the Managed OS catalogue boundary: scheduled operating-system updates, monitoring set-up, up to one hour of OS administration per month and server backups whose schedule, retention and recovery arrangements are agreed during onboarding. Application code, content, changes and functional checks remain with the customer's team unless separately agreed. Its customer-control page says a future usable export would require agreed files, database exports, configuration, versions, dependencies, licences and restore instructions, followed by a separate compatible restore and agency validation.

Those are public scope and pre-service expectations, not evidence that a particular customer handover or restore has succeeded. The separate agency portfolio enquiry is non-binding, and new VPS orders remain paused. The live pages do not promise free or immediate migration, a round-the-clock response or a recovery objective. Use the agreement and evidence that apply to the real service; this article does not create a handover entitlement.

Sources

• NCSC: prepare your business continuity — current official guidance on service priorities, dependencies, suppliers and exercises.
• NCSC: prepare your people — current official guidance on roles, alternates, decision authority and offline contacts.
• NCSC: prepare your technical recovery capability — current official guidance on asset information, backups, restoration and dependencies.
• NCSC: using SaaS securely — official guidance on provider contacts, access recovery and avoiding dependencies on unavailable systems.
• Novasean: responsibilities, customer control and Managed VPS — live scope and order-pause wording inspected on 2 October 2026.

Next: Review customer control and portability questions.