[Início](https://servhidden.com/pt) /
[Guias de Hospedagem com Privacidade](https://servhidden.com/pt/guides) /
Como Migrar um Site para Hospedagem Offshore sem Downtime






Operações


# Migre para Hospedagem Offshore sem Downtime



Quase toda migração dolorosa é uma falha de ordem, não uma falha técnica — um TTL baixado na própria noite em vez de dois dias antes, um certificado emitido depois da mudança de DNS em vez de antes, um cron job deixado ativo num servidor que não é mais autoritativo. Esta é a sequência que elimina completamente a janela de downtime, além da parte que os guias genéricos pulam: o que a mudança registra permanentemente sobre você, e o que ainda dá para fazer a respeito.


[Ler o guia](#guide-body)
[Perguntas frequentes](#guide-faq)






## Nesta página




- [Guia](#guide-body)

- [Perguntas frequentes](#guide-faq)

- [Guias relacionados](#guide-related)

- [Páginas recomendadas](#guide-cta)






Sem KYC
Somente Cripto
Sem Logs
DMCA ignorado
Root Completo
NVMe SSD





18 min de leitura
Atualizado em Aug 2026

Nesta página

[01O que "zero downtime" realmente significa](#o-que-zero-downtime-realmente-significa)
[02Baixe o TTL do DNS dias antes de planejar a migração](#baixe-o-ttl-do-dns-dias-antes-de-planejar-a-migração)
[03Faça o inventário do que você está migrando, não do que você lembra](#faça-o-inventário-do-que-você-está-migrando-não-do-que-você-)
[04Construa o novo servidor primeiro, e faça o hardening antes de ele guardar qualquer coisa](#construa-o-novo-servidor-primeiro-e-faça-o-hardening-antes-d)
[05Copie os dados duas vezes: uma passada lenta, depois uma rápida](#copie-os-dados-duas-vezes-uma-passada-lenta-depois-uma-rápid)
[06Teste o novo servidor antes que o DNS saiba que ele existe](#teste-o-novo-servidor-antes-que-o-dns-saiba-que-ele-existe)
[07A virada, em ordem](#a-virada-em-ordem)
[08O que a migração deixa para trás](#o-que-a-migração-deixa-para-trás)
[09A questão do domínio: levar junto, ou começar do zero?](#a-questão-do-domínio-levar-junto-ou-começar-do-zero)
[10Desative o host antigo corretamente](#desative-o-host-antigo-corretamente)
[11A sequência inteira, numa página só](#a-sequência-inteira-numa-página-só)
[FAQPerguntas frequentes](#guide-faq)
[→Páginas recomendadas](#guide-cta)







Ninguém migra um site no ar por entretenimento. Isso acontece porque o host atual de repente quer uma foto do seu passaporte, ou repassa uma reclamação com prazo de 24 horas, ou porque o país onde fica o datacenter deixou de parecer um lugar sensato para manter seus dados. Seja qual for o motivo, a migração em si é a parte perigosa — é o único momento em que o site pode sair do ar, e o único momento em que um passo descuidado pode grudar o novo servidor na identidade que você estava tentando deixar para trás.

Os dois riscos têm a mesma cura, e não é uma ferramenta. É ordem. Uma migração feita na sequência certa não tem nenhuma janela em que o site fica inacessível, porque os dois servidores estão ativos ao mesmo tempo e o DNS é a última coisa a mudar. Uma migração feita na sequência errada produz uma queda e um rastro ao mesmo tempo. O que vem a seguir é essa sequência, escrita para quem está migrando para um host offshore sem KYC, e não trocando entre dois provedores tradicionais — a mecânica é a mesma, mas a limpeza depois não é.

## O que "zero downtime" realmente significa

A expressão é usada de forma solta, e é nessa imprecisão que as pessoas se machucam. Servir HTTP a partir de duas máquinas ao mesmo tempo é fácil. Manter o *estado* consistente enquanto as duas máquinas servem ao mesmo tempo é a parte difícil, e é a única parte que chega a perder dados. Então, antes de planejar qualquer coisa, decida qual desses cenários você está realmente rodando, porque a resposta define o formato da noite inteira.

| O que você está migrando | A parte que realmente morde | Qual deve ser o plano |
| --- | --- | --- |
| Site estático, site institucional, saída gerada | Nada. Não há estado para dividir | Copiar, verificar, virar a chave. Zero downtime de verdade |
| CMS com banco de dados — WordPress, Ghost, um fórum | Comentários, logins e posts caindo em dois bancos ao mesmo tempo | Um congelamento somente leitura medido em **minutos**, no seu horário mais tranquilo |
| Uma loja, ou qualquer coisa que receba pedidos | Um split brain perde pedidos pagos silenciosamente | Assuma a janela de manutenção curta. Sai mais barato que a reconciliação |
| Qualquer coisa com cron jobs ou workers em segundo plano | O mesmo job disparando nos dois servidores — e-mails em dobro, cobranças em dobro | Desative o agendamento no host antigo *antes* de o novo começar |
| E-mail no mesmo domínio | Registros MX expiram dos caches no próprio relógio deles, sem relação com o seu registro A | Migre o e-mail numa noite separada, e mantenha o MX antigo aceitando por uma semana |

Note que só a primeira linha é realmente gratuita. Em todo o resto, "zero downtime" significa "um congelamento de escrita tão curto que ninguém abre um chamado por causa dele". Dois minutos de somente leitura às 4h da manhã são um erro de arredondamento; duas horas de escritas divididas entre dois bancos de dados são um fim de semana de reconciliação. Escolha o congelamento.

Os dois servidores rodam ao mesmo tempo e o DNS é a última coisa a mudar — por isso uma virada bem sequenciada não tem janela nenhuma.

## Baixe o TTL do DNS dias antes de planejar a migração

Este é o único passo com prazo de antecedência, por isso é o primeiro e por isso é o que as pessoas pulam. Seu TTL — time to live — diz a cada resolver na internet por quanto tempo ele pode manter seu registro em cache antes de perguntar de novo. Se o seu registro A tem um TTL de 86400, um resolver que consultou há uma hora vai continuar entregando o IP antigo por mais 23 horas, não importa o que você mude no registrador.

O detalhe crítico é que baixar o TTL está, ele mesmo, sujeito ao TTL antigo. Os resolvers só ficam sabendo do valor novo, menor, quando a cópia antiga em cache expira. Então baixe o TTL para 300 segundos **pelo menos um período inteiro do TTL antigo antes da virada** — com um TTL de um dia, isso significa fazer isso de 24 a 48 horas antes. Aí o mundo converge para o seu novo registro em até cinco minutos após a mudança, e a virada deixa de ser um evento de suspense.

Volte o TTL para algo razoável alguns dias depois da migração. Um TTL de 300 segundos é uma ferramenta ótima e uma configuração permanente ruim: ele multiplica o volume de consultas e transforma seu provedor de DNS num ponto único de falha muito mais afiado.

## Faça o inventário do que você está migrando, não do que você lembra

Toda migração fracassada tem o mesmo post-mortem: algo que ninguém listou não foi copiado. A raiz do site e o banco de dados são as duas coisas que todo mundo lembra; a lista abaixo é o resto, e vale a pena percorrê-la ao pé da letra em vez de confiar na memória.

- **Trabalho agendado.** crontab -l para cada usuário, mais os timers do systemd. Hooks de renovação e jobs noturnos se escondem aqui.

- **Definições de serviço.** Units customizadas do systemd, os vhosts do servidor web, pools do PHP-FPM, qualquer configuração de supervisor.

- **Segredos e ambiente.** Arquivos .env, chaves de API, senhas de banco de dados, salts da aplicação — e vale notar que eles devem ser rotacionados, não apenas copiados.

- **Material TLS.** Certificados e, mais importante, a conta ACME e a configuração de renovação.

- **Identidade de e-mail.** Chaves privadas DKIM, registros SPF e DMARC. Uma incompatibilidade aqui não quebra de forma barulhenta; ela só manda seu e-mail para o spam, silenciosamente.

- **Mídia enviada pelos usuários.** Frequentemente fora da raiz do site, frequentemente a maior coisa que você possui.

- **Tudo externo que confia no seu IP.** Allowlists de gateway de pagamento, destinos de webhook, firewalls de banco de dados, APIs de terceiros com restrição de IP. Essa é a causa número um do "o site funciona mas o checkout está quebrado" às 3h da manhã.

- **A lista de pacotes.** dpkg --get-selections ou o equivalente, para que a máquina nova tenha as mesmas extensões e bibliotecas, e não quase as mesmas.

Anote a lista antes de começar a copiar. O inventário também é o seu plano de testes depois — cada linha dele é algo para verificar no novo servidor antes que o DNS saiba que ele existe.

## Construa o novo servidor primeiro, e faça o hardening antes de ele guardar qualquer coisa

Contrate o destino com antecedência e deixe-o rodando vazio por um dia ou dois. Não há custo nenhum nessa sobreposição — um VPS offshore pequeno custa alguns dólares por mês — e há um grande valor em não fazer a construção sob pressão de tempo, com um banco de dados congelado esperando.

Combine com o ambiente antigo deliberadamente: a mesma distribuição e versão principal, a mesma versão principal do PHP, Node ou Python, a mesma versão principal do banco de dados. A tentação de modernizar tudo enquanto você está lá dentro é enorme e deve ser resistida por completo. Se o site quebrar depois da virada, você quer que exatamente uma variável tenha mudado. Atualize a stack duas semanas depois, numa tarde tediosa, com a capacidade de reverter.

Faça o hardening dele enquanto ainda está vazio. SSH somente com chaves, um firewall padrão-negar, atualizações de segurança automáticas — o [checklist de hardening da primeira hora](https://servhidden.com/pt/guides/first-hour-vps-hardening-checklist) é exatamente essa lista, e é muito mais fácil de aplicar numa máquina sem nada rodando nela. Se o dado for sensível o bastante para você estar mudando de jurisdição por causa dele, este também é o momento certo para decidir sobre [criptografia em repouso](https://servhidden.com/pt/guides/full-disk-encryption-on-a-vps), porque aplicar isso depois significa outra migração.

## Copie os dados duas vezes: uma passada lenta, depois uma rápida

O instinto é copiar tudo durante a janela de manutenção. Faça o oposto. Rode uma cópia completa dias antes, enquanto o site antigo ainda está servindo tráfego tranquilamente, depois rode uma segunda passada na virada que só move o que mudou. A primeira passada pode levar seis horas e ninguém percebe. A segunda leva 90 segundos, e esse é todo o seu orçamento de downtime.

Para arquivos, rsync -aHAX --numeric-ids preserva permissões, propriedade, hard links e atributos estendidos; a flag --numeric-ids importa porque os UIDs raramente coincidem entre duas máquinas recém-criadas. Rode uma vez com antecedência, depois de novo imediatamente antes da virada com os mesmos argumentos — a segunda execução transfere só o delta.

Bancos de dados precisam do mesmo tratamento em duas fases, mas com ferramentas diferentes. Um mysqldump --single-transaction ou pg_dump te dá um snapshot antecipado consistente para construir e testar. Na virada, ou você tira um segundo dump durante o seu breve congelamento de escrita, ou — para um banco de dados grande, onde até um congelamento curto dói — configura o novo servidor como réplica do antigo com dias de antecedência, deixa ele alcançar o estado atual, e então o promove. Replicação transforma o congelamento em segundos. Também transforma uma migração de duas horas num projeto de dois dias, então use isso só quando o tamanho realmente exigir.

**Pull, não push, e nunca pelo seu laptop.** Inicie a cópia a partir do novo servidor, para que a transferência rode de host a host na velocidade do datacenter. Rotear gigabytes pela sua conexão doméstica é lento, e coloca o seu IP residencial nos logs de acesso das duas máquinas — que é precisamente o vínculo que uma migração motivada por privacidade existe para evitar. Se até o host antigo descobrir o seu novo IP for inaceitável, não copie diretamente de jeito nenhum: em vez disso, restaure o novo servidor a partir do seu próprio [backup externo criptografado](https://servhidden.com/pt/guides/vps-backup-strategy), e as duas máquinas nunca chegam a se falar.

## Teste o novo servidor antes que o DNS saiba que ele existe

Você pode servir o hostname real a partir do novo IP sem mudar um único registro público, e deveria fazer isso — é isso que torna a virada tranquila. Adicione uma linha ao seu /etc/hosts local apontando o domínio para o novo IP, ou pule isso e deixe o curl fazer isso para uma única requisição:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Agora percorra o inventário. Carregue a página inicial e três páginas internas. Faça login. Envie um formulário. Suba um arquivo. Confira se a conexão com o banco de dados é a nova, local, e não ainda apontando para o host antigo pela internet — um erro que funciona perfeitamente até o momento em que você cancela o servidor antigo. Rode os cron jobs manualmente e leia a saída deles. Verifique os redirecionamentos e que uma URL inexistente ainda retorna 404 em vez de 200.

Emita o certificado TLS agora, antes da virada, não depois. Use um desafio DNS-01, que prova o controle do domínio por meio de um registro TXT e por isso funciona enquanto o registro A ainda aponta para o servidor antigo. Se você esperar a validação HTTP-01 depois da mudança de DNS, todo visitante inicial recebe um aviso de certificado durante essa lacuna — uma queda autoinfligida bem na janela que você estava tentando proteger.

## A virada, em ordem

Neste ponto, o novo servidor já está construído, com o hardening feito, populado, testado sob o hostname real e com um certificado válido. A virada em si agora é uma lista curta e tediosa, que é exatamente o objetivo.

- Avise sobre a janela se mais alguém depende do site, depois coloque o site antigo em modo somente leitura ou manutenção.

- **Desative o cron e os workers em segundo plano no host antigo.** Faça isso antes de iniciá-los no novo, nunca depois.

- Rode a passada final de delta do rsync e o dump final do banco de dados, e importe-o.

- Inicie a aplicação no novo servidor e rode de novo seus smoke tests via --resolve, contra os dados finais.

- Mude os registros A e AAAA para o novo IP. Com um TTL de 300 segundos, o mundo acompanha em até cinco minutos.

- Ative o cron e os workers no host novo.

- Observe os dois logs de acesso lado a lado. O tráfego escoa do servidor antigo e aparece no novo; quando o antigo fica quieto, a virada está completa.

- Deixe o servidor antigo rodando, servindo, e intocado por uma semana. Ele é o seu rollback.

O passo oito é o que as pessoas cortam, e é o seguro mais barato da lista. Pelo preço de alguns dólares você mantém a capacidade de apontar o DNS de volta — uma recuperação de cinco minutos — pelo tempo que for preciso até ter certeza.

## O que a migração deixa para trás

Aqui está a parte que os guias genéricos de migração omitem, e a parte que mais importa se você migrou por privacidade em vez de preço. Migrar um site não apaga a sua história. Vários registros públicos e semipúblicos do arranjo antigo sobrevivem à migração permanentemente, e saber quais são eles é a diferença entre um corte limpo e uma falsa sensação de um.

| O que registra a migração | Quem consegue ler isso | O que você realmente pode fazer |
| --- | --- | --- |
| DNS passivo — registros A históricos | Qualquer pessoa, por meio de serviços comerciais de histórico | **Nada.** O IP antigo fica associado ao nome permanentemente. Planeje como se fosse público, porque é |
| Logs de Certificate Transparency | Qualquer pessoa, permanentemente, pesquisável por domínio | Todo certificado já emitido é listado — incluindo os subdomínios de nome interno que você esqueceu. Prefira um wildcard a nomes descritivos |
| Os registros de conta do host antigo | O host antigo, e qualquer um que possa obrigá-lo | Dados do cartão, e-mail de cadastro, IPs de login. Um destino sem KYC protege o futuro, não o passado |
| Histórico de WHOIS | Arquivos comerciais de histórico de WHOIS | Se o domínio já foi registrado com dados reais, aquele retrato foi capturado. Privacidade aplicada depois não o desfaz |
| Identificadores de analytics e anúncios | O fornecedor, e qualquer um que leia o código-fonte da sua página | Carregar o mesmo ID de rastreamento liga os dois sites de forma conclusiva. Emita um novo, ou remova-o |
| Dumps e backups deixados no disco antigo | Quem quer que receba aquele armazenamento em seguida | Apague e sobrescreva antes de cancelar. Em armazenamento compartilhado, assuma que a exclusão é uma sugestão, não uma garantia |
| Cabeçalhos Received: no e-mail enviado | Todo destinatário, para sempre | Nada retroativo. Só o e-mail que você enviar depois da migração carrega o novo caminho |
| Suas próprias conexões durante a cópia | Seu provedor de internet, e os logs de acesso dos dois hosts | Esse aqui está inteiramente sob seu controle. Nunca acesse nenhuma das máquinas a partir de um IP que te identifique |

O resumo honesto é que uma migração não consegue reescrever o passado — ela só pode parar de adicionar coisas a ele. Isso ainda vale muito, mas muda a decisão: se o seu modelo de ameaça exige que nenhum observador consiga ligar o site novo ao antigo, migrar o mesmo domínio para um host novo não resolve isso, e nenhum cuidado durante a virada vai resolver. Esse caso precisa de um nome novo e um recomeço limpo, discutido a seguir. Se o seu objetivo é, em vez disso, parar de gerar registros identificáveis a partir de hoje, e mover o centro de gravidade legal para uma jurisdição que você escolheu, a migração faz exatamente isso. Nosso [guia de OpSec de servidor](https://servhidden.com/pt/guides/server-opsec-staying-anonymous) cobre os hábitos que mantêm isso limpo depois.

## A questão do domínio: levar junto, ou começar do zero?

O site e o domínio são decisões independentes, e confundir as duas é comum. Você pode migrar a hospedagem hoje e nunca mais mexer no registrador; nada na troca de servidor exige tocar no domínio. Se você *deveria* fazer isso depende inteiramente do que o domínio já sabe sobre você.

- **Mantenha o domínio, troque o registrador.** Sensato quando o domínio tem valor — links, rankings, um nome que as pessoas digitam. Isso resolve o futuro do registro WHOIS, não o seu histórico, e mantém todo sinal de ranking intacto. Essa é a resposta certa para a maioria dos sites comerciais.

- **Mantenha o domínio, não mude nada além do host.** Perfeitamente razoável quando você migrou por jurisdição, uptime ou postura de DMCA, e não por anonimato. A migração mais simples possível, com risco zero de SEO.

- **Domínio novo, redirecionando o antigo.** Preserva os rankings, e liga os dois nomes pública e permanentemente. Escolha essa opção por continuidade, nunca por privacidade — o redirecionamento é o vínculo.

- **Domínio novo, corte limpo.** A única opção que realmente rompe a associação, e custa todo ranking e link de entrada que você tinha. Registre-o de forma privada desde o início, porque um domínio só é tão anônimo quanto o seu primeiro registro. Nosso guia de [registro anônimo de domínio com cripto](https://servhidden.com/pt/guides/anonymous-domain-registration-with-crypto) cobre como fazer isso direito.

Escolha deliberadamente, e escolha antes da virada, não durante ela. Mudar de ideia sobre o domínio depois que o DNS já migrou significa fazer a parte delicada duas vezes.

## Desative o host antigo corretamente

Uma semana ou duas depois da virada, quando os logs do novo servidor estiverem tediosos e os do antigo estiverem vazios, é hora de fechar a conta antiga. Faça isso nesta ordem, porque o atalho tentador — clicar em cancelar — é o que deixa seus dados no disco de outra pessoa.

- Confirme que nada mais aponta para o IP antigo: verifique endereços fixos em webhooks de terceiros, allowlists, monitoramento, e qualquer registro de DNS que você tenha esquecido, como um subdomínio perdido mail ou cpanel.

- Rotacione todo segredo que já viveu naquela máquina — senhas de banco de dados, chaves de API, salts da aplicação, chaves DKIM, chaves SSH. Não as copie para a frente.

- Remova suas chaves públicas SSH e qualquer acesso de suporte do servidor antigo.

- Apague a aplicação, os dumps e os backups, depois sobrescreva o espaço livre para que uma leitura casual do volume reciclado não retorne nada.

- Só então encerre o serviço, e remova qualquer forma de pagamento salva da conta antiga.

**Qualquer coisa que viveu num hardware que você não controla mais está comprometida por definição.** Não porque o seu host antigo seja malicioso, mas porque aquele disco vai voltar para um pool e você nunca vai saber o que sobreviveu à limpeza. Rotacionar uma senha de banco de dados leva dois minutos. Descobrir meses depois que uma chave de um servidor desativado ainda abre alguma coisa leva consideravelmente mais tempo.

## A sequência inteira, numa página só

Tirando o raciocínio, uma migração de host são nove passos, dos quais só dois têm alguma urgência:

- **Dois dias antes:** baixe o TTL do DNS para 300 segundos.

- **Dois dias antes:** contrate e faça o hardening do servidor de destino, casando a versão da stack antiga, versão por versão.

- **Dias antes:** escreva o inventário — cron, segredos, TLS, chaves de e-mail, mídia, allowlists de IP, pacotes.

- **Dias antes:** rode a primeira cópia completa dos dados, de host a host.

- **Antes da janela:** emita o certificado via DNS-01 e teste tudo através do --resolve.

- **A janela (minutos):** congele as escritas, desative o cron antigo, rode a cópia delta e o dump final, inicie a nova aplicação.

- **A janela (segundos):** mude o registro A, depois ative o cron no host novo.

- **Na semana seguinte:** mantenha o servidor antigo vivo como rollback, observe os dois arquivos de log, depois suba o TTL de novo.

- **Depois:** rotacione segredos, apague, cancele — e lembre do que a migração não conseguiu apagar.

Nada nessa lista é difícil. Todo passo que dói é um passo feito fora de ordem — um TTL baixado na própria noite, um certificado emitido depois da mudança de DNS, um cron job deixado ativo numa máquina que não é mais autoritativa. Acerte a sequência e a parte interessante de uma migração passa a ser escolher onde colocar o servidor, não a migração em si. Se você ainda não decidiu isso, o [guia de jurisdições](https://servhidden.com/pt/guides/choosing-an-offshore-jurisdiction) é o lugar para começar.





Perguntas frequentes

## Migração de host — perguntas frequentes





### 01
Quanto downtime eu devo realmente esperar?



Para um site estático, nenhum — os dois servidores podem servir o mesmo conteúdo simultaneamente, então a mudança de DNS é invisível. Para qualquer coisa com banco de dados, o seu downtime é exatamente a duração do seu congelamento de escrita, que costuma ser de dois a 10 minutos se você já rodou uma cópia completa dos dados com antecedência. O número que importa não é a velocidade com que o DNS muda; é quanto você copia durante a janela. Copie quase tudo dias antes e a janela encolhe para o tamanho do delta.





### 02
Quanto tempo leva a propagação do DNS?



Não existe propagação — essa palavra descreve algo que não acontece. Os resolvers simplesmente mantêm seu registro em cache pelo tempo que o TTL mandou, e perguntam de novo quando ele expira. Se o TTL em vigor era 86400, alguns resolvers vão continuar servindo o IP antigo por mais 24 horas. Baixe o TTL para 300 segundos pelo menos um período inteiro do TTL antigo antes da virada, e a internet inteira acompanha a sua mudança em até cinco minutos.





### 03
Eu também preciso migrar meu domínio?



Não. O registrador e o host são completamente independentes, e migrar o site deixando o domínio exatamente onde está funciona perfeitamente. Se você deveria migrá-lo também depende do seu motivo para migrar: se foi jurisdição, preço ou postura de DMCA, deixe o domínio como está. Se foi anonimato, note que o domínio carrega sua própria história separada — os arquivos de WHOIS guardam quaisquer dados com que ele foi registrado pela primeira vez, e mudanças de hospedagem não tocam nisso.





### 04
Consigo migrar sem que o host antigo descubra para onde eu fui?



Não, se você copiar diretamente entre as duas máquinas — uma ponta se conecta à outra, e os dois conjuntos de logs de acesso registram isso. Se esse vínculo realmente importa para o seu modelo de ameaça, não copie de host a host de jeito nenhum: restaure o novo servidor a partir do seu próprio backup externo criptografado, para que os dois provedores nunca troquem um pacote sequer. De qualquer forma, nunca inicie a transferência a partir de uma conexão que te identifique, e mantenha o destino fora de qualquer chamado de suporte que você abrir com o provedor antigo.





### 05
Devo atualizar o SO ou a stack ao mesmo tempo?



Não, e essa é a falha de migração autoinfligida mais comum. Mude uma coisa de cada vez. Se o site se comportar mal depois da virada, você quer uma única explicação candidata, não uma escolha entre a máquina nova, a nova versão do PHP e a nova versão principal do banco de dados. Combine com o ambiente antigo versão por versão, complete a migração, confirme uma semana de logs limpos, e só depois atualize separadamente, com a capacidade de reverter.





### 06
Migrar vai prejudicar meu ranking de busca?



Não de forma significativa, desde que o domínio, as URLs e o conteúdo permaneçam os mesmos — o Google indexa URLs, não endereços IP, e uma troca de host, por si só, não é um sinal de ranking. Mantenha a estrutura de URL idêntica, retorne os mesmos códigos de status, e não combine a migração com um redesign ou uma mudança no esquema de URLs. Se você estiver migrando para um domínio novo, espere uma queda temporária mesmo com redirecionamentos 301 corretos, e entenda que esses redirecionamentos também ligam os dois nomes publicamente.





### 07
Eu preciso reemitir os certificados TLS?



Sim — o novo servidor precisa do próprio certificado e chave privada, e copiar a chave antiga para a frente é um mau hábito, mesmo quando tecnicamente funciona. Emita-o antes da virada usando um desafio DNS-01, que valida por meio de um registro TXT e por isso funciona enquanto o registro A ainda aponta para o host antigo. Esperar pelo HTTP-01 depois da mudança de DNS garante um período de avisos de certificado bem na janela que você estava tentando proteger.





### 08
Quando é seguro cancelar o servidor antigo?



Depois de uma semana ou duas de logs quietos na máquina antiga e logs limpos na nova — essa espera é o seu rollback, e custa alguns dólares. Antes de cancelar, confira se nada externo ainda aponta para o IP antigo, rotacione todo segredo que já viveu nele, depois apague seus dados e sobrescreva o espaço livre. Cancele por último. Encerrar o serviço primeiro deixa o seu banco de dados num disco que você não controla mais.




Guias relacionados

## Continue lendo


[### Como Escolher uma Jurisdição de Hospedagem Offshore em 2026

Compra


Um framework de decisão prático para escolher uma jurisdição offshore: lei de retenção de dados, exposição a MLAT, postura sobre DMCA, velocidade dos tribunais e aplicação real — país a país.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Servidor Dedicado para Cargas de Trabalho com Privacidade Crítica

Compra


Quando um VPS é suficiente, quando a multilocação é um risco, e quando o bare metal é a única resposta honesta. Isolamento de hardware, risco de hypervisor e custo vs modelo de ameaça.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/vps-vs-dedicated-for-privacy)
[### VPN Auto-Hospedada em VPS Sem KYC: WireGuard vs OpenVPN

Operações


Por que uma VPN auto-hospedada supera os provedores comerciais e como WireGuard e OpenVPN realmente se comparam em privacidade, desempenho e risco operacional em 2026.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 para Inferência de IA (e Onde o RTX 5090 se Encaixa)

Compra


Guia de decisão de compra: qual GPU NVIDIA para LLM auto-hospedado, imagem, vídeo, voz e cargas de trabalho de ajuste fino em 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs H100 duplo — VRAM, throughput, $/token, quando cada um vence.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore para Trading Forex com MT4 / MT5 / cTrader

Operações


Guia completo: por que um RDP Windows para trading forex, como escolher uma jurisdição offshore de baixa latência, configuração de MT4 / MT5 / cTrader / Expert Advisor, latência para servidores de corretora e o caminho de checkout sem KYC.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/offshore-windows-rdp-for-forex-trading)
[### Hospedagem DMCA-Ignorada Explicada: O Que Realmente Significa em 2026

Compra


O que a hospedagem "DMCA ignorado" realmente oferece, quais jurisdições de fato a sustentam, os tipos de carga que a necessitam, e as armadilhas de direitos autorais que o termo não cobre.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/dmca-ignored-hosting-explained)
[### Registro Anônimo de Domínio com Cripto: Privacidade WHOIS em 2026

Privacidade


Um guia prático para 2026 sobre como registrar domínios sem revelar sua identidade: regimes WHOIS por TLD, escolha de registrador, opções de pagamento em cripto e os erros operacionais que ainda assim vão te expor.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/anonymous-domain-registration-with-crypto)
[### Pagamentos Cripto para Hospedagem: Monero vs Bitcoin vs USDT

Privacidade


Como a escolha da moeda afeta o que seu host aprende sobre você. Privacidade, taxas, finalidade e exposição à análise de blockchain para XMR, BTC e USDT — com uma recomendação clara.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Hospedagem offshore é realmente anônima? Uma resposta honesta

Privacidade


Hospedagem offshore sem KYC remove a identidade que um provedor comum coleta — mas "anônimo" depende do pagamento, dos logs do provedor e da sua própria segurança operacional. Veja o que é realmente rastreável.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/is-offshore-hosting-truly-anonymous)
[### A primeira hora de hardening do VPS: um checklist

Operações


Um checklist concreto e ordenado para proteger um VPS novo em menos de uma hora: chaves SSH, firewall, fail2ban, atualizações automáticas e a redução da superfície de ataque que barra a maioria dos ataques oportunistas.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/first-hour-vps-hardening-checklist)
[### O Que É Hospedagem Sem KYC? Definição, Legalidade e Como Funciona

Privacidade


A hospedagem sem KYC permite alugar um servidor sem nenhuma verificação de identidade — sem nome, sem e-mail, sem documento. Aqui está exatamente o que isso significa, como funciona tecnicamente, se é legal e como escolher um provedor de verdade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/what-is-no-kyc-hosting)
[### Hospedagem Offshore É Legal? A Resposta Honesta para 2026

Compra


Hospedagem offshore é legal — para você e para o provedor. Aqui está o que o termo realmente significa, onde a linha legal de fato se situa, os mitos que vale descartar, e como utilizá-la de forma responsável.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/is-offshore-hosting-legal)
[### Como Pagar por Hospedagem com Monero (XMR) — Passo a Passo

Privacidade


Um guia passo a passo para pagar por um VPS ou servidor dedicado com Monero (XMR): por que o XMR é a opção mais privada, como obtê-lo e como funciona o processo de pagamento — da fatura ao servidor em funcionamento em minutos.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-pay-for-hosting-with-monero)
[### Como Hospedar um Site de Forma Anônima — Guia Prático 2026

Privacidade


Um guia prático e em camadas para hospedar um site sem nenhuma identidade vinculada: a conta, o pagamento, o domínio, a jurisdição, a sua conexão e o conteúdo — cada camada explicada.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-host-a-website-anonymously)
[### Como Configurar uma VPN WireGuard em um VPS — Guia Passo a Passo

Operações


Monte sua própria VPN privada em um VPS com WireGuard: por que uma VPN auto-hospedada supera as comerciais, o processo completo desde a instalação até o primeiro cliente conectado, e como reforçar a segurança.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Como Hospedar um LLM em um Servidor GPU — Guia 2026

Operações


Execute seu próprio modelo de linguagem em um servidor GPU alugado: por que hospedar seu próprio LLM supera uma API, qual GPU e modelo escolher, a configuração com Ollama ou vLLM, e quanto custa.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/self-host-an-llm-on-a-gpu-server)
[### Hospedagem Bulletproof vs Hospedagem Offshore — Qual é a Diferença?

Compra


Hospedagem bulletproof e hospedagem offshore são constantemente confundidas — e não são a mesma coisa. Veja a diferença real, por que isso importa e qual das duas você realmente precisa.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/bulletproof-vs-offshore-hosting)
[### Como Comprar um VPS com Bitcoin — Passo a Passo (2026)

Compra


Um guia completo para iniciantes sobre como comprar um VPS com Bitcoin: como obter BTC, escolher um plano, pagar a fatura e o que você recebe — um servidor funcionando sem cartão e sem nome associado.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-buy-a-vps-with-bitcoin)
[### Melhores Países para Hospedagem com DMCA Ignorado em 2026

Compra


Onde hospedar quando você quer servidores além do alcance fácil das remoções ao estilo americano: as jurisdições que funcionam, o que DMCA ignorado realmente significa e como escolher.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/best-countries-for-dmca-ignored-hosting)
[### Como Hospedar um Serviço Oculto Tor (Site .onion) — Guia 2026

Operações


Configure um serviço onion Tor em um VPS: o que é um serviço oculto, por que é a forma mais robusta de hospedagem anônima, o processo completo de configuração e como mantê-lo verdadeiramente anônimo.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-host-a-tor-hidden-service)
[### Configuração de Servidor de E-mail Offshore — Hospede Seu Próprio E-mail Privado em 2026

Operações


Execute seu próprio servidor de e-mail privado em um VPS offshore: por que hospedar e-mail você mesmo, o que é necessário, a configuração prática com uma stack de e-mail completa e como garantir a entregabilidade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/offshore-mail-server-setup)
[### Guia de Hospedagem de Nó de Criptomoeda — Execute um Nó Blockchain em um VPS

Operações


Como hospedar um nó blockchain em um servidor: por que executar seu próprio nó, dimensionamento do servidor para Bitcoin, Ethereum, Monero e outros, a configuração e como manter a privacidade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/crypto-node-hosting-guide)
[### Hospedagem GPU para Stable Diffusion — Rode Seu Próprio Servidor de Imagens

Operações


Rode o Stable Diffusion no seu próprio servidor GPU: por que hospedar geração de imagens localmente, qual GPU escolher, como configurar com uma interface web e quanto custa em comparação a um serviço hospedado.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/gpu-hosting-for-stable-diffusion)
[### OpSec para Servidores — Como Manter o Anonimato ao Operar um Servidor

Privacidade


Segurança operacional para quem administra um servidor anônimo: os erros que expõem identidades, os hábitos que os previnem e como manter identidades verdadeiramente separadas.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/server-opsec-staying-anonymous)
[### Guia de Configuração de Seedbox — Monte Sua Própria Seedbox Privada em 2026

Operações


Como montar sua própria seedbox em um servidor: o que é uma seedbox, como dimensioná-la, instalar um cliente torrent com interface web e mantê-la privada e segura.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/seedbox-setup-guide)
[### Como Contornar a Censura por DPI com Seu Próprio VPS (Guia 2026)

Privacidade


Sua VPN parou de funcionar? Como contornar a censura por DPI com seu próprio VPS: o que a inspeção profunda de pacotes realmente detecta, qual dos cinco protocolos de 2026 vence qual tipo de bloqueio, e um passo a passo completo de VLESS+REALITY.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/bypass-dpi-censorship-with-your-own-vps)
[### Criptografia de Disco Completo em um VPS: LUKS e o Que Ela Protege

Operações


Como criptografar um VPS com LUKS: volumes de dados, raiz completa com desbloqueio via SSH, as configurações que importam em um servidor pequeno, e o que a criptografia de disco realmente impede.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/full-disk-encryption-on-a-vps)
[### Ocultar o IP do Servidor de Origem: CDNs, Proxies Reversos e o Que Ainda Vaza

Privacidade


Colocar ou não um CDN na frente de um servidor offshore: o que ele esconde, a central de reclamações que você herda, as seis formas como o IP de origem vaza, e como auditar o seu.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/hiding-your-origin-server-ip)
[### Backup de VPS: Criptografado, Externo e Restaurável de Verdade

Operações


Sua hospedagem não guarda backup. O que realmente destrói servidores, por que backup via push morre junto com a origem, restic vs Borg, e como testar um restore.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/vps-backup-strategy)
[### Hospedar Servidor Matrix Próprio: Federação e Metadados

Operações


O que um servidor Matrix próprio realmente muda: Synapse ou Conduit, o server_name que você nunca poderá trocar, e a mídia que lota o disco rapidamente.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/self-host-a-matrix-server)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operações


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.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/self-host-a-crypto-payment-gateway)




## Dê à migração um lugar para pousar



Servidores KVM offshore em sete jurisdições a partir de $7.50/mês, com root completo, armazenamento NVMe e banda ilimitada, implantados em menos de cinco minutos assim que o pagamento em cripto é confirmado. Suba o destino com antecedência, copie no seu próprio ritmo, e faça a virada quando estiver pronto.


[Ver Planos VPS](https://servhidden.com/pt/vps)
[Hospedagem offshore](https://servhidden.com/pt/offshore-hosting)
[Todas as localizações](https://servhidden.com/pt/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS e servidores dedicados offshore em 7 jurisdições privacy-friendly. Sem KYC, sem logs, apenas cripto. Privacidade por arquitetura.",
    "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": "Como Migrar um Site para Hospedagem Offshore sem Downtime",
    "description": "A ordem que torna a migração de host tediosa: baixar o TTL do DNS dias antes, rodar os dois servidores em paralelo, congelar as escritas por minutos em vez de horas — e limpar o rastro de DNS passivo, Certificate Transparency e WHOIS que a mudança deixa para trás.",
    "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": "pt",
    "keywords": "migrar site para hospedagem offshore, trocar de provedor de hospedagem sem downtime, migração de servidor com zero downtime, migrar um VPS para outro host, TTL do DNS na migração, migrar para um host sem KYC, checklist de migração de site, migração de servidor com rsync",
    "articleSection": "Operações",
    "wordCount": 3497
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Quanto downtime eu devo realmente esperar?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Para um site estático, nenhum — os dois servidores podem servir o mesmo conteúdo simultaneamente, então a mudança de DNS é invisível. Para qualquer coisa com banco de dados, o seu downtime é exatamente a duração do seu congelamento de escrita, que costuma ser de dois a 10 minutos se você já rodou uma cópia completa dos dados com antecedência. O número que importa não é a velocidade com que o DNS muda; é quanto você copia durante a janela. Copie quase tudo dias antes e a janela encolhe para o tamanho do delta."
            }
        },
        {
            "@type": "Question",
            "name": "Quanto tempo leva a propagação do DNS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não existe propagação — essa palavra descreve algo que não acontece. Os resolvers simplesmente mantêm seu registro em cache pelo tempo que o TTL mandou, e perguntam de novo quando ele expira. Se o TTL em vigor era 86400, alguns resolvers vão continuar servindo o IP antigo por mais 24 horas. Baixe o TTL para 300 segundos pelo menos um período inteiro do TTL antigo antes da virada, e a internet inteira acompanha a sua mudança em até cinco minutos."
            }
        },
        {
            "@type": "Question",
            "name": "Eu também preciso migrar meu domínio?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não. O registrador e o host são completamente independentes, e migrar o site deixando o domínio exatamente onde está funciona perfeitamente. Se você deveria migrá-lo também depende do seu motivo para migrar: se foi jurisdição, preço ou postura de DMCA, deixe o domínio como está. Se foi anonimato, note que o domínio carrega sua própria história separada — os arquivos de WHOIS guardam quaisquer dados com que ele foi registrado pela primeira vez, e mudanças de hospedagem não tocam nisso."
            }
        },
        {
            "@type": "Question",
            "name": "Consigo migrar sem que o host antigo descubra para onde eu fui?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não, se você copiar diretamente entre as duas máquinas — uma ponta se conecta à outra, e os dois conjuntos de logs de acesso registram isso. Se esse vínculo realmente importa para o seu modelo de ameaça, não copie de host a host de jeito nenhum: restaure o novo servidor a partir do seu próprio backup externo criptografado, para que os dois provedores nunca troquem um pacote sequer. De qualquer forma, nunca inicie a transferência a partir de uma conexão que te identifique, e mantenha o destino fora de qualquer chamado de suporte que você abrir com o provedor antigo."
            }
        },
        {
            "@type": "Question",
            "name": "Devo atualizar o SO ou a stack ao mesmo tempo?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não, e essa é a falha de migração autoinfligida mais comum. Mude uma coisa de cada vez. Se o site se comportar mal depois da virada, você quer uma única explicação candidata, não uma escolha entre a máquina nova, a nova versão do PHP e a nova versão principal do banco de dados. Combine com o ambiente antigo versão por versão, complete a migração, confirme uma semana de logs limpos, e só depois atualize separadamente, com a capacidade de reverter."
            }
        },
        {
            "@type": "Question",
            "name": "Migrar vai prejudicar meu ranking de busca?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não de forma significativa, desde que o domínio, as URLs e o conteúdo permaneçam os mesmos — o Google indexa URLs, não endereços IP, e uma troca de host, por si só, não é um sinal de ranking. Mantenha a estrutura de URL idêntica, retorne os mesmos códigos de status, e não combine a migração com um redesign ou uma mudança no esquema de URLs. Se você estiver migrando para um domínio novo, espere uma queda temporária mesmo com redirecionamentos 301 corretos, e entenda que esses redirecionamentos também ligam os dois nomes publicamente."
            }
        },
        {
            "@type": "Question",
            "name": "Eu preciso reemitir os certificados TLS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Sim — o novo servidor precisa do próprio certificado e chave privada, e copiar a chave antiga para a frente é um mau hábito, mesmo quando tecnicamente funciona. Emita-o antes da virada usando um desafio DNS-01, que valida por meio de um registro TXT e por isso funciona enquanto o registro A ainda aponta para o host antigo. Esperar pelo HTTP-01 depois da mudança de DNS garante um período de avisos de certificado bem na janela que você estava tentando proteger."
            }
        },
        {
            "@type": "Question",
            "name": "Quando é seguro cancelar o servidor antigo?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Depois de uma semana ou duas de logs quietos na máquina antiga e logs limpos na nova — essa espera é o seu rollback, e custa alguns dólares. Antes de cancelar, confira se nada externo ainda aponta para o IP antigo, rotacione todo segredo que já viveu nele, depois apague seus dados e sobrescreva o espaço livre. Cancele por último. Encerrar o serviço primeiro deixa o seu banco de dados num disco que você não controla mais."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Início",
            "item": "https://servhidden.com/pt/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guias de Hospedagem com Privacidade",
            "item": "https://servhidden.com/pt/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Como Migrar um Site para Hospedagem Offshore sem Downtime",
            "item": "https://servhidden.com/pt/guides/migrate-website-to-offshore-hosting"
        }
    ]
}
```