Close an unused cloud account without losing apps, files, or databases

TL;DR — Before you close a cloud account, first list everything in it, export the data, move any still-used services to another provider or account, and update DNS (the internet's address book) to point at the new location. The most common reason people lose data is deleting storage volumes, databases, or backups before verifying that exports and restores actually work. Reading time: ~5 min

Goal

When you finish, the old cloud account is closed or ready to close, your important data exists in a new location you can access, and any live website, app, database, or DNS record that depended on the old account works from its new home.

Prerequisites

• Login to the cloud provider account you want to close
• Billing or owner-level access in that account
• Login to your DNS provider if any domain names point to resources in the old account
• A destination location for data: another cloud account, local computer, or company backup system
• Enough free disk space to download backups
• A spreadsheet or note with these items:
  • account ID or account email
  • list of domains used by this account
  • list of apps, virtual machines, databases, object storage buckets, snapshots, and backups
  • contact email for billing receipts and closure confirmations
• Optional CLI (command line tool) only if your provider supports it and you prefer it; dashboard steps come first

Steps

Step 1: Inventory everything that still exists in the account

In your provider's dashboard, open each service area and record what exists. Use this checklist in order:

• Dashboard → Compute / Virtual Machines
• Dashboard → Databases / Managed Databases
• Dashboard → Storage / Buckets / Object Storage
• Dashboard → Block Storage / Volumes / Disks
• Dashboard → Snapshots / Images / Backups
• Dashboard → Networking → Load Balancers / Public IPs / Firewalls
• Dashboard → DNS / Domains
• Dashboard → Identity / Users / API Keys / Service Accounts
• Dashboard → Billing → Active subscriptions / Reserved resources

Copy this table into your notes and fill one row per item:

What you should see: a complete list of resources with no blank "I don't know what this is" items left.

Step 2: Find anything public that still points at the old account

Check whether your domains still resolve to the old provider's IP addresses or hostnames.

If your DNS is managed in a dashboard, open your DNS provider and review these records:

• DNS → Records → A
• DNS → Records → AAAA
• DNS → Records → CNAME
• DNS → Records → MX
• DNS → Records → TXT

If you want a command-line check, run:

nslookup example.com
nslookup www.example.com
nslookup -type=mx example.com

Replace example.com with your real domain.

What you should see: either records already point somewhere else, or you have a clear list of records that still point to the old account.

⚠️ Do not delete any server, database, disk, bucket, or snapshot yet. Deleting compute often also deletes attached storage, and many providers permanently remove final backups when an account is closed.

Step 3: Export data before you move or delete anything

Use the provider dashboard export or download action for each resource type.

Use these dashboard paths where available:

• Databases → your database → Backups / Export → Create export
• Storage / Buckets → your bucket → Download or Transfer
• Volumes / Disks → Snapshots → Create snapshot
• Virtual Machines → your VM → Snapshots / Images → Create image

If you have direct database access, these copy-paste commands are common:

PostgreSQL:

pg_dump -Fc -h DB_HOST -U DB_USER -d DB_NAME -f db-backup.dump

MySQL:

mysqldump -h DB_HOST -u DB_USER -p --single-transaction DB_NAME > db-backup.sql

For object storage already mounted or synced locally, use:

rclone copy REMOTE:bucket-name ./bucket-backup --progress

What you should see: backup files exist in the destination location, with recent timestamps and non-zero file sizes.

Step 4: Restore or copy the data to its new home

Create the replacement resources in the new account or provider, then import the backups.

Typical dashboard paths:

• New provider dashboard → Databases → Create database
• New provider dashboard → Storage → Create bucket
• New provider dashboard → Compute → Create VM
• New provider dashboard → Backups / Import → Upload backup

Typical restore commands:

PostgreSQL:

pg_restore -h NEW_DB_HOST -U NEW_DB_USER -d NEW_DB_NAME --clean --if-exists db-backup.dump

MySQL:

mysql -h NEW_DB_HOST -u NEW_DB_USER -p NEW_DB_NAME < db-backup.sql

What you should see: the new resource exists and the import finishes without errors.

Step 5: Point domains and apps to the new location

Update DNS and any app settings that still reference the old account.

In your DNS provider's dashboard, edit the exact records that point to the old account:

• DNS → Records → edit A record for example.com → set value to NEW_PUBLIC_IP
• DNS → Records → edit CNAME record for www → set value to new-app.example.net
• DNS → Records → lower TTL (cache time) to 300 seconds before the change if your provider allows it

If your app connects to a database, update its connection string in the app settings panel. Replace the old host with the new one.

[User Browser] ---- 1. DNS lookup ----> [DNS Provider]
[DNS Provider] ---- 2. new IP/host ----> [User Browser]
[User Browser] ---- 3. HTTPS request ----> [New App]
[New App] ---- 4. DB connection ----> [New Database]

What you should see: DNS records save successfully, and the app settings show the new hostnames or IPs.

Step 6: Verify the new location works before closing the old account

Test the public site, app login, file access, and database-backed features from the new location.

Use these checks:

nslookup example.com
curl -I https://example.com

If you have a web app, also perform one real user action in the browser, such as signing in or loading a page that reads from the database.

What you should see: DNS resolves to the new destination, curl returns HTTP/2 200 or HTTP/1.1 200 OK, and the app behaves normally.

Step 7: Remove secrets, users, and billing ties from the old account

Once the new location is confirmed, clean up access in the old account.

Use these dashboard paths:

• Identity / Users → remove extra users
• API Keys / Access Tokens → revoke all keys
• Billing → remove saved payment methods if your provider allows it before closure
• Support / Account Settings / Security → enable final confirmation email if available

What you should see: no active API keys remain, and only the owner account is left for final closure.

Step 8: Close the account

In your provider dashboard, use the account closure flow. The exact label varies, but it is usually one of these:

• Account Settings → Close account
• Billing → Cancel subscription / Close account
• Organization Settings → Delete organization

If the provider blocks closure, return to the inventory and remove remaining billable resources first.

What you should see: a confirmation screen or email stating the account is scheduled for closure or has been closed.

Verify it works

Run these checks after closure or after the closure is scheduled:

nslookup example.com
curl -I https://example.com

Expected results:

• nslookup shows the new IP address or hostname, not the old provider's one
• curl -I returns a successful status such as:

HTTP/2 200

Also verify in the browser:

• the site loads over https://
• login works if your app has accounts
• recent files or records are present in the new storage or database
• the old cloud dashboard shows no running resources and the account status is "closing" or "closed"

Common pitfalls

You closed the account before exporting the database

Mistake: deleting the managed database or closing the whole account first.

Symptom: the app opens but shows missing content, login failures, or empty tables after migration.

Fix: restore from the last successful backup file you created in Step 3; if you do not have one, stop and contact the provider immediately because retention windows are often short.

DNS still points to the old server

Mistake: moving the app but leaving A or CNAME records unchanged.

Symptom: some users still reach the old site, or the domain stops loading after the old account is closed.

Fix: edit the exact DNS record values to the new IP or hostname, then wait for the TTL you set, commonly 300 seconds.

You forgot non-obvious storage like snapshots or attached volumes

Mistake: backing up the VM but not the attached disk, snapshot, or object storage bucket.

Symptom: the new server starts, but uploaded files, media, or historical data are missing.

Fix: return to Storage, Volumes, Snapshots, and Buckets in the old account and export each one separately.

API keys or service accounts still exist in the old account

Mistake: closing resources but leaving active credentials behind.

Symptom: security alerts, failed integrations, or confusion about whether anything still depends on the old account.

Fix: revoke all API keys and remove service accounts before final closure.

You trusted a backup file without testing a restore

Mistake: downloading a backup and assuming it is usable.

Symptom: the restore fails only after the old account is gone.

Fix: always run one real restore into the new database or storage location before you close the old account.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.