El cierre de Deno Deploy obliga a una startup a tomar dos decisiones distintas: dónde se ejecutará su aplicación y quién mantendrá su entorno de ejecución. Deno ha anunciado seis meses más de funcionamiento de Deploy y otro año de versiones mensuales del entorno de ejecución con correcciones de errores y de seguridad. Antes de trasladar el tráfico de producción, comprueba que la alternativa conserva el comportamiento del que dependen tus clientes. El [anuncio de Deno del 9 de octubre](https://deno.com/blog/cloudflare) establece esos dos periodos.

Que la página de inicio cargue en Workers es un primer paso útil. No demuestra que una sesión siga siendo privada, que una escritura concurrente siga siendo correcta ni que puedas deshacer un cambio de plataforma fallido. Esas pruebas deben determinar si la migración está lista.

Este artículo propone un marco de aceptación para responsables de ingeniería cuya aplicación ya depende de Deno. Los ejemplos son pruebas propuestas, no migraciones de clientes cuyos resultados hayamos medido ni una promesa de que todas las aplicaciones puedan seguir la misma ruta.

## ¿Qué plazo de Deno afecta a tu aplicación?

El plazo de alojamiento afecta a Deno Deploy; el de mantenimiento, al entorno de ejecución de Deno. Averigua de qué depende realmente tu aplicación en producción antes de programar el trabajo.

En el anuncio del 9 de octubre, Deno afirma que todo su equipo se incorpora a Cloudflare. Deploy seguirá funcionando durante seis meses antes de cerrar. El entorno de ejecución recibirá versiones mensuales con correcciones de errores y de seguridad durante otro año; después, el equipo dejará de desarrollarlo, aunque seguirá siendo de código abierto. JSR continúa y su infraestructura se trasladará a Cloudflare. Se ofrece ayuda para la migración a los clientes de pago que se pasen a Workers. Estos compromisos no fijan una fecha y hora exactas de cierre, el alcance contractual de la ayuda para cada cliente ni un equipo que asuma después el mantenimiento del entorno de ejecución. Confirma esos detalles directamente al planificar el cambio.

Una aplicación puede usar el entorno de ejecución sin usar Deploy. Un pipeline de compilación que ejecuta `deno task` tiene una dependencia distinta de la de una API cuyas peticiones llegan a Deploy. Un servicio de terceros también puede usar un entorno de ejecución compatible con Deno: [Supabase describe así sus Edge Functions](https://supabase.com/docs/guides/functions), junto con su propia pasarela y las integraciones de su plataforma. Eso no convierte a Supabase en cliente de Deploy ni le atribuye el plazo de cierre de Deploy.

Para cada ruta de petición en producción, anota qué servidor la atiende y en qué entorno se ejecuta. Después, identifica si el estado o las tareas programadas también dependen de Deploy. Es una revisión breve de las dependencias de esa aplicación. La mera presencia de configuración de Deno en el repositorio no permite responder a esas preguntas.

La documentación también puede llevarte a un plazo equivocado. La [guía de migración](https://docs.deno.com/deploy/migration_guide/) existente de Deno explica el paso de **Deploy Classic a Deno Deploy**. Su destino no es Workers. La [descripción general de Deploy](https://docs.deno.com/deploy/) también conserva un aviso histórico sobre el cierre de Classic. Lee ambas como documentación de aquella transición anterior, no como las instrucciones completas de migración correspondientes al anuncio de octubre de 2026.

Si te afectan ambos plazos, valida la alternativa de alojamiento antes de que termine su periodo. Toma por separado la decisión sobre el mantenimiento del entorno de ejecución, incluido cualquier ejecutable de Deno que siga presente en las compilaciones o las tareas internas después de trasladar el servicio público.

## Elige el destino por el comportamiento que puede conservar

El destino adecuado supera las pruebas de aceptación de tu aplicación y tu equipo puede gestionarlo. Un anuncio de adquisición no resuelve esa elección.

Usa esta tabla para decidir qué investigar primero. Los requisitos son recomendaciones de ingeniería; los compromisos de los proveedores son los que figuran en sus anuncios.

| Situación de tu aplicación | Ruta posible | Pruebas necesarias para aceptarla | Motivo para reconsiderarla |
| --- | --- | --- | --- |
| Servicio HTTP alojado en Deploy con poco comportamiento específico del entorno de ejecución | Evaluar Workers gestionado, incluida la ayuda anunciada para clientes de pago | Superan las pruebas las rutas reales de petición, la autenticación, la ejecución de dependencias, los registros y la recuperación ante fallos | Una API necesaria se importa pero no puede ejecutarse, o cambia el contrato de datos |
| Las API del entorno de ejecución de Deno son esenciales para el servicio | Evaluar un alojamiento con mantenimiento que pueda ejecutar el entorno necesario, o una reescritura explícita para otro entorno | Las API utilizadas y la recuperación operativa funcionan en la versión y el alojamiento elegidos | La ruta conserva el código actual, pero deja sin resolver el mantenimiento |
| Las transacciones de Deno KV protegen las invariantes de la aplicación | Elegir el almacenamiento por los requisitos de transacción antes de elegir el nombre del producto | Las escrituras concurrentes, las confirmaciones condicionales, la caducidad y la restauración conservan la invariante | La alternativa supera las lecturas secuenciales, pero pierde conflictos o devuelve un estado desactualizado |
| Deno solo aparece en una tarea de compilación o desarrollo | Revisar las herramientas por separado del alojamiento de producción | Compilaciones reproducibles y un plan de mantenimiento del entorno de ejecución | Se programa una migración de alojamiento para una plataforma que la aplicación no usa |
| Otro proveedor opera el servicio compatible con Deno | Verificar el ciclo de vida y las dependencias de ese proveedor | Información de mantenimiento del proveedor y pruebas de tu integración | Se ha asumido el plazo de Deploy sin pruebas |
| El equipo considera alojar workerd por su cuenta | Tratarlo como una propuesta operativa aparte | Las funciones necesarias ya existen y el equipo puede desplegarlas, diagnosticar problemas y recuperarlas | El plan depende de formas de distribución o herramientas futuras anunciadas |

El [anuncio de Cloudflare](https://blog.cloudflare.com/deno-joins-cloudflare/) describe el trabajo futuro para combinar celld y workerd y permitir el alojamiento propio. También reconoce que la implementación actual de Durable Objects en workerd está limitada a una sola instancia y que las herramientas que la rodean están incompletas. Eso delimita lo que se puede deducir de la dirección propuesta.

Para un equipo que se plantea usar infraestructura propia, la responsabilidad operativa es una cuestión aparte. Nuestro [artículo sobre personal y responsabilidades en el alojamiento propio](/blog/self-hosting-startup-staffing-ownership) aborda esa decisión. Aquí, la pregunta inmediata es si el destino elegido puede superar las pruebas de la aplicación.

## Prueba las rutas que se ejecutan, la autenticación y las tareas en segundo plano

Una prueba de migración debe ejercitar el comportamiento que podría fallar en el destino. Compilar correctamente y obtener los mismos códigos de estado HTTP solo aporta una parte de las pruebas.

Empieza con un pequeño banco de pruebas en un entorno de preproducción que pueda enviar las mismas peticiones representativas a la aplicación actual y a la alternativa. Usa registros sintéticos y credenciales de prueba independientes. Fija el estado inicial para poder interpretar las comparaciones y anota después las diferencias deliberadas, como el nombre del host o los identificadores generados.

La [documentación de compatibilidad de Deno con Node y npm](https://docs.deno.com/runtime/fundamentals/node/) trata sobre la ejecución de aplicaciones Node en Deno. No demuestra que el código que usa las API de Deno pueda ejecutarse sin cambios en otro lugar. En Workers, la [documentación de compatibilidad con Node.js](https://developers.cloudflare.com/workers/runtime-apis/nodejs/) distingue entre API implementadas, compatibilidad parcial e implementaciones vacías sin funcionalidad. Una importación puede funcionar y una llamada posterior fallar.

Incluye de forma explícita las rutas poco usadas: la exportación de informes, la transformación de adjuntos, el callback de autenticación o la tarea que accede a un sistema de archivos o lanza un subproceso. Incluye solo las funciones que usa tu aplicación. Ejecuta la operación real de la dependencia en lugar de comprobar únicamente que se carga su módulo. Deja fijadas la configuración del destino y la fecha de compatibilidad en el registro de la prueba, para que un resultado correcto corresponda a un entorno reproducible.

Para comprobar el comportamiento HTTP, compara cuerpos de respuesta, cabeceras, redirecciones y cookies cuando formen parte del contrato. Incluye datos de entrada mal formados, sesiones caducadas y peticiones sin autorización. Si el servicio separa los datos por cuenta, crea registros similares en dos cuentas sintéticas e intenta acceder de una a la otra. Una respuesta que contiene el registro esperado, pero también datos de otra cuenta, debe hacer fallar la prueba.

Si la aplicación programa tareas o las pone en cola, pruébalas por separado. Por ejemplo, acepta una petición, interrumpe el proceso de trabajo antes de que termine y vuelve a intentar la entrega. Comprueba el estado resultante y el efecto externo con un receptor de prueba en lugar del buzón de un cliente real. Verifica que quien deba intervenir pueda detectar el fallo. Una petición que devuelve un resultado correcto no demuestra que se haya ejecutado su tarea posterior.

Documenta cada resultado de forma que otro ingeniero pueda cuestionarlo: estado inicial, acción, resultado esperado, resultado observado y traza pertinente. Marca un criterio como «no aplicable» y explica el motivo cuando la aplicación carezca de esa función. Una lista de comprobación enorme con marcas verdes sin explicación aporta menos pruebas que unos pocos casos ligados a fallos reales.

## Deno KV y Workers KV necesitan pruebas de aceptación distintas

Los nombres similares de dos sistemas de almacenamiento no demuestran que sus transacciones o lecturas se comporten igual. Si la corrección del estado depende de Deno KV, deja clara esa dependencia antes de elegir el almacenamiento alternativo.

La [documentación de transacciones de Deno KV](https://docs.deno.com/deploy/kv/transactions/) describe un control de concurrencia optimista. Las lecturas devuelven marcas de versión; una operación atómica puede comprobar pares de clave y marca de versión junto con las modificaciones. La confirmación solo tiene éxito si las versiones comprobadas siguen coincidiendo. Las aplicaciones que usan esas comprobaciones deben gestionar los conflictos y decidir si reintentan la operación.

La [documentación de Workers KV](https://developers.cloudflare.com/kv/concepts/how-kv-works/) explica que sus réplicas convergen con el tiempo: los cambios pueden tardar 60 segundos o más en aparecer en otras ubicaciones. Advierte de que no se debe confiar en su visibilidad inmediata, ni siquiera allí donde se ha realizado la escritura, y afirma que KV no es idóneo para operaciones atómicas ni para lecturas y escrituras transaccionales. Remite a Durable Objects a quienes necesitan mayor coherencia.

Se trata de una diferencia concreta de compatibilidad, no de un juicio en contra de Workers. Una caché y una restricción de unicidad pueden necesitar almacenamientos distintos incluso dentro de la misma aplicación. Elegir otro componente de almacenamiento de Cloudflare también exige probar sus garantías reales y tu implementación; su nombre no aporta por sí solo el comportamiento que falta.

Supongamos que una aplicación Deno comprueba que no existe una clave de invitación y, después, crea de forma atómica la invitación y su registro de búsqueda. Una adaptación ingenua que haga una lectura seguida de escrituras independientes puede superar todas las pruebas secuenciales. Prueba, en cambio, dos peticiones concurrentes para la misma invitación. El resultado esperado de la aplicación podría ser una invitación aceptada, un conflicto y un registro de búsqueda coherente. Define ese resultado a partir del contrato existente antes de escribir la alternativa.

Un segundo caso prueba la visibilidad. Crea un registro sintético de permisos, revócalo e intenta inmediatamente realizar la acción protegida desde otra ubicación geográfica. Especifica si la revocación debe aplicarse al instante o si el producto admite un retraso. El resultado de aceptación debe responder a ese requisito de seguridad, no a si la API de almacenamiento devolvió un resultado correcto.

Para la caducidad, crea un registro de corta duración y comprueba el acceso antes y después de su vencimiento. Incluye una ausencia previamente guardada en caché si importa cuándo se hace visible la creación. Para las listas ordenadas, restaura suficientes claves sintéticas para poner a prueba las suposiciones de la aplicación sobre paginación y orden. Si las marcas de versión sirven como cursores o metadatos de la aplicación, define cómo funcionarán esas referencias tras la conversión; no las sustituyas sin más por las marcas de tiempo del destino.

## Detecta los falsos positivos antes de aprobar el cambio

Un falso positivo es un resultado correcto obtenido sin poner a prueba la condición que debía comprobarse. Revisa el diseño de las pruebas con tanto cuidado como el código de la alternativa.

Un emulador local puede validar la lógica sin reproducir la distribución de producción. Las peticiones desde una sola máquina pueden pasar por alto un problema de visibilidad que afecta a otra ubicación. Las peticiones secuenciales no demuestran la seguridad de la concurrencia. Una base de datos vacía no puede revelar un error de conversión en registros antiguos. Añade la condición concreta que falta en lugar de repetir más veces la misma prueba superficial.

Presta atención también a los fallos ocultos. Un error de una dependencia puede capturarse y convertirse en un resultado vacío. El endpoint devuelve 200, pero la exportación ha perdido filas. Comprueba el contenido de la salida y el comportamiento esperado ante errores. En las pruebas de reintento, cuenta el efecto final, no solo el número de peticiones aceptadas.

Duplicar tráfico exige cuidado. Reproduce peticiones con los datos sensibles eliminados en un estado aislado y sustituye los destinos de correo, pagos y webhooks por receptores de prueba. Replicar una escritura de producción puede provocar un segundo efecto externo. Decide de antemano qué comparaciones pueden ser de solo lectura y cuáles necesitan un caso controlado en preproducción.

Las pruebas operativas también forman parte de la aceptación. Provoca un fallo reconocible en preproducción y pide a alguien que lo diagnostique con los registros y las alertas del destino. Comprueba que las credenciales corresponden al entorno previsto y que las instrucciones de recuperación funcionan para la persona que debe intervenir. Una aplicación correcta cuyos fallos no se pueden investigar sigue siendo difícil de recuperar bajo presión.

## Demuestra la vuelta atrás con escrituras y conciliación de datos

La vuelta atrás solo está completa cuando la aplicación anterior puede reanudar el servicio con un estado correcto. Revertir el encaminamiento del tráfico no deshace las escrituras que ha aceptado el destino.

Deno documenta las [copias de seguridad de KV en almacenamiento compatible con S3 bajo control del cliente](https://docs.deno.com/deploy/kv/backup/) y su uso mediante la herramienta `denokv`. Es una vía de exportación y recuperación que conviene examinar. No convierte automáticamente los datos a Workers KV, D1 ni a otro destino.

Restaura una copia de seguridad representativa de forma aislada. Compara registros relevantes, el comportamiento de caducidad y las relaciones, no solo el número de objetos. Anota hasta qué momento cubre la copia e identifica las escrituras aceptadas después. Una copia legible que carece de transacciones recientes no basta para la vuelta atrás que pretendes realizar.

Después, ensaya un fallo cuando la alternativa ya haya aceptado nuevas escrituras. Detén o controla de otro modo las escrituras posteriores, captura los cambios aceptados en el destino y concílialos en el sistema que volverá a ser la fuente autoritativa. Define cómo se gestionan los duplicados, las modificaciones en conflicto, las eliminaciones y las tareas interrumpidas. Usa identificadores de la aplicación y reglas de conciliación explícitas; «copiarlo todo de vuelta» deja esas preguntas sin respuesta.

En un servicio pequeño, una pausa planificada de las escrituras puede facilitar la conciliación. Un servicio que no pueda detenerlas necesita un diseño probado de captura de cambios o replicación. Las escrituras dobles añaden sus propios casos de fallo: un lado puede tener éxito mientras el otro falla. Ensaya ese caso antes de considerar las escrituras dobles una protección para la recuperación.

Por último, especifica en la decisión de cambio el punto a partir del cual la vuelta atrás requiere más trabajo. Antes de que empiecen las escrituras en el destino, devolver el tráfico puede ser sencillo. Después, exige el procedimiento de conciliación y las pruebas que lo validan. Si el equipo no puede restaurar un estado correcto dentro del requisito de recuperación que ha elegido, el cambio no está listo.

## Usa Kit si la migración revela una necesidad de contratación

Contrata para cubrir una carencia de ingeniería demostrada cuando las pruebas de aceptación hayan mostrado qué falta. Un plazo de cierre no demuestra por sí solo que la startup necesite incorporar a alguien de forma permanente.

Puede que necesites a alguien para una conversión puntual de bases de datos, experiencia en compatibilidad de entornos de ejecución o una persona que asuma la responsabilidad operativa a largo plazo. Define primero el resultado necesario y la duración. Un ejercicio breve de entrevista puede pedir a un candidato que explique una escritura condicional fallida, investigue una ruta de compatibilidad al ejecutarla o razone cómo volver atrás tras crear un registro nuevo. Usa datos sintéticos y un ejercicio corto; el trabajo de migración de producción debe remunerarse.

Guarda las pruebas de la migración y las decisiones de cambio en tus herramientas de ingeniería. Kit encaja en el proceso de selección si decides contratar: ofrece un lugar donde gestionar candidaturas y la revisión del equipo. No migra tu entorno de ejecución ni concilia tu base de datos.

El objetivo inmediato es disponer de una alternativa que supere las pruebas de comportamiento, estado y recuperación antes de que termine el plazo de alojamiento. Si esas pruebas revelan un puesto que necesitas cubrir, [consulta Kit Hiring](/hiring) para esa fase de contratación.