Exit-ready hosting: what to keep under your control before you sign

The best time to plan your exit is before you buy the service.

That does not mean treating every supplier as temporary. It means making sure a future change of provider, agency or employee is a controlled project rather than an emergency negotiation. A good service can be long-lived and still be exit-ready.

Exit readiness is not the same as downloading a backup. A usable transfer may also depend on the domain, DNS, certificates, source code, configuration, software licences, supplier contacts, billing authority and people who can approve changes. If one of those is trapped in an inaccessible account, the data export alone may not be enough.

Use the following checklist while comparing offers and before signing the applicable agreement.

1. Name the service assets and their controller

Start with a small register. For each asset, record its business owner, account owner, technical operator, approver and recovery contact.

Include at least:

• domain registrations;
• authoritative DNS zones;
• hosting, cloud and control-panel accounts;
• application and database content;
• source-code repositories and deployment pipelines;
• certificates and renewal methods;
• email delivery, identity, payment and analytics services;
• backup locations and encryption-key dependencies;
• monitoring and incident tools;
• licences, subscriptions and billing records.

These roles may belong to different organisations. The end client might be the domain registrant, the agency might operate DNS, and the hosting supplier might provide the platform. That can work well when the authority and recovery route are explicit.

2. Keep domain authority identifiable

ICANN describes a registrant as the person or entity that registers a domain name and enters into a contract with the registrar. Registrants manage domain settings through that registrar. This makes the registrar account and the registered-holder record materially different from day-to-day website administration.

Before signing, verify:

• which legal entity or person will be the registered holder;
• who owns the registrar account;
• which shared or role-based address receives renewal and transfer notices;
• who can recover the account if the usual operator is unavailable;
• who approves a transfer or registrant change;
• whether account security and renewal controls meet your needs.

Do not settle for “the agency looks after it”. Name the authority, operator and substitute. A hosting supplier can operate DNS without becoming the organisation that must own the domain.

3. Define a usable export, not just an export button

Ask what can be exported, in which format, by whom and under what conditions. For a typical website, a useful exit set may include:

• application files and user-generated media;
• a consistent database export;
• configuration and environment requirements;
• runtime, database and extension versions;
• scheduled jobs and background-worker definitions;
• redirects and web-server rules;
• DNS records and certificate requirements;
• dependency and licence information;
• backup and restore instructions;
• logs or audit evidence needed for the transition.

An export is only useful if the receiving team can interpret it. Ask whether it is a native backup, a provider-specific snapshot, a standard archive or a documented combination. Provider-specific formats may still be valuable, but they should not be mistaken for a guaranteed restore path elsewhere.

4. Know where configuration truth lives

A working service contains more than code and content. Record which settings live in version control, the hosting control panel, environment variables, the database, a secret manager or a supplier portal.

The exit plan should identify how the receiving team reconstructs those settings without copying secrets into an ordinary document. Reference the authorised secret location and recovery route; do not place passwords, tokens, private keys or recovery codes in the exit checklist itself.

Ask who can export or recreate:

• environment variables and non-secret settings;
• network and firewall rules;
• scheduled tasks;
• storage mounts and permissions;
• monitoring thresholds and destinations;
• deployment and build settings;
• service identities and integration registrations.

5. Separate licences from installed software

Installed software does not prove the customer can continue using it elsewhere. Themes, plugins, fonts, security tools, backup services and commercial libraries may be licensed to the supplier, agency, client or an individual employee.

For every material licence, record:

• the licence holder;
• the covered sites or environments;
• renewal and billing owner;
• transfer or re-purchase conditions;
• where entitlement evidence is held;
• what happens when the supplier relationship ends.

Do not assume a licence key may be copied to the new environment. Confirm the applicable terms and budget for replacements where transfer is unavailable.

6. Make access transferable without making it loose

Customer control does not require every party to hold permanent administrator rights. It requires an authorised route to obtain the access needed for normal operation, incident response and exit.

