[Home](https://servhidden.com/) / [Privacy Hosting Guides](https://servhidden.com/guides) / How to Migrate a Website to Offshore Hosting Without Downtime Operations # Migrate to Offshore Hosting Without Downtime Almost every painful migration is an ordering failure, not a technical one — a TTL lowered on the night instead of two days before, a certificate issued after the DNS change instead of before, a cron job left armed on a server that is no longer authoritative. This is the sequence that removes the downtime window entirely, plus the part generic guides skip: what the move permanently records about you, and what you can still do about it. [Read the guide](#guide-body) [FAQ](#guide-faq) ## On this page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Related guides](#guide-related) - [Recommended pages](#guide-cta) No KYC Crypto Only No Logs DMCA Ignored Full Root NVMe SSD 16 min read Updated Aug 2026 On this page [01What “zero downtime” actually means](#what-zero-downtime-actually-means) [02Lower the DNS TTL days before you plan to move](#lower-the-dns-ttl-days-before-you-plan-to-move) [03Inventory what you are moving, not what you remember](#inventory-what-you-are-moving-not-what-you-remember) [04Build the new server first, and harden it before it holds anything](#build-the-new-server-first-and-harden-it-before-it-holds-any) [05Copy the data twice: a slow pass, then a fast one](#copy-the-data-twice-a-slow-pass-then-a-fast-one) [06Test the new server before DNS knows it exists](#test-the-new-server-before-dns-knows-it-exists) [07The cutover, in order](#the-cutover-in-order) [08What the migration leaves behind](#what-the-migration-leaves-behind) [09The domain question: carry it over, or start fresh?](#the-domain-question-carry-it-over-or-start-fresh) [10Decommission the old host properly](#decommission-the-old-host-properly) [11The whole sequence on one page](#the-whole-sequence-on-one-page) [FAQCommon questions](#guide-faq) [→Recommended pages](#guide-cta) Nobody moves a live site for entertainment. It happens because the current host suddenly wants a photograph of your passport, or forwards a complaint with a twenty-four hour deadline, or because the country its datacentre sits in stopped looking like a sensible place to keep your data. Whatever pushed you, the move itself is the dangerous part — it is the one moment the site can go dark, and the one moment a careless step can staple the new server to the identity you were trying to leave behind. Both risks have the same cure, and it is not a tool. It is ordering. A migration run in the right sequence has no window in which the site is unreachable, because both servers are alive at the same time and DNS is the last thing to move. A migration run in the wrong sequence produces an outage and a trail at once. What follows is that sequence, written for someone moving to an offshore, no-KYC host rather than shuffling between two mainstream providers — the mechanics are the same, but the cleanup afterwards is not. ## What “zero downtime” actually means The phrase is used loosely, and the looseness is where people get hurt. Serving HTTP from two machines at once is easy. Keeping *state* consistent while two machines serve at once is the hard part, and it is the only part that ever loses data. So before planning anything, decide which of these you are actually running, because the answer sets the shape of the whole night. | What you are moving | The part that actually bites | What the plan should be | | --- | --- | --- | | Static site, brochure site, generated output | Nothing. There is no state to split | Copy, verify, cut over. Genuinely zero downtime | | CMS with a database — WordPress, Ghost, a forum | Comments, logins and posts landing on two databases at once | A read-only freeze measured in **minutes**, at your quietest hour | | A store, or anything that takes orders | A split brain silently loses paid orders | Take the short maintenance window. It is cheaper than reconciliation | | Anything with cron jobs or background workers | The same job firing on both servers — double emails, double charges | Disable the schedule on the old host *before* the new one starts | | Mail on the same domain | MX records expire from caches on their own clock, unrelated to your A record | Move mail on a separate night, and keep the old MX accepting for a week | Notice that only the first row is truly free. Everywhere else, “zero downtime” means “a write freeze so short nobody files a ticket about it”. Two minutes of read-only at 04:00 is a rounding error; two hours of split writes across two databases is a weekend of reconciliation. Choose the freeze. Both servers run at once and DNS moves last — which is why a correctly sequenced cutover has no window at all. ## Lower the DNS TTL days before you plan to move This is the single step with a lead time, which is why it is first and why it is the one people skip. Your TTL — time to live — tells every resolver on the internet how long it may cache your record before asking again. If your A record has a TTL of 86400, a resolver that looked it up an hour ago will keep handing out the old IP for another twenty-three hours, no matter what you change at the registrar. The critical detail is that lowering the TTL is itself subject to the old TTL. Resolvers only learn about the new, shorter value when the old cached copy expires. So drop the TTL to 300 seconds **at least one full old-TTL period before the cutover** — with a day-long TTL, that means doing it 24 to 48 hours ahead. Then the world converges on your new record within five minutes of the change, and the cutover stops being a suspenseful event. Put the TTL back up to something sane a few days after the move. A 300-second TTL is a fine tool and a poor permanent setting: it multiplies your query volume and makes your DNS provider a much sharper single point of failure. ## Inventory what you are moving, not what you remember Every failed migration has the same post-mortem: something nobody listed was not copied. The web root and the database are the two things everyone remembers; the list below is the rest, and it is worth walking it literally rather than from memory. - **Scheduled work.** crontab -l for every user, plus systemd timers. Renewal hooks and nightly jobs hide here. - **Service definitions.** Custom systemd units, the web server vhosts, PHP-FPM pools, any supervisor config. - **Secrets and environment.** .env files, API keys, database passwords, application salts — and note that these should be rotated, not merely copied. - **TLS material.** Certificates and, more importantly, the ACME account and renewal configuration. - **Mail identity.** DKIM private keys, SPF and DMARC records. A mismatch here does not break loudly; it just quietly sends your mail to spam. - **Uploaded media.** Frequently outside the web root, frequently the largest thing you own. - **Everything external that trusts your IP.** Payment gateway allowlists, webhook destinations, database firewalls, third-party APIs with IP restrictions. This is the number one cause of “the site works but checkout is broken” at 03:00. - **The package list.** dpkg --get-selections or the equivalent, so the new box has the same extensions and libraries rather than nearly the same ones. Write the list down before you start copying. The inventory is also your test plan later — every line on it is something to verify on the new server before DNS knows it exists. ## Build the new server first, and harden it before it holds anything Order the destination early and leave it running empty for a day or two. There is no cost to overlap — a small offshore VPS is a few dollars a month — and a great deal of value in not doing the build under time pressure with a frozen database waiting. Match the old environment deliberately: the same distribution and major version, the same PHP or Node or Python major version, the same database major version. The temptation to modernise while you are in there is enormous and should be resisted completely. If the site breaks after the cutover, you want exactly one variable to have changed. Upgrade the stack a fortnight later, on a boring afternoon, with the ability to roll back. Harden it while it is still empty. Keys-only SSH, a default-deny firewall, automatic security updates — the [first-hour hardening checklist](https://servhidden.com/guides/first-hour-vps-hardening-checklist) is exactly this list, and it is far easier to apply to a machine with nothing on it. If the data is sensitive enough that you are moving jurisdictions over it, this is also the right moment to decide about [encryption at rest](https://servhidden.com/guides/full-disk-encryption-on-a-vps), because retrofitting it later means another migration. ## Copy the data twice: a slow pass, then a fast one The instinct is to copy everything during the maintenance window. Do the opposite. Run a full copy days ahead while the old site is happily serving traffic, then run a second pass at cutover that only moves what changed. The first pass can take six hours and nobody notices. The second takes ninety seconds, and that is your entire downtime budget. For files, rsync -aHAX --numeric-ids preserves permissions, ownership, hard links and extended attributes; the --numeric-ids flag matters because UIDs rarely line up between two freshly built machines. Run it once early, then again immediately before the cutover with the same arguments — the second run transfers only the delta. Databases need the same two-phase treatment but different tools. A mysqldump --single-transaction or pg_dump gives you a consistent early snapshot to build and test against. At cutover, either take a second dump during your brief write freeze, or — for a large database where even a short freeze hurts — set the new server up as a replica of the old one days in advance, let it catch up, and then promote it. Replication turns the freeze into seconds. It also turns a two-hour migration into a two-day project, so use it only when the size genuinely demands it. **Pull, do not push, and never through your laptop.** Initiate the copy from the new server so the transfer runs host to host at datacentre speed. Routing gigabytes through your home connection is slow, and it puts your residential IP in the access logs of both machines — which is precisely the link a privacy-motivated migration exists to avoid. If even the old host learning your new IP is unacceptable, do not copy directly at all: restore the new server from your own [off-site encrypted backup](https://servhidden.com/guides/vps-backup-strategy) instead, and the two machines never speak. ## Test the new server before DNS knows it exists You can serve the real hostname from the new IP without changing a single public record, and you should — this is what makes the cutover uneventful. Add a line to your local /etc/hosts pointing the domain at the new IP, or skip that and let curl do it for one request: curl -I --resolve example.com:443:203.0.113.10 https://example.com/ Now walk the inventory. Load the front page and three deep pages. Log in. Submit a form. Upload a file. Check that the database connection is the new local one and not still pointing at the old host over the internet — a mistake that works perfectly right up until you cancel the old server. Run the cron jobs by hand and read their output. Verify redirects and that a missing URL still returns 404 rather than 200. Issue the TLS certificate now, before the cutover, not after. Use a DNS-01 challenge, which proves control of the domain through a TXT record and therefore works while the A record still points at the old server. If you wait for HTTP-01 validation after the DNS change, every early visitor gets a certificate warning during the gap — a self-inflicted outage in the one window you were trying to protect. ## The cutover, in order By this point the new server is built, hardened, populated, tested under the real hostname and holding a valid certificate. The cutover itself is now a short, dull list, which is the goal. - Announce the window if anyone else depends on the site, then put the old site into read-only or maintenance mode. - **Disable cron and background workers on the old host.** Do this before starting them on the new one, never after. - Run the final rsync delta pass and the final database dump, and import it. - Start the application on the new server and re-run your smoke tests through --resolve, against the final data. - Change the A and AAAA records to the new IP. With a 300-second TTL, the world follows within five minutes. - Enable cron and workers on the new host. - Watch both access logs side by side. Traffic drains from the old server and appears on the new one; when the old one goes quiet, the cutover is complete. - Leave the old server running, serving, and untouched for a week. It is your rollback. Step eight is the one people cut, and it is the cheapest insurance in the list. For the price of a few dollars you keep the ability to point DNS back — a five-minute recovery — for as long as it takes to be sure. ## What the migration leaves behind Here is the part generic migration guides omit, and the part that matters most if you moved for privacy rather than for price. Moving a site does not erase its history. Several public and semi-public records of the old arrangement survive the move permanently, and knowing which ones is the difference between a clean break and a false sense of one. | What records the move | Who can read it | What you can actually do | | --- | --- | --- | | Passive DNS — historical A records | Anyone, through commercial history services | **Nothing.** The old IP is permanently associated with the name. Plan as if it is public, because it is | | Certificate Transparency logs | Anyone, permanently, searchable by domain | Every certificate ever issued is listed — including the internal-sounding subdomains you forgot. Prefer a wildcard to descriptive names | | The old host’s account records | The old host, and anyone who can compel them | Card details, signup email, login IPs. A no-KYC destination protects the future, not the past | | WHOIS history | Commercial WHOIS-history archives | If the domain was ever registered under real details, that snapshot is captured. Privacy applied later does not retract it | | Analytics and ad identifiers | The vendor, and anyone reading your page source | Carrying the same tracking ID across links the two sites conclusively. Issue a new one, or drop it | | Dumps and backups left on the old disk | Whoever is allocated that storage next | Delete and overwrite before cancelling. On shared storage, assume deletion is a hint rather than a guarantee | | Received: headers in sent mail | Every recipient, forever | Nothing retroactive. Only the mail you send after the move carries the new path | | Your own connections during the copy | Your ISP, and both hosts’ access logs | This one is entirely under your control. Never touch either machine from an IP that identifies you | The honest summary is that a migration cannot rewrite the past — it can only stop adding to it. That is still worth a great deal, but it changes the decision: if your threat model requires that no observer can link the new site to the old one, moving the same domain to a new host does not achieve it, and no amount of care during the cutover will. That case needs a new name and a clean start, discussed next. If your goal is instead to stop generating identifying records from today onward, and to move the legal centre of gravity to a jurisdiction you chose, the move does exactly that. Our [server OpSec guide](https://servhidden.com/guides/server-opsec-staying-anonymous) covers the habits that keep it clean afterwards. ## The domain question: carry it over, or start fresh? The site and the domain are independent decisions, and conflating them is common. You can move the hosting today and leave the registrar alone forever; nothing about the server change requires touching the domain. Whether you *should* depends entirely on what the domain already knows about you. - **Keep the domain, change the registrar.** Sensible when the domain has value — links, rankings, a name people type. It fixes the future of the WHOIS record, not its history, and it keeps every ranking signal intact. This is the right answer for most commercial sites. - **Keep the domain, change nothing but the host.** Perfectly reasonable when you moved for jurisdiction, uptime or DMCA posture rather than anonymity. Simplest possible move, zero SEO risk. - **New domain, redirect the old one.** Preserves rankings, and publicly and permanently links the two names. Choose it for continuity, never for privacy — the redirect is the link. - **New domain, clean break.** The only option that genuinely severs the association, and it costs you every ranking and inbound link you had. Register it privately from the start, because a domain is only as anonymous as its first registration. Our guide to [anonymous domain registration with crypto](https://servhidden.com/guides/anonymous-domain-registration-with-crypto) covers doing that properly. Pick deliberately, and pick before the cutover rather than during it. Changing your mind about the domain after the DNS has moved means doing the delicate part twice. ## Decommission the old host properly A week or two after the cutover, when the new server’s logs are boring and the old one’s are empty, it is time to close the old account. Do it in this order, because the tempting shortcut — hitting cancel — is the one that leaves your data on someone else’s disk. - Confirm nothing still points at the old IP: check for hardcoded addresses in third-party webhooks, allowlists, monitoring, and any DNS record you forgot, such as a stray mail or cpanel subdomain. - Rotate every secret that ever lived on that machine — database passwords, API keys, application salts, DKIM keys, SSH keys. Do not copy them forward. - Remove your SSH public keys and any support access from the old server. - Delete the application, the dumps and the backups, then overwrite the free space so a casual read of the recycled volume yields nothing. - Only then terminate the service, and remove any stored payment method from the old account. **Anything that lived on hardware you no longer control is compromised by definition.** Not because your old host is malicious, but because that disk is going back into a pool and you will never know what survived the wipe. Rotating a database password takes two minutes. Discovering months later that a key from a decommissioned server still opens something takes considerably longer. ## The whole sequence on one page Strip out the reasoning and a host migration is nine steps, of which only two have any urgency: - **Two days ahead:** lower the DNS TTL to 300 seconds. - **Two days ahead:** order and harden the destination server, matching the old stack version for version. - **Days ahead:** write the inventory — cron, secrets, TLS, mail keys, media, IP allowlists, packages. - **Days ahead:** run the first full data copy, host to host. - **Before the window:** issue the certificate by DNS-01 and test everything through --resolve. - **The window (minutes):** freeze writes, disable old cron, run the delta copy and final dump, start the new app. - **The window (seconds):** change the A record, then enable cron on the new host. - **The following week:** keep the old server alive as a rollback, watch both log files, then raise the TTL again. - **Afterwards:** rotate secrets, wipe, cancel — and remember what the move could not erase. Nothing in that list is difficult. Every step that hurts is a step done out of order — a TTL lowered on the night, a certificate issued after the DNS change, a cron job left armed on a machine that is no longer authoritative. Get the sequence right and the interesting part of a migration is choosing where to put the server, not the move itself. If you have not settled that yet, the [jurisdiction guide](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) is the place to start. FAQ ## Host migration — common questions ### 01 How much downtime should I really expect? For a static site, none at all — both servers can serve the same content simultaneously, so the DNS change is invisible. For anything with a database, your downtime is exactly the length of your write freeze, which is typically two to ten minutes if you have already run a full data copy beforehand. The number that matters is not how fast DNS moves; it is how much you copy during the window. Copy almost everything days in advance and the window shrinks to the size of the delta. ### 02 How long does DNS propagation take? There is no propagation — that word describes something that does not happen. Resolvers simply cache your record for as long as its TTL said to, and ask again when it expires. If the TTL in effect was 86400, some resolvers will serve the old IP for a further 24 hours. Lower the TTL to 300 seconds at least one full old-TTL period before the cutover and the entire internet follows your change within five minutes. ### 03 Do I have to move my domain as well? No. The registrar and the host are completely independent, and moving the site while leaving the domain exactly where it is works perfectly. Whether you should move it depends on your reason for migrating: if it was jurisdiction, price or DMCA posture, leave the domain alone. If it was anonymity, note that the domain carries its own separate history — WHOIS archives keep whatever details it was first registered with, and hosting changes do not touch that. ### 04 Can I migrate without the old host learning where I went? Not if you copy directly between the two machines — one end connects to the other, and both sets of access logs record it. If that link genuinely matters to your threat model, do not copy host to host at all: restore the new server from your own off-site encrypted backup, so the two providers never exchange a packet. Either way, never initiate the transfer from a connection that identifies you, and keep the destination out of any support ticket you open with the old provider. ### 05 Should I upgrade the OS or the stack at the same time? No, and this is the most common self-inflicted migration failure. Change one thing. If the site misbehaves after the cutover you want a single candidate explanation, not a choice between the new machine, the new PHP version and the new database major. Match the old environment version for version, complete the move, confirm a week of clean logs, then upgrade separately with the ability to roll back. ### 06 Will migrating hurt my search rankings? Not meaningfully, provided the domain, the URLs and the content stay the same — Google indexes URLs, not IP addresses, and a host change on its own is not a ranking signal. Keep the URL structure identical, return the same status codes, and do not combine the move with a redesign or a URL scheme change. If you are moving to a new domain instead, expect a temporary dip even with correct 301 redirects, and understand that those redirects also publicly connect the two names. ### 07 Do I need to re-issue TLS certificates? Yes — the new server needs its own certificate and private key, and copying the old key forward is a bad habit even when it technically works. Issue it before the cutover using a DNS-01 challenge, which validates through a TXT record and therefore succeeds while the A record still points at the old host. Waiting for HTTP-01 after the DNS change guarantees a stretch of certificate warnings in the exact window you were trying to protect. ### 08 When is it safe to cancel the old server? After a week or two of quiet logs on the old machine and clean logs on the new one — the delay is your rollback, and it costs a few dollars. Before you cancel, check that nothing external still points at the old IP, rotate every secret that ever lived on it, then delete your data and overwrite the free space. Cancel last. Hitting terminate first leaves your database on a disk you no longer control. Related guides ## Keep reading [### How to Choose an Offshore Hosting Jurisdiction in 2026 Buying A practical decision framework for picking an offshore jurisdiction: data-retention law, MLAT exposure, DMCA stance, court speed and real-world enforcement — country by country. 6-question FAQ](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) [### VPS vs Dedicated Server for Privacy-Critical Workloads Buying When a VPS is fine, when shared tenancy is a liability, and when bare metal is the only honest answer. Hardware isolation, hypervisor risk, and cost vs threat model. 6-question FAQ](https://servhidden.com/guides/vps-vs-dedicated-for-privacy) [### Self-Hosted VPN on a No-KYC VPS: WireGuard vs OpenVPN Operations Why a self-hosted VPN beats commercial providers, and how WireGuard and OpenVPN really compare on privacy, performance and operational risk in 2026. 6-question FAQ](https://servhidden.com/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 for AI Inference (and Where the RTX 5090 Fits) Buying Buying guide: which NVIDIA GPU for self-hosted LLM, image, video, speech, and fine-tuning workloads in 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, when each wins. 6-question FAQ](https://servhidden.com/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP for MT4 / MT5 / cTrader Forex Trading Operations Complete guide: why a Windows RDP for Forex trading, how to choose a low-latency offshore jurisdiction, MT4 / MT5 / cTrader / Expert Advisor setup, latency to broker servers, and the no-KYC checkout path. 6-question FAQ](https://servhidden.com/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting Explained: What It Really Means in 2026 Buying What "DMCA ignored" hosting genuinely buys you, which jurisdictions actually back it up, the workloads that need it, and the copyright traps the term doesn't cover. 6-question FAQ](https://servhidden.com/guides/dmca-ignored-hosting-explained) [### Anonymous Domain Registration with Crypto: WHOIS Privacy in 2026 Privacy A practical 2026 guide to registering domains without revealing your identity: WHOIS regimes by TLD, registrar choice, crypto payment options, and the operational mistakes that leak you anyway. 6-question FAQ](https://servhidden.com/guides/anonymous-domain-registration-with-crypto) [### Crypto Payments for Hosting: Monero vs Bitcoin vs USDT Privacy How payment coin affects what your host learns about you. Privacy, fees, finality and chain analysis exposure for XMR, BTC and USDT — with a clear recommendation. 6-question FAQ](https://servhidden.com/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Is Offshore Hosting Truly Anonymous? An Honest Answer Privacy Offshore, no-KYC hosting removes the identity a normal host collects — but "anonymous" depends on payment, provider logging and your own opsec. Here is what is really traceable. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-truly-anonymous) [### The First Hour of VPS Hardening: A Checklist Operations A concrete, ordered checklist to secure a new VPS in under an hour: SSH keys, a firewall, fail2ban, automatic updates, and the attack-surface reduction that stops most opportunistic attacks. 6-question FAQ](https://servhidden.com/guides/first-hour-vps-hardening-checklist) [### What Is No-KYC Hosting? Definition, Legality & How It Works Privacy No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider. 6-question FAQ](https://servhidden.com/guides/what-is-no-kyc-hosting) [### Is Offshore Hosting Legal? The Honest 2026 Answer Buying Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-legal) [### How to Pay for Hosting with Monero (XMR) — Step by Step Privacy A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes. 6-question FAQ](https://servhidden.com/guides/how-to-pay-for-hosting-with-monero) [### How to Host a Website Anonymously — A Practical 2026 Guide Privacy A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-website-anonymously) [### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide Operations Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it. 6-question FAQ](https://servhidden.com/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### How to Self-Host an LLM on a GPU Server — 2026 Guide Operations Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs. 6-question FAQ](https://servhidden.com/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs Offshore Hosting — What Is the Difference? Buying Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want. 6-question FAQ](https://servhidden.com/guides/bulletproof-vs-offshore-hosting) [### How to Buy a VPS with Bitcoin — Step-by-Step (2026) Buying A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached. 6-question FAQ](https://servhidden.com/guides/how-to-buy-a-vps-with-bitcoin) [### Best Countries for DMCA-Ignored Hosting in 2026 Buying Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose. 6-question FAQ](https://servhidden.com/guides/best-countries-for-dmca-ignored-hosting) [### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide Operations Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-tor-hidden-service) [### Offshore Mail Server Setup — Self-Host Private Email in 2026 Operations Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right. 6-question FAQ](https://servhidden.com/guides/offshore-mail-server-setup) [### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS Operations How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private. 6-question FAQ](https://servhidden.com/guides/crypto-node-hosting-guide) [### GPU Hosting for Stable Diffusion — Run Your Own Image Server Operations Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service. 6-question FAQ](https://servhidden.com/guides/gpu-hosting-for-stable-diffusion) [### Server OpSec — Staying Anonymous When You Run a Server Privacy Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate. 6-question FAQ](https://servhidden.com/guides/server-opsec-staying-anonymous) [### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026 Operations How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure. 6-question FAQ](https://servhidden.com/guides/seedbox-setup-guide) [### How to Bypass DPI Censorship with Your Own VPS (2026 Guide) Privacy Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough. 6-question FAQ](https://servhidden.com/guides/bypass-dpi-censorship-with-your-own-vps) [### Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects Operations How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops. 8-question FAQ](https://servhidden.com/guides/full-disk-encryption-on-a-vps) [### Hiding Your Origin Server IP: CDNs, Reverse Proxies and What Still Leaks Privacy Whether to put a CDN in front of an offshore server: what it hides, the abuse desk you inherit, the six ways an origin IP leaks anyway, and how to audit yours. 8-question FAQ](https://servhidden.com/guides/hiding-your-origin-server-ip) [### VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable Operations Your host keeps no backups. What really destroys servers, why push backups die with them, restic vs Borg, the keys everyone forgets, and how to test a restore. 8-question FAQ](https://servhidden.com/guides/vps-backup-strategy) [### Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide Operations What a Matrix homeserver really gives you: Synapse vs Conduit, the server_name you can never change, media that eats the disk, and what federation still reveals. 8-question FAQ](https://servhidden.com/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operations Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-question FAQ](https://servhidden.com/guides/self-host-a-crypto-payment-gateway) ## Give the migration somewhere to land Offshore KVM servers in seven jurisdictions from $7.50/mo, with full root, NVMe storage and unmetered bandwidth, deployed in under five minutes once a crypto payment confirms. Spin the destination up early, copy at your own pace, and cut over when it is ready. [View VPS Plans](https://servhidden.com/vps) [Offshore Hosting](https://servhidden.com/offshore-hosting) [All Locations](https://servhidden.com/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Offshore VPS & dedicated servers in 7 offshore jurisdictions. No KYC, no logs, crypto only. Privacy by architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "How to Migrate a Website to Offshore Hosting Without Downtime", "description": "The order that makes a host migration boring: lower the DNS TTL days ahead, run both servers in parallel, freeze writes for minutes rather than hours — and clean up the passive-DNS, Certificate Transparency and WHOIS trail the move leaves behind.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "en", "keywords": "migrate website to offshore hosting, change hosting provider without downtime, zero downtime server migration, move a VPS to a new host, DNS TTL cutover, migrate to a no-KYC host, website migration checklist, rsync server migration", "articleSection": "Operations", "wordCount": 3157 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How much downtime should I really expect?", "acceptedAnswer": { "@type": "Answer", "text": "For a static site, none at all — both servers can serve the same content simultaneously, so the DNS change is invisible. For anything with a database, your downtime is exactly the length of your write freeze, which is typically two to ten minutes if you have already run a full data copy beforehand. The number that matters is not how fast DNS moves; it is how much you copy during the window. Copy almost everything days in advance and the window shrinks to the size of the delta." } }, { "@type": "Question", "name": "How long does DNS propagation take?", "acceptedAnswer": { "@type": "Answer", "text": "There is no propagation — that word describes something that does not happen. Resolvers simply cache your record for as long as its TTL said to, and ask again when it expires. If the TTL in effect was 86400, some resolvers will serve the old IP for a further 24 hours. Lower the TTL to 300 seconds at least one full old-TTL period before the cutover and the entire internet follows your change within five minutes." } }, { "@type": "Question", "name": "Do I have to move my domain as well?", "acceptedAnswer": { "@type": "Answer", "text": "No. The registrar and the host are completely independent, and moving the site while leaving the domain exactly where it is works perfectly. Whether you should move it depends on your reason for migrating: if it was jurisdiction, price or DMCA posture, leave the domain alone. If it was anonymity, note that the domain carries its own separate history — WHOIS archives keep whatever details it was first registered with, and hosting changes do not touch that." } }, { "@type": "Question", "name": "Can I migrate without the old host learning where I went?", "acceptedAnswer": { "@type": "Answer", "text": "Not if you copy directly between the two machines — one end connects to the other, and both sets of access logs record it. If that link genuinely matters to your threat model, do not copy host to host at all: restore the new server from your own off-site encrypted backup, so the two providers never exchange a packet. Either way, never initiate the transfer from a connection that identifies you, and keep the destination out of any support ticket you open with the old provider." } }, { "@type": "Question", "name": "Should I upgrade the OS or the stack at the same time?", "acceptedAnswer": { "@type": "Answer", "text": "No, and this is the most common self-inflicted migration failure. Change one thing. If the site misbehaves after the cutover you want a single candidate explanation, not a choice between the new machine, the new PHP version and the new database major. Match the old environment version for version, complete the move, confirm a week of clean logs, then upgrade separately with the ability to roll back." } }, { "@type": "Question", "name": "Will migrating hurt my search rankings?", "acceptedAnswer": { "@type": "Answer", "text": "Not meaningfully, provided the domain, the URLs and the content stay the same — Google indexes URLs, not IP addresses, and a host change on its own is not a ranking signal. Keep the URL structure identical, return the same status codes, and do not combine the move with a redesign or a URL scheme change. If you are moving to a new domain instead, expect a temporary dip even with correct 301 redirects, and understand that those redirects also publicly connect the two names." } }, { "@type": "Question", "name": "Do I need to re-issue TLS certificates?", "acceptedAnswer": { "@type": "Answer", "text": "Yes — the new server needs its own certificate and private key, and copying the old key forward is a bad habit even when it technically works. Issue it before the cutover using a DNS-01 challenge, which validates through a TXT record and therefore succeeds while the A record still points at the old host. Waiting for HTTP-01 after the DNS change guarantees a stretch of certificate warnings in the exact window you were trying to protect." } }, { "@type": "Question", "name": "When is it safe to cancel the old server?", "acceptedAnswer": { "@type": "Answer", "text": "After a week or two of quiet logs on the old machine and clean logs on the new one — the delay is your rollback, and it costs a few dollars. Before you cancel, check that nothing external still points at the old IP, rotate every secret that ever lived on it, then delete your data and overwrite the free space. Cancel last. Hitting terminate first leaves your database on a disk you no longer control." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://servhidden.com/" }, { "@type": "ListItem", "position": 2, "name": "Privacy Hosting Guides", "item": "https://servhidden.com/guides" }, { "@type": "ListItem", "position": 3, "name": "How to Migrate a Website to Offshore Hosting Without Downtime", "item": "https://servhidden.com/guides/migrate-website-to-offshore-hosting" } ] } ```