Leaving Kapsule: Taking Everything With You

This is the complete checklist for moving your websites, files, databases, mailboxes and domains to another provider, in the order that keeps all of it intact. Almost every route out is self-service, and where a step still needs us, this page says so and tells you exactly what to ask for.

Your data is yours. Nothing here needs our permission, and none of it starts with a conversation.

Do It in This Order

The most expensive mistake people make when leaving a host is cancelling first and exporting second.

Cancelling is only a billing action, so nothing is deleted the moment you confirm it. But when the paid period runs out, the websites stop serving and the mailboxes stop delivering, and at that moment everything you were about to download stops being downloadable. Recovering it afterwards is a support request rather than a button, and it is slower and less complete than doing it a week earlier would have been.

So the order is:

1. Request the account export. It runs in the background while you do everything else.
2. Export the things the account export does not include: mailbox messages, website files, databases.
3. Open what you exported. A finished archive is not a verified one.
4. Start any domain transfer. Transfers run on the registry's clock, not ours, and they take days.
5. Repoint DNS at the new host, and confirm the new host is actually serving.
6. Cancel the subscriptions, once nothing you still need is here.
7. Close the account, if you want it closed at all.

Two traps sit inside that order.

If you only need a break rather than an exit, a paused subscription stops the invoices while leaving everything provisioned and your data in place. That is covered in Cancelling Your Plan. It is a real option, and it is the last thing this guide will say about staying.

Start With the Account Export

Go to Settings, then Account, and find the card called Your data. Click Request full export. We build a single archive of everything we hold about the account and email you when it is ready.

Inside the archive:

• full-export.json, every record we hold, grouped by category: account and profile, billing and payments, support, email, domains and DNS, websites and hosting, projects and Orbit, servers, security and activity, and the assistant. Each section states its true row count, and anything credential-bearing is replaced with a redaction marker rather than being handed over.
• A DNS zone file per domain, in standard BIND format. This is the single best reason to run the export before you touch anything: it is a real, importable copy of your records rather than a screenshot.
• A .env file of variable names per Orbit project, names only and never values. See the Orbit section below.
• A CSV of deployments per Orbit project.

Three limits worth knowing before you rely on it:

• It is Owner or Admin only. Other roles do not see the button.
• There is a 24-hour cooldown between exports, so do not burn one on a trial run.
• The download link expires 7 days after the export finishes. Fetch it promptly and keep your own copy.

Website Files

Three routes. Pick by size.

The file manager is the quickest for a whole site. Open the site, go to Files, select the folders you want, and click Download. For more than one item it offers Download {count} items as zip, asks you to name the archive, and builds it with Create + Download. See The File Manager.

SFTP has no size ceiling and is the right tool for a large site. It pulls the entire document root in one operation and resumes if the connection drops. Note that we offer SFTP only, authorised with an SSH key rather than a password, and the username is the site's own system user rather than your panel login. SFTP Access has the host, the port and the setup.

Backups are not a download route today. See the next section, because this one surprises people.

What a Backup Will and Will Not Give You

Every site gets an automatic backup on a schedule you choose, holding both the files and the database, kept 30 days as standard and longer on a paid retention tier. Taking a Backup covers all of that.

Two things about backups matter specifically when you are leaving.

Browse files restores, it does not download. The Browse files button on a completed backup opens a picker whose only action is Restore selected: it puts those files back into your live site. It does not hand you a copy. If what you want is a file on your own machine, use the file manager or SFTP.

A backup that never reached offsite storage cannot be handed over at all. The Backups tab has an Offsite column. If you do end up asking support for an archive, take a fresh manual backup first and check that column before you rely on it.

Databases

You do not need a backup to take a database away, and this is the part of the export that is genuinely well served. All three routes produce an ordinary SQL dump that any MySQL server will import.

phpMyAdmin is the general answer. Open the site, go to Database, and click the button to open phpMyAdmin. Its Export tab produces a full SQL dump. See Accessing Your Database With phpMyAdmin.

WordPress sites have a one-click button. Open the site, go to WordPress, then the Database section, and click Export DB. It streams a gzipped SQL dump straight to your browser with nothing stored and nothing to expire. It refuses above 100 MB and tells you to use SSH or phpMyAdmin instead, which is the correct advice for a database that size.

A remote connection or an SSH tunnel lets you run mysqldump from your own machine, which is the most reliable option for anything large. The Database page shows the host, port, database name and credentials to use. See Connecting to Your Database Remotely and Connecting Through an SSH Tunnel.

Export every database your site uses, not just the one you remember. A site running a store or a forum alongside the main application often has more than one.

Mailboxes

Mail does not live in your website backup and it is not in the account export. It has to be taken separately, and missing this is the most common hole in an otherwise complete migration.

Export Mailbox is the self-service route. Open Email, click the mailbox, and on the Setup tab use Download .mbox. You get every message from every folder as one file that Thunderbird, Apple Mail and most other clients open directly, and that most providers will import.

IMAP is the complete answer for a large mailbox, and the one with no cap. Connect the mailbox in a desktop client, let every folder download in full, and you have a local copy. Better still, most providers will pull directly from IMAP on your behalf, which is the cleanest migration of all and usually the one to ask your new host for. The settings are the same ones you already use:

IMAP vs POP3 explains why IMAP is the one to use here, and Setting Up Your Mailbox in a Mail Client has the per-client steps.

Copy your routing rules by hand. Forwarders, aliases, catch-all rules, distribution groups and shared inboxes are not inside an .mbox file and all of them have to be rebuilt at the other end. Email Forwarding, Email Aliases and Distribution Groups show where each one lives so you can copy the settings out.

