El programador que hizo tu sistema ya no está: qué hacer en los primeros 30 días

Foto de Marco Orta | 14 min de lectura
Portada tipográfica: «Se fue» en grande sobre un diff, en rojo «el código está en su laptop» y en verde «el código está en un repositorio a nombre de tu empresa»
Tabla de Contenidos

    Si el programador o la agencia que hizo tu sistema ya no contesta, lo primero no es buscar quien lo reemplace: es asegurar lo que ya tienes. En 30 días puedes recuperar el control si consigues cinco cosas: el código fuente, el acceso al servidor donde corre, una copia de la base de datos, el dominio y las llaves de todo lo que el sistema usa (pagos, WhatsApp, facturación, correo). Si el sistema se hizo por encargo y no firmaste nada que diga lo contrario, la ley mexicana dice que los derechos patrimoniales sobre ese código son tuyos (Ley Federal del Derecho de Autor, art. 83). Abajo va la lista de lo que debes tener, cómo recuperar cada cosa, qué hacer si ni siquiera tienes el código y cómo decidir, con el sistema ya en tus manos, si se arregla, se migra por partes o se reemplaza.

    No soy abogado. Lo legal de este artículo es mi lectura del texto de la ley, que enlazo; confirma tu caso con uno. Lo técnico sí es lo mío: me dedico a rescatar sistemas PHP y Laravel que alguien dejó a medias, y el caso de este artículo, el programador que se fue, es el más común que me llega.

    Primero: qué debes tener en tu poder

    Un sistema son al menos siete cosas, y normalmente el dueño del negocio tiene una o dos. Revisa esta lista hoy, aunque tu programador siga contestando:

    QuéDónde suele estarCómo sabes que lo tienes
    El código fuenteUn repositorio en GitHub, GitLab o Bitbucket, o solo en la computadora del programadorPuedes entrar al repositorio con una cuenta tuya y ver los archivos. Un .zip que te mandaron hace un año no cuenta: es una foto vieja
    El servidor donde correUn VPS (DigitalOcean, Hetzner, AWS, Vultr), un hosting compartido con cPanel o una máquina en tu oficinaTienes la cuenta del proveedor a tu nombre y puedes entrar al panel o por SSH
    La base de datosEn el mismo servidor, o en un servicio aparte (RDS, PlanetScale, un MySQL del hosting)Puedes sacar un respaldo tú mismo, y lo has restaurado al menos una vez en otro lado
    El dominio y el DNSUn registrador (GoDaddy, Namecheap, Akky para .mx) y, a veces, CloudflareEl dominio está a nombre de tu empresa, con tu correo, y puedes entrar al registrador
    El correo del sistemaGoogle Workspace, Microsoft 365, Mailgun, SendGrid, Amazon SESPuedes entrar y ver qué correos manda el sistema
    Las llaves de tercerosMeta (WhatsApp), Mercado Pago o Stripe, el PAC de facturación, el SAT (CSD y e.firma), Google Maps, la API de tu ERPCada cuenta está a nombre de tu empresa y tienes el acceso, no solo «ya está configurado»
    La app móvil, si hayGoogle Play Console y App Store Connect, más la llave de firma del APKLa cuenta de desarrollador es tuya; sin la llave de firma no se puede actualizar la app en Play, aunque tengas el código

    Si contestaste «no sé» en más de dos filas, no tienes un sistema: tienes un servicio que depende de que otra persona siga de buenas. Eso es lo que hay que cambiar en los próximos 30 días.

    Días 1 a 3: congela lo que haya y pide todo por escrito

    1. Escríbele al programador o a la agencia, por correo, con fecha. Pide las siete cosas de la tabla, una por una, y da un plazo razonable (diez días hábiles). Aunque no conteste, ese correo te sirve después: deja constancia de que lo pediste y cuándo.
    2. No cambies contraseñas todavía si no sabes qué se rompe. Un sistema suele conectarse a sí mismo con esas contraseñas (la base de datos, el correo, la API de pagos). Cambiarlas a ciegas lo tira. Primero inventario, luego cambios.
    3. Haz un respaldo de lo que sí alcances. Si tienes acceso al hosting, descarga los archivos y exporta la base de datos hoy, aunque no entiendas qué son. Es la foto de «antes de tocar nada».
    4. Anota qué hace el sistema con tus palabras: qué pantallas usa tu gente, qué reportes saca, qué manda solo (correos, facturas, mensajes), con qué se conecta. Es el mapa que el siguiente técnico va a necesitar, y lo sabes tú mejor que nadie.

    Días 4 a 10: recupera el acceso a cada cosa

    El servidor y el hosting. Si la cuenta del proveedor está a tu nombre, entras y cambias la contraseña: listo. Si está a nombre del programador, el proveedor no te la va a dar, pero sí puedes pedir el traspaso de la cuenta o del servidor; cada proveedor tiene un procedimiento, y casi todos piden que la petición salga del titular. Si el titular no responde, la ruta realista es mover el sistema a un servidor tuyo, no pelear por el viejo. Para eso necesitas el código y la base de datos, que es lo siguiente.

    El código fuente, si está en un repositorio. Pide que te hagan propietario de la organización o del repositorio, no colaborador. En GitHub, GitLab y Bitbucket se transfiere la propiedad en un par de clics. Si no te lo transfieren, tú puedes crear tu propia organización y, con un acceso de lectura, clonar el repositorio completo con su historial. Aun así, pide el traspaso: con la propiedad vienen las claves del despliegue y las acciones automáticas.

    El código fuente, si nadie sabe dónde está. La buena noticia: si el sistema está corriendo, el código está en el servidor (en PHP y Laravel, casi siempre tal cual, legible). Con acceso al servidor se recupera completo. Lo que pierdes es el historial de cambios y, a veces, los archivos de configuración con las llaves, que conviene regenerar de todas formas. Un sistema compilado (una app móvil, un ejecutable) es otra historia: ahí sin el código fuente hay que reescribir, y por eso la llave de firma de la app y el repositorio importan tanto.

    La base de datos. Con acceso al servidor sacas un respaldo (mysqldump, pg_dump o el botón «Exportar» del panel). Restáuralo en otro lado para comprobar que sirve: un respaldo que nunca se ha restaurado es una esperanza, no un respaldo.

    El dominio. Si está a nombre del programador, pídele que inicie la transferencia a una cuenta tuya; los registradores piden un código de autorización que solo el titular puede generar. Si no coopera, los registros de .mx y los de .com tienen procedimientos de disputa, pero son lentos. Mientras tanto, registra hoy una variante del dominio a tu nombre para no quedarte sin nada si el otro vence. Y revisa quién administra el DNS: si es Cloudflare, también esa cuenta debe ser tuya.

    Las llaves de terceros. Entra a cada servicio (Meta Business, Mercado Pago, tu PAC, Google Cloud) y comprueba de quién es la cuenta. Las que estén a nombre del programador se vuelven a crear a tu nombre y se cambian en el sistema; es trabajo, pero es el único modo de que no te las apaguen. Los certificados del SAT (CSD y e.firma) son del contribuyente: si el programador los tiene, pide que los borre de donde los tenga una vez que los cambies tú.

    Días 11 a 20: diagnóstico, no arreglos

    Con el código, el servidor y la base en tus manos, viene la tentación de empezar a arreglar. Mejor no: primero hay que saber qué tienes. Esto es lo que yo reviso en un diagnóstico, y lo que le puedes pedir a quien contrates:

    • Versiones: de PHP, del framework y de cada paquete. Es la primera pregunta porque las versiones tienen fecha. PHP 8.2 recibe parches de seguridad solo hasta el 31 de diciembre de 2026; Laravel 11 dejó de recibirlos en marzo de 2026. Un sistema hecho en 2021 o 2022 casi seguro está en una versión que ya no se parcha.
    • Qué corre solo: tareas programadas, colas, correos automáticos, timbrado de facturas. Es lo que se rompe en silencio cuando se mueve de servidor.
    • Con qué se conecta: cada API, cada webhook, cada integración. Cada una es una llave de la lista de arriba.
    • Seguridad básica: contraseñas en el código, puertos abiertos, respaldos que no existen, usuarios de administrador que nadie recuerda haber creado.
    • Qué tan documentable es: si otro programador puede entenderlo en una semana o si cada regla de negocio está enterrada en código que nadie quiere tocar.

    El resultado del diagnóstico no es «está mal». Es un inventario, una lista de riesgos ordenada por lo que te costaría que fallen y una recomendación con precio.

    Días 21 a 30: decidir con números

    Las opciones son tres, y la buena noticia es que la peor casi nunca es la única:

    OpciónCuándo convieneQué cuesta de verdad
    Estabilizar y mantener lo que hayEl sistema hace lo que necesitas, solo está desatendido: versiones viejas, sin respaldos, sin nadie que contesteLo más barato. Se actualizan versiones, se automatizan respaldos, se documenta y alguien lo cuida cada mes
    Migrar por partesHay módulos que ya no sirven o que nadie entiende, pero otros funcionan bienMedio. Se reemplaza módulo por módulo, sin apagar el sistema, y cada etapa tiene su precio cerrado
    Reescribir desde ceroEl código no se puede recuperar, o es tan frágil que cada cambio rompe otra cosaLo más caro, y no por el precio: durante meses pagas dos sistemas, y el nuevo tarda en igualar reglas que el viejo ya resolvía. Muchas reescrituras se abandonan a medias

    Mi regla: reescribir es la última opción, no la primera. Casi todos los programadores que lleguen te van a proponer reescribir, porque es más cómodo para ellos. Pídeles que te expliquen, módulo por módulo, por qué no se puede migrar por partes.

    Qué dice la ley sobre de quién es el código

    La Ley Federal del Derecho de Autor protege los programas de cómputo como obras (art. 13, fracción XI). Sobre quién es el dueño, hay dos artículos que importan:

    • Art. 83, obra por encargo. «Salvo pacto en contrario, la persona física o moral que comisione la producción de una obra o que la produzca con la colaboración remunerada de otras, gozará de la titularidad de los derechos patrimoniales sobre la misma.» Si le pagaste a un freelance o a una agencia por hacer tu sistema y el contrato no dice otra cosa, los derechos patrimoniales son tuyos.
    • Art. 84, relación laboral. Si el programador era tu empleado con contrato escrito y no se pactó nada, se presume que los derechos se dividen por partes iguales. Si no había contrato por escrito, los derechos son del empleado. Este es el caso que más sorprende a los dueños.

    Lo que eso significa en la práctica: tener el derecho no te da el código. Te da la razón para exigirlo y, si hace falta, para reclamarlo. Por eso el correo del día 1 importa, y por eso el contrato con el siguiente proveedor debe decir, con todas sus letras, que el código, el repositorio y los accesos son de tu empresa.

    Y un matiz: lo que el programador hizo con código de otros (librerías de código abierto, el propio framework) se rige por la licencia de esos componentes, no por tu contrato. En PHP y Laravel es casi todo licencia MIT, que permite usarlo sin problema.

    Para que no te vuelva a pasar

    Con el sistema ya en tus manos, lo que lo mantiene en tus manos es un contrato y tres hábitos:

    1. En el contrato: código en un repositorio a nombre de tu empresa desde el día uno; cuentas de servidor, dominio y terceros a nombre de tu empresa; documentación como entregable; y qué pasa si el proveedor deja de responder (accesos, plazos, entrega).
    2. Respaldos que se prueban. Automáticos, fuera del servidor, y una vez al trimestre alguien los restaura para ver que sirven.
    3. Un inventario vivo. La tabla de arriba, llenada y actualizada cada vez que algo cambia. Es una hoja, no un sistema.
    4. Alguien que conteste. Un sistema sin mantenimiento no se queda igual: se queda viejo. Un programador de confianza o una iguala mensual cuesta menos que el día que todo se cae.

    Lo que yo hago para esto

    Mi trabajo con sistemas que alguien dejó empieza por un diagnóstico de 5 días hábiles por $9,900 MXN más IVA: firmamos confidencialidad, me das acceso de solo lectura, levanto una copia fuera de producción, reviso versiones, paquetes, seguridad y respaldos, y te entrego un documento con el inventario, los riesgos ordenados por costo, la recomendación (estabilizar, migrar por partes o reescribir) y el precio cerrado de cada etapa. Te lo explico en una llamada de una hora, en lenguaje de negocio. Si contratas la estabilización, el diagnóstico se descuenta completo; si el documento dice que no vale la pena rescatarlo, también lo dice. Y si lo que necesitas primero es solo recuperar el código del servidor y sacar un respaldo que sirva, eso cabe en la llamada gratis de 20 minutos con la que empieza todo.

    Hago PHP y Laravel, que es donde vive la mayoría de los sistemas a medida en México. Si tu sistema es otra cosa, en la llamada te digo si te puedo ayudar o a quién buscar.

    Preguntas frecuentes

    El programador que hizo mi sistema desapareció. ¿Puedo recuperar el código?

    Casi siempre sí. Si el sistema está corriendo, el código está en el servidor: con acceso al hosting o al VPS se recupera completo, y en PHP y Laravel es legible tal cual. Lo que se pierde sin el repositorio es el historial de cambios. Lo que no se recupera así es una app móvil compilada sin su código fuente ni su llave de firma.

    ¿De quién es el código de un sistema que pagué a un freelance o a una agencia?

    Según el artículo 83 de la Ley Federal del Derecho de Autor, salvo pacto en contrario, quien comisiona y paga una obra es el titular de los derechos patrimoniales. Si tu contrato no dice otra cosa, el código es tuyo. Si el programador era tu empleado sin contrato escrito, el artículo 84 dice que los derechos son del empleado. No soy abogado: confirma tu caso con uno.

    ¿Qué hago si el dominio está a nombre del programador?

    Pídele por escrito que inicie la transferencia a una cuenta tuya; el registrador exige un código que solo el titular puede generar. Mientras tanto registra una variante del dominio a tu nombre para no quedarte sin nada. Si no coopera, los registros tienen procedimientos de disputa, pero son lentos y no sustituyen el acuerdo.

    ¿Debo cambiar todas las contraseñas de inmediato?

    No a ciegas. El sistema usa esas contraseñas para conectarse a su base de datos, a su correo y a las APIs de pago o facturación; cambiarlas sin inventario lo tira. Primero respaldo, luego inventario de dónde se usa cada una, y después se cambian una por una, empezando por las cuentas a nombre del programador.

    ¿Conviene reescribir el sistema desde cero?

    Casi nunca como primera opción. Reescribir implica pagar dos sistemas durante meses y el nuevo tarda en igualar las reglas que el viejo ya resolvía; muchas reescrituras se abandonan. Lo habitual es estabilizar lo que hay (versiones, respaldos, documentación) y migrar por partes solo los módulos que de verdad no sirven. Un diagnóstico te dice cuál es tu caso con números.

    ¿Cuánto cuesta un diagnóstico del sistema y qué incluye?

    Conmigo, $9,900 MXN más IVA por cinco días hábiles: inventario de versiones, paquetes, servidor e integraciones; riesgos ordenados por lo que costaría que fallen; respaldo verificado y una copia fuera de producción; recomendación de estabilizar, migrar o reescribir; y precio cerrado de cada etapa. Se descuenta si contratas la estabilización, y te quedas el documento aunque no contrates nada más.

    ¿Y si mi sistema no es PHP ni Laravel?

    La lista de qué debes tener en tu poder y el plan de 30 días aplican a cualquier sistema. Lo que cambia es quién lo rescata: yo trabajo PHP y Laravel, que es donde vive la mayoría de los sistemas a medida en México. En una llamada de 20 minutos te digo si te puedo ayudar o a quién buscar.

    ¿Te sirvió? Compártelo

    ¿Te sirvió? Recibe la próxima por correo

    Una vez por semana: qué se rompe al actualizar, IA para desarrolladores y lo que estoy construyendo, con fuentes. Sin spam.

    Al suscribirte aceptas nuestro aviso de privacidad.

    Buscar

    Etiquetas

    PHP IA Laravel Migración JavaScript Tutorial Seguridad Desarrollo Web Upgrade Buenas Prácticas Agentes MCP OpenAI SEO Backend