What is the first thing to change when an account changes hands?

The contact and recovery details, verified through the provider's confirmation step. Password resets, MFA recovery and billing notices all route through them, so nothing else is secure until they point to the new owner. Only then reset the password, replace MFA devices and move on to users, keys and billing. Skipping this order leaves the previous holder a way back in.

Do I really need to rotate every key, even ones that seem unused?

Yes. A credential that was ever known to a previous holder cannot be considered secret, and unused keys are exactly the ones nobody notices being used later. Revoke every API token, replace SSH keys on each server and rotate application secrets. Doing it all in one scheduled window is faster than tracking down individual keys over months.

Does a handover have to follow the provider's terms?

Yes. Each provider sets rules for changing the registered account holder, and a transfer outside those rules can lead to suspension. Agree the change in writing, use the provider's own process for updating the holder and contact records, and keep the documentation. The general Cloud FAQ covers common questions about listed accounts and ownership.

Cloud account handover checklist

Cloud accounts change hands for ordinary reasons: a contractor finishes a build and hands the environment to the client, a company is acquired, a founder leaves, a project moves between departments. Each provider sets terms for how ownership changes are handled, and the handover should follow those terms. Within that boundary, the technical work is the same everywhere. This checklist covers it in order, with notes on OVHcloud and Atlantic.Net, whose accounts are listed on the marketplace.

Table of Contents

Before the handover

Agree in writing who the new owner is, what the account contains, and what the previous owner keeps access to (usually nothing). Confirm the provider’s process for changing the account holder; OVHcloud, for example, manages the account through a customer identifier and contact records that must be updated, and Atlantic.Net expects the account’s registered details to match the operator. Do not proceed if the transfer would breach the provider’s terms.

Written agreement naming the new owner and the effective date
Inventory of resources, credentials and recurring charges
Confirmation that the transfer follows the provider’s ownership rules
A scheduled window, because some steps briefly interrupt access

Step 1: contact and recovery details

Change the primary email, phone number and any recovery contacts to the new owner first. Everything else, including password resets and MFA recovery, flows through these. Verify each new contact by completing the provider’s confirmation step before moving on. The account recovery article explains why stale contacts are the most common cause of permanent lockouts.

Step 2: password and MFA

Set a new password known only to the new owner. Remove every existing MFA device and enroll the new owner’s device. Generate fresh backup codes and store them with the ownership records. If the provider supports it, review active sessions and sign out all of them.

Step 3: users, roles and API credentials

List every sub-user, role, API key, SSH key and access token on the account and on every resource in it. Remove what belongs to the previous owner. Rotate everything that remains, because a key that was ever known to someone else is no longer a secret. The key rotation guide walks through the order for keys that are wired into running systems.

Credential	Action	Where to check
Console sub-users	Remove or re-verify	Account user management
API keys and tokens	Revoke and reissue	Account API settings
SSH keys on servers	Replace in authorized keys	Each instance
Application secrets	Rotate	Config, secrets manager
IP allow lists	Update to new owner’s addresses	Firewalls, console restrictions

Step 4: billing

Replace the payment method with the new owner’s. Update the billing address and tax details. Check for any outstanding balance, pending invoice, or credit and record who it belongs to. Set a fresh budget alert routed to the new owner. If the account was part of an organization or reseller structure, confirm it has been detached.

Step 5: resource review

Walk through every resource: servers, volumes, snapshots, IP addresses, DNS zones, load balancers, object storage buckets. Confirm each one is expected and still needed, and delete what is not. Look specifically for scheduled tasks, cron jobs and webhooks that call out to the previous owner’s systems. The cleanup routine doubles as a handover audit.

Provider notes

OVHcloud’s control panel supports IP restrictions and user management, so the new owner should review both after taking control; the marketplace lists an OVH vCPU34 Account and an OVH Open 25 Port Account. Atlantic.Net’s panel covers servers, block storage, snapshots and private networking; the Atlantic Limit 8 Account listing carries a server cap, so confirm the resource count after cleanup fits within it.

Step 6: document and close out

Write a one-page record: account identifier, new owner, date, what was rotated, what was removed, where backup codes live. Store it with the organization’s other ownership records, not in the account itself. Then have the previous owner confirm in writing that they hold no remaining access.