Domains

A domain is the one asset with real failure modes on the way out, and the only one with an outside clock. Start it first and treat everything else as work you do while it runs.

The full process is in Transferring Your Domain to Another Registrar, and the code your new registrar will ask for is in Getting Your Domain Auth Code. You get that code yourself, from the domain's Settings tab under Renewal & Transfer, and we email it to you. We will not withhold it, and that is true even if there is money outstanding on the account.

Rather than repeat those articles, here is what actually stops a transfer:

• The registrar lock. The registry rejects the transfer while the lock is on, whatever code you use.
• A registry-level lock. Some domains carry a lock only the current registrar can ask the registry to lift.
• The 60-day rule. Most registries refuse a transfer within 60 days of registration, and within 60 days of the previous transfer. This is the ICANN Transfer Policy and it binds .com, .net, .org and the other gTLDs. It does not bind every registry, and .nz has no such rule. See .nz Domain Rules.
• WHOIS privacy, which some registrars will not proceed past. Turn it off for the transfer. See WHOIS Privacy.
• DNSSEC. Leave it on through a transfer and the domain can stop resolving entirely at the far end. Turn it off first and wait. See DNSSEC.
• An expired domain, which registries usually refuse to transfer. Renew it first, then move it.
• Redemption. Once a domain has expired and fallen into the redemption period it cannot be transferred at all. It has to be restored with the current registrar first, and a redemption restore carries a registry fee far higher than a renewal. This is the state to avoid, and the way people reach it is by cancelling and looking away.

Orbit Projects

Your git repository is already yours, and it is the majority of the value. What is worth understanding is the part that lives in our database and never went into the repo.

Environment variables are the thing people lose. There are three kinds and they behave differently:

• Plain config values are visible in the panel, so you can copy them out.
• Secrets are masked, but the account Owner can reveal them one at a time. Every reveal is written to the audit log before the value is shown.
• Sensitive values are write-only and can never be read back, by you, by your team, or by us. If a variable was stored this way, the only route is to re-issue the credential at whatever service created it.

The Export .env template button gives you variable names only, never values. Treat it as the checklist of what you need to go and find, not as a backup. For a bulk copy of the values you can read, mint an API token as the Owner with the env:read:values scope and run kapsule env pull with the CLI, then revoke the token when you are done. See Environment Variables and Orbit API Tokens.

Build settings are not in your repo. The install command, build command, output directory, root directory, Node version and framework preset all live in our database, per environment. Copy them out of the project's Settings before you go, or read them out of full-export.json. See Build Configuration.

Take the history that is not reconstructible from git. Commits, branches and authors you already have. What you do not have is build durations, failure categories, deploy health and any notes your team left, all of which come out of the Deployments tab as a CSV. Build logs and build artifacts each have their own download.

Analytics and logs expire on their own, and sooner than you think. Web analytics are kept 30 days, runtime request logs 72 hours, and edge logs a few days. Anything older is already gone and leaving does not change that. If the numbers matter to you, export the analytics panels to CSV before you cancel, and note that each panel exports up to 250 rows. See Analytics.

Custom domains and certificates. The domain itself is covered above. TLS certificates are issued by us and are not exportable, which costs you nothing: your new host issues its own. Redirects and branch-pinned domains have to be rebuilt by hand.

What You Cannot Take With You

Short and honest:

• Write-only sensitive environment variable values. Re-issue them at the source.
• Web analytics older than 30 days, request logs older than 72 hours, edge logs older than a few days. They have already been deleted on a rolling basis.
• TLS certificates. Your new host issues its own.
• Orbit configuration snapshots. They restore in place; there is no export.
• A backup archive, without asking us. Covered above.

What We Keep After You Go

If you close the account, three different clocks run, and they are not the same length.

• Your hosting content is deleted 30 days after closure. Sites, files, databases, mailboxes, forwarders and backups. Those 30 days are also the window in which you can cancel the closure and have everything back exactly as it was, because after the content is gone there is nothing to come back to.
• The records we hold about you are deleted 12 months after closure. Your name, contact details, credentials, sessions, support conversations and assistant history.
• Invoices, orders and payment records are kept for seven years. New Zealand law requires business and tax records to be held that long, and that obligation does not end when the customer relationship does. They are unlinked from your contact details and nobody can sign in to reach them, but we will not delete them on request while the seven-year obligation runs.

A few practical notes on closing:

• Closure is Owner only, and it is a request followed by a one-time code emailed to your billing address. Until you enter that code, nothing is scheduled.
• The panel refuses to close an account that still has an active subscription, an unpaid invoice, or a domain registered here, and tells you which one is in the way. That refusal is deliberate: closing over the top of a live domain is how people lose a name they meant to keep.
• A deleted mailbox is recoverable for 7 days. That grace does not stack on top of account closure: mailboxes are removed when the 30 days end, not 37 days later.

The full walkthrough is in Closing Your Kapsule Account. You do not have to close the account at all; cancelling the subscriptions and leaving it empty is fine, and costs nothing.

If you simply stop paying rather than cancelling, a different sequence applies, with its own suspension and cancellation stages. That is set out in What Happens If You Stop Paying.

Related Reading

• Closing Your Kapsule Account
• Cancelling Your Plan
• What Happens If You Stop Paying
• Transferring Your Domain to Another Registrar
• SFTP Access
• Accessing Your Database With phpMyAdmin
• Environment Variables