Lo que de verdad se rompe al migrar desde Render

Render no hizo nada mal. Eso es lo que hace que esta migración sea distinta a una desde Heroku: nadie se va porque el producto sea malo. Se van porque es la infraestructura de Render, las regiones de Render y la factura de Render, y las tres cosas se vuelven cada vez menos cómodas cuanto más crece realmente una app.

Lo que se transfiere limpio

El importador de Railyard lee una cuenta de Render directamente desde un token de API: repositorio y rama, variables de entorno, el comando de arranque y los dominios personalizados pasan todos tal cual. Los workers en segundo plano de Render se convierten en procesos de worker normales en Railyard: el mismo trabajo, distinto host.

Si estás migrando a mano en vez de usar el importador, lo mismo se mapea directo:

Tu Dockerfile, si tienes uno —el mismo desde el que ya construye Render.
La intención de un render.yaml: las definiciones de servicios web y worker se vuelven tipos de proceso de Railyard, y un preDeployCommand se vuelve una tarea de release que corre antes de que la nueva versión reciba tráfico.
Variables de entorno y grupos de entorno, pegadas tal cual.
Render Postgres y Render Key Value se mapean a los complementos administrados de Postgres y Redis, con las URLs de conexión inyectadas de la misma forma en que Render las inyecta hoy.

Lo que no se transfiere solo

Dos cosas necesitan un paso deliberado, no un simple interruptor:

Los valores de los archivos secretos. El importador trae los nombres de lo que Render guardó como archivo secreto, no el contenido —hay que volver a ingresarlos a mano una vez.
Los datos en sí. Una base de datos migra transmitiendo un pg_dump desde el DATABASE_URL de Render directo al nuevo Postgres administrado. Mantén la base de datos vieja corriendo hasta que la nueva responda bien, y recién ahí mueve el DNS, no antes.

El movimiento, en orden

Apunta Railyard a un servidor en tu propia cuenta de DigitalOcean, Hetzner o AWS —o conecta uno que ya tengas corriendo.
Agrega el repositorio y confirma el método de build que Render ya usa (casi siempre el Dockerfile).
Recrea la configuración: pega las variables de entorno, conecta Postgres/Redis para que las cadenas de conexión se conecten solas.
Despliega a la URL temporal y de verdad pon a prueba la app, jobs en segundo plano incluidos, antes de tocar el DNS.
Transmite los datos, verifícalos, y recién entonces redirige el DNS. Render sigue sirviendo todo el tiempo —no hay ninguna ventana en la que la app esté caída.

Lo que de verdad cambia después

La máquina es tuya. Sin sorpresas de egress por GB al final de un buen mes, sin esperar una región que Render todavía no agregó, y si alguna vez decides dejar Railyard también, los contenedores siguen corriendo en una máquina que ya posees: nada de la salida depende de nosotros.

Mapeo técnico completo: Migrar desde Render, la comparación con Render, e Importar desde Heroku, Render, Fly o Railway.