Define:

• named or role-based administrator accounts;
• multi-factor authentication and recovery methods;
• which actions require approval;
• how emergency access is granted and recorded;
• how a substitute is authorised;
• how supplier access is logged, reviewed and removed;
• how access will be rotated or revoked after exit.

The NCSC advises organisations to understand whether suppliers or subcontractors can access their data or systems, how that access is limited and monitored, and whether remote sessions are logged. Its cloud guidance also treats provider administration as highly privileged and recommends strong controls and detailed audit information.

7. Put exit obligations in the agreement

A friendly conversation is not an exit provision. The relevant contract or service schedule should answer:

• what the supplier returns or makes available;
• the format and delivery method;
• request and authorisation steps;
• applicable notice periods and charges;
• reasonable timescales;
• assistance that is included or separately scoped;
• how long the old service and data remain available;
• when residual data is deleted and how that is evidenced;
• how disputes, unpaid invoices or expired services affect access;
• which obligations flow down to subcontractors.

The NCSC's supplier-assurance questions explicitly recommend considering contract-exit provisions for secure deletion or return of data and assets, including transfer to another supplier. The exact answer still comes from the agreement you accept, not from a generic checklist.

For a prospective Novasean service, do not infer an accepted exit fee, included assistance, notice period, export window or deletion timetable from this article. Ask for the actual applicable terms before commitment. Existing customers may have different current rights; this checklist does not amend them.

8. Test the route while the service is healthy

Do not wait for termination to discover that the only export owner has left. Use a proportionate readiness exercise:

1. identify the person authorised to request an export;
2. produce a representative export without exposing secrets;
3. inspect its contents and format;
4. locate version, dependency and licence information;
5. restore it into a compatible separate environment where justified;
6. perform functional and data checks;
7. record gaps, effort and supplier dependencies;
8. review the result after material changes.

This is evidence about the tested scope on a particular date. It is not proof that every future migration will be quick, free or successful.

A compact pre-signing decision test

Before approval, ask five questions:

1. Authority: Can we name who controls the domain, DNS, service account and exit decision?
2. Portability: Can we obtain the data, files, configuration and dependency information in usable forms?
3. Continuity: Can an authorised substitute recover the necessary accounts and records?
4. Terms: Do the agreement, charges, timescales and deletion obligations match our risk?
5. Evidence: Have we tested a representative export or clearly recorded that this remains untested?

If an answer is unclear, record it as a buying condition or accepted risk. Do not allow “we can probably sort it out later” to become the operating model.

How this relates to Novasean

Novasean's current customer-control page describes a proposed model in which the agency or end customer names the domain controller and keeps the route for DNS changes and transfer; domain registration and customer DNS administration are outside the proposed hosting scope. That boundary concerns the hosting proposal: Novasean separately offers new domain registrations across hundreds of extensions; availability and final charges must be checked in the client portal, and incoming transfers are not offered. The page says the parties should agree a useful export set—files, database exports, configuration inventory, versions, dependencies, licences and restore instructions—before a hosting service. A substitute would need a compatible separate environment and the agency would validate application behaviour.

Those statements are proposed information-stage expectations. The page expressly says no such restore has been established and that timing, assistance, charges and retention must be agreed before commitment. They do not prove that a particular export works, make migration easy, promise free or immediate transfer, or replace an accepted service agreement. Use them as questions to verify against the exact service and evidence offered.

Sources

• ICANN: information for domain name registrants — current official explanation of the registrant, registrar relationship and management rights.
• NCSC: supplier assurance questions — official prompts on supplier access, contracts, secure return or deletion and transfer at exit.
• NCSC: secure service administration — official guidance on privileged provider administration and auditability.
• Novasean: customer control — live proposed control and portability boundaries rechecked against release 54a1fb754da38574 on 15 October 2026.

Next: Review Novasean's proposed customer-control model.