The move from one host to another is presented in vendor-side runbooks as a straightforward exercise: dump the database, copy the files, repoint the DNS, run the smoke tests, declare the migration complete. For an investigative archive — a publication whose published work includes material that motivates the kind of removal request a hosting provider hopes never to see — the migration is something else. It is a legal moment, an operational-security moment, and a chain-of-custody moment, layered on top of the operational mechanics. The hosting layer changes; the threat model the hosting layer was chosen to address does not.
This article sets out the practical sequence of steps for migrating an investigative archive — a journalist’s published-work archive, a leak-aggregator’s corpus, an NGO’s case-file repository — onto offshore hosting in a jurisdiction selected for its civil-liberties posture rather than its commercial convenience. It is written for readers who have already decided that an offshore-hosting posture is right for the work, and who have already read why offshore hosting matters for journalism and the threat-model framing for activist archives. The choice between Iceland and Switzerland sits one step earlier in the decision tree and is treated separately.
Before the migration: integrity is the foundation
The first failure mode of a migration is not a disclosure or a downtime — it is a corrupted corpus that nobody notices for six weeks. An investigative archive’s value rests on the verifiable integrity of the documents it carries; the move from one host to another is the moment at which that integrity is most likely to slip, because the operational pressure of the cutover competes with the slower discipline of verification.
The discipline that protects against this is mechanical. Every document, every database row, every static asset is hashed at the source — SHA-256 is sufficient — and the hash manifest is signed with a key the editor controls and the hosting operator does not. At the destination, the same hashing is repeated and the manifests are compared. Any divergence is reconciled before the public-facing surface is repointed. The discipline takes additional days; it is the difference between an archive that is verifiable post-migration and one that is not.
For an archive that uses git-annex or content-addressed storage natively, this step is built in; the manifest is the working tree and the comparison is a routine git annex fsck. For an archive that is a Postgres dump and a directory of PDFs, the operator builds a one-off manifest using find -type f -exec sha256sum {} \; and a pg_dump digest of the schema and the row counts; the script that does this is published in our operating principles dossier for any reader who wants to verify the operator’s discipline rather than trust it.
The OPSEC of the migration window
The migration window — the period during which both the old and the new hosts are operationally live — is the period of greatest forensic exposure. Two providers have observed-from-outside SMTP and HTTP traffic from your domain at once; one of them is the one you are trying to leave, and that one’s logs are the ones that will be subpoenaed first.
The discipline that narrows the window is preparation. The destination host is provisioned, configured, and silently running the application stack against a copy of the data, with TLS certificates issued, monitoring lit, backup discipline running, all before the DNS ever points at it. The cutover is then a DNS change with a short-TTL pre-warm — typically 60 seconds, set 24 hours in advance of the cutover so that the lower TTL has propagated globally. After the DNS change, the old surface continues to serve for the duration of remaining cache lifetimes (often hours, sometimes longer for stub resolvers and recursive resolvers operated outside the major-provider ecosystem), and then is torn down. The teardown step matters: an old surface that continues to serve a stale view of the corpus past the point of useful service is itself a forensic surface.
Email servers — for any archive that runs its own mailhost — require a parallel and longer migration. The IP reputation of a mail server takes weeks to build at a new provider; the discipline is to run the new mail server for a month in parallel with the old, gradually shifting outbound mail through the new IP, before tearing the old one down. The post-Snowden reality of mail deliverability — that DKIM, SPF and DMARC reputation is bound to specific IPs and that fresh IPs are treated as untrusted by Gmail, Microsoft, and most reputation-tracking infrastructure for somewhere between two and eight weeks — makes the mail-server migration the longest single thread in the schedule. The deliverability landscape after 2013 is treated separately.
Payment, decoupled
A migration to offshore hosting is also a migration of the financial surface. The card-processor relationship that funded the prior host carries metadata — billing address, card last-four, statement descriptor, timestamps — that ties the operating identity to the publishing identity in ways the prior host’s threat model did not require detangled. Moving the hosting away from a provider that requires that surface, while leaving the financial surface intact, half-completes the migration.
The discipline is to migrate the payment route at the same time. OffshorePress accepts Monero, Lightning, on-chain Bitcoin, or cash by post; for a migrating archive, the cleanest financial surface is Monero where the operator has the discipline to run a wallet, and cash by envelope where they do not. The card-processor relationship is closed at the prior provider after the cutover is verified; the closure itself is a small forensic event (the closure is logged at the processor) but it is the closure of an existing surface, not the opening of a new one.
The legal moment
A migration is also a moment at which legal posture is updated. Who must be told? Who must not? The answers depend on the jurisdictions involved, the corpus carried, and the legal entity that operates the publication.
Counsel review is non-negotiable for any archive whose corpus might attract a removal-order or disclosure-order from a jurisdiction the migration is moving away from. The instinct that a migration is a purely-technical operation, conductable by the operator without legal oversight, is wrong; the migration is, among other things, the disposition of a corpus across jurisdictions, and the disposition of a corpus is a legal act. The counsel review need not be expensive — for an archive whose threat model is well-specified, a one-hour review against a clear migration plan is sufficient — but it cannot be skipped.
The General Data Protection Regulation imposes specific obligations on the transfer of personal data outside the European Economic Area. For an archive that contains personal data of EU data subjects, those obligations attach to the migration whether or not the publication considers itself an EU operation. Article 46 transfer mechanics — Standard Contractual Clauses, Binding Corporate Rules, supplementary measures of the kind set out by the European Data Protection Board’s Recommendations 01/2020 on supplementary measures following Schrems II — apply where the destination jurisdiction has not received an adequacy decision from the European Commission. Switzerland holds a current adequacy decision; Iceland is inside the EEA and the regime applies to it directly rather than through a transfer mechanic. Both routes are GDPR-compliant by construction; the SCCs are not required when the destination is Iceland or Switzerland, but the rest of the GDPR’s obligations still attach to the corpus.
For archives whose corpus contains data subject to specific source-protection or shield-law obligations in the originating jurisdiction, the migration is also an opportunity to refresh the documentary trail of those obligations. A source whose identity is protected by a domestic shield law in the originating country may continue to expect that protection in the destination country — both Iceland and Switzerland have absolute source-protection regimes that meet or exceed most domestic shield laws — but the documentary chain of custody for that source’s communications must travel with the corpus, not be left behind on the prior host’s storage.
Where migrations commonly fail
The migrations that fail catastrophically share a small set of patterns, and the patterns are documented because they recur.
The first is residual logs at the prior provider. A hosting provider retains operational logs — access logs, error logs, billing records, support-ticket records — for a period after the customer relationship ends. The retention period is in the prior provider’s terms of service and is rarely shorter than ninety days; for a migration whose adversary is a legal process targeting the prior provider, the residual-log window is the operational risk. The discipline is to document the retention period before the migration begins, plan for it, and treat the migration as not-yet-completed until the residual-log window has elapsed. A migration that closes the prior account with no notice and assumes the logs are gone is operating on a working assumption that the prior provider’s terms of service contradict on the third page.
The second is DNS cache lifetime in non-controlled resolvers. A short-TTL repointing assumes that resolvers honour the TTL; many do not, particularly stub resolvers configured by enterprise IT departments or by cellular carriers. The pragmatic working assumption is that some non-zero fraction of traffic will continue to hit the old surface for 24 to 48 hours after a cutover, and the old surface must continue to serve correctly until that window closes. Tearing down too aggressively produces a partial outage that looks worse than the migration was designed to be.
The third is mail-server IP reputation, which the operational-security section above introduced and which the schedule below allocates four weeks to. The discipline is to warm the new IP gradually through a controlled increase in send volume over the warm-up period, and to keep the prior provider’s mail flow active during the warm-up. Reputation-warming services exist commercially; the operator’s preference is to skip them and warm manually using a known-good corpus of recipients (the publication’s own existing readership), because the commercial services interleave warming traffic from many simultaneously-warming customers and the resulting reputation is a shared one.
The fourth is payment-stack delays. A Monero payment confirms in approximately twenty minutes; a cash-by-envelope payment confirms when the envelope arrives, which is typically three to seven business days from posting. A migration whose hosting cutover is timed to a Monday morning and whose payment route is cash-by-envelope is operationally fragile if the envelope is posted the prior Friday — the working assumption is that the destination hosting is paid-up before the cutover begins, with margin, and that the payment confirmation has been observed by both sides before the corpus moves.
A practical sequencing
For an archive of moderate size (say, 50,000 documents totalling 100 GB of working data plus a ten-gigabyte database), a working migration sequence runs roughly fourteen days from the day the destination is provisioned to the day the public-facing surface flips. Days 1 to 3 are corpus-side work: hashing, manifest generation, counsel review of the migration plan, payment to the destination provider with confirmation observed. Days 4 to 6 are destination-side provisioning: the new VPS-4 or DS Lite in the chosen jurisdiction, the application stack configured, the corpus copied, the integrity verified against the source manifest. Days 7 to 9 are the silent-running period: the destination serves a copy of the corpus to internal verification only, while the prior surface continues to serve the public. Day 10 is the DNS pre-warm: TTL drops to 60 seconds, advance notice that any well-behaved resolver respects. Day 11 is the cutover: DNS repoints, the new surface is live, the prior surface is monitored for residual traffic. Days 12 to 14 are the teardown sequence: the prior provider’s surface is stopped (but not yet deleted), the residual-log window begins to elapse, the new surface accumulates the operational data that confirms the migration succeeded.
The actual prior-provider account is closed at day 90 — the end of the residual-log window — at which point the migration is operationally complete. The mail-server IP warming runs in parallel from day 1 to roughly day 35, and the prior provider’s mail flow is the long-running surface that carries the schedule past the nominal day-14 cutover.
The calendar is sketched, not prescriptive. Larger archives need longer; smaller archives need less; archives whose corpus contains time-sensitive material may need to compress the silent-running period at the cost of some operational risk. The discipline that matters is the sequencing, not the specific number of days.
After the cutover
The post-migration surface is verified before it is declared operational. The integrity-hash comparison runs once more against the destination; the application-layer self-tests run; the user-facing journey is exercised by an editor who is not the operator. The chain of custody for the corpus — the documentary evidence that the archive at the new host is byte-identical to the archive at the prior host — is filed alongside the article-side evidence rooms, where applicable, and is the operational counterpart of the editorial-side citation discipline.
The prior provider’s relationship is wound down deliberately. A goodbye message to the support contact (in the operator’s brief register, no editorialising) is recommended; a Friday-night account-closure with no notice produces support tickets that ripple into the prior provider’s logs and is operationally noisier than a clean wind-down. The prior provider’s invoice for the final month is paid; declining to pay produces collections records that connect to the operating identity past the migration’s nominal end-date and are themselves a forensic surface that the migration was supposed to close.
Who this article is for, and who it is not
This article is for an archive that has already decided that an offshore-hosting posture is right for the work and that has the operational discipline to execute a fourteen-day migration plan. It is not for a project that is exploring the question — that project should read the Iceland-versus-Switzerland comparative dossier and the threat-model framing for activist archives first, and then return to this article when the threshold question is settled. The migration is a meaningful operational commitment; doing it well takes more time than doing it badly, and the additional time is not optional.
Questions about the migration mechanics that this article does not answer — the questions that depend on the specific shape of the corpus, the specific adversary profile, the specific publication’s editorial process — are welcome at the operator’s editorial address. The migration runbook above is a generic shape; every actual migration is shaped by the project that runs it. The brief is to make the migration a deliberate act, not a hurried one, and the rest is the work.