O que realmente quebra ao sair da Render

A Render não fez nada de errado. É isso que torna essa migração diferente de uma do Heroku: ninguém está saindo porque o produto é ruim. Estão saindo porque é a infraestrutura da Render, as regiões da Render, e a conta da Render, e as três coisas ficam menos confortáveis conforme uma aplicação realmente cresce.

O que vem de forma limpa

O importador da Railyard lê uma conta da Render direto a partir de um token de API: repositório e branch, variáveis de ambiente, o comando de start, e domínios customizados vêm todos como estão. Background workers na Render se tornam processos worker comuns na Railyard — mesmo trabalho, host diferente.

Se você estiver migrando manualmente em vez de usar o importador, as mesmas coisas mapeiam direto:

O seu Dockerfile, se você tiver um — o mesmo a partir do qual a Render já faz o build.
A intenção de um render.yaml: definições de serviço web e worker se tornam tipos de processo na Railyard, e um preDeployCommand se torna uma tarefa de release que roda antes da nova versão receber tráfego.
Variáveis de ambiente e grupos de ambiente, coladas como estão.
Render Postgres e Render Key Value mapeiam pra addons gerenciados de Postgres e Redis, com as URLs de conexão injetadas do mesmo jeito que a Render injeta hoje.

O que não vem automaticamente

Duas coisas precisam de uma etapa deliberada, não um botão:

Valores de secret file. O importador traz os nomes de qualquer coisa que a Render armazenou como secret file, não o conteúdo — digite esses de novo manualmente, uma vez.
Os dados de fato. Um banco de dados migra fazendo streaming de um pg_dump a partir do DATABASE_URL da Render direto pro novo Postgres gerenciado. Mantenha o banco de dados antigo rodando até o novo responder corretamente, só então mude o DNS — não antes.

A mudança, em ordem

Aponte a Railyard pra um servidor na sua própria conta da DigitalOcean, Hetzner ou AWS — ou conecte um que você já roda.
Adicione o repositório e confirme o método de build que a Render já usa (normalmente o Dockerfile).
Recrie a configuração: cole as env vars, conecte Postgres/Redis pra que as connection strings se configurem automaticamente.
Faça deploy pra URL temporária e de fato exercite a aplicação, jobs em segundo plano inclusos, antes de tocar no DNS.
Transfira os dados por streaming, verifique, e só então mude o DNS. A Render continua servindo o tempo todo — não existe uma janela em que a aplicação fica fora do ar.

O que realmente é diferente depois

A máquina é sua. Sem surpresa de egress por GB no final de um mês bom, sem esperar por uma região que a Render ainda não adicionou, e se você algum dia decidir sair da Railyard também, os containers continuam rodando numa máquina que já é sua — nada sobre a saída depende de nós.

Mapeamento técnico completo: Migrating from Render, a comparação com a Render, e Import from Heroku, Render, Fly or Railway.