Rascacielos holográfico ámbar a medio construir con andamios de luz, metáfora de rescatar un proyecto de software abandonado
Software / APIsDesarrollo Web

Rescatar un Proyecto de Software Abandonado en Madrid

Codezone
Codezone Empresa de Desarrollo Web y Software a Medida

Rescatar un proyecto de software abandonado exige primero recuperar el control de los accesos y los datos, y después diagnosticar el código para decidir si se continúa, se refactoriza o se rehace. En Madrid es habitual encontrar proyectos a medio hacer que el proveedor anterior dejó sin entregar. Lo primero es asegurar lo que ya pagaste. Así planteamos el rescate dentro del desarrollo de software a medida de Codezone.

Cada semana con el proyecto parado tiene un coste doble: lo invertido no produce y el plan comercial que dependía del software se retrasa. Un dominio que caduca a nombre del antiguo proveedor o un servidor que deja de pagarse sin copia de la base de datos pueden borrar meses de trabajo en un día.

Al terminar sabrás qué asegurar en las primeras 72 horas y con qué criterio elegir el camino, apoyándote en la auditoría técnica del código heredado antes del rescate.

Qué es rescatar un proyecto de software abandonado

Rescatar un proyecto de software abandonado es tomar el control técnico y legal de una aplicación que otro proveedor dejó incompleta o sin mantenimiento para llevarla a producción, o sustituirla, con un plan cerrado basado en su estado real. Se diferencia de modernizar un sistema antiguo que funciona: aquí el software casi nunca está terminado ni documentado.

Para sistemas antiguos que funcionan, lee cómo sustituir una aplicación legacy sin detener la operación.

Bóveda holográfica ámbar con llaves de luz flotando sobre un suelo reflectante en una sala oscura
Sin las llaves de cada servicio, el código que tienes no se puede desplegar.

Las Primeras 72 Horas: Accesos, Datos y Activos

En las primeras 72 horas la prioridad es inventariar y poner a nombre de tu empresa todo lo que el proyecto necesita para funcionar.

  • Repositorio: acceso de propietario al Git con el historial completo.
  • Dominios y DNS: quién figura como titular y quién controla la zona DNS. Revisa también cómo se conecta un dominio externo al despliegue de la aplicación.
  • Hosting y nube: quién paga cada factura y qué servicios siguen activos.
  • Credenciales: tokens de API de terceros como la pasarela de pago. Rota todos los que conocía el antiguo proveedor.
  • Datos: copia completa de la base de datos y de los ficheros subidos, guardada fuera del servidor actual.

En paralelo, el artículo 97 de la Ley de Propiedad Intelectual en el BOE (Real Decreto Legislativo 1/1996) atribuye al empresario los derechos de explotación de un programa cuando lo crea un trabajador asalariado. Con un proveedor externo, la cesión depende del contrato.

Diagnóstico del Proyecto Heredado

Un diagnóstico de rescate mide cuánto del código existente puede sostener al negocio en los próximos años. En Codezone lo hacemos en una fase corta de alcance cerrado:

  • Despliegue: si arranca en un entorno limpio solo con lo que hay en el repositorio.
  • Estado funcional: qué procesos están terminados frente a lo contratado.
  • Seguridad: dependencias sin soporte y secretos escritos dentro del código.
  • Datos: si el modelo es coherente o necesita un plan para migrar los datos al sistema rescatado.

Si falta documentación, compara con la documentación técnica mínima que debe entregarte un proveedor.

Estructura holográfica de bloques de código con grietas rojas recorrida por un haz de escaneo ámbar
El diagnóstico separa lo que se puede aprovechar de lo que conviene tirar.

Continuar, Refactorizar o Rehacer: Lista de Decisión

Elegir entre continuar, refactorizar o rehacer depende de dos variables medibles: cuánto del alcance está bien construido y cuánto cuesta cambiar el código sin romperlo.

  • Continuar: Cuándo sí: el proyecto despliega con una arquitectura reconocible y faltan funcionalidades. Cuándo no: cada cambio rompe otra parte.
  • Refactorizar: Cuándo sí: el modelo de datos sirve, pero el código está desordenado o sin pruebas. Cuándo no: el framework ya no recibe parches de seguridad.
  • Rehacer: Cuándo sí: el proyecto no compila o su base técnica impide lo que el negocio necesita. Cuándo no: el único motivo es la preferencia del nuevo equipo.

Cómo se Presupuesta un Rescate en Madrid

Un rescate se presupuesta en dos tramos: un diagnóstico con precio cerrado y, después, la ejecución basada en lo encontrado. Presupuestarlo a ciegas obliga a inflar el margen o a renegociar a mitad de camino.

Contrasta los plazos realistas de un desarrollo a medida y, si buscas relevo, los criterios para escoger empresa de software en Madrid. Para la ejecución, mira cómo trabajar por sprints con un proveedor externo.

Globo holográfico de nodos conectados donde varios puntos parpadean en rojo de alerta sobre una red ámbar
Un inventario automático avisa antes de que un dominio o un certificado caduque.
CodeZone Pro Tip: este script lee un inventario YAML con los activos del proyecto (dominios, DNS, hosting, repositorios, cuentas) y marca los que no están a nombre de tu empresa o caducan en menos de 60 días.
import sys
from datetime import date, datetime

import yaml  # PyYAML: pip install pyyaml

# Nombre legal exacto que debe figurar como titular de cada activo
EMPRESA = "Tu Empresa SL"
MARGEN_DIAS = 60  # dos meses dan tiempo a renovar o a pedir un traspaso

def revisar(ruta):
    with open(ruta, encoding="utf-8") as f:
        activos = yaml.safe_load(f)["activos"]
    alertas = 0
    for a in activos:
        problemas = []
        if a.get("titular") != EMPRESA:
            problemas.append(f"titular: {a.get('titular', 'desconocido')}")
        caduca = a.get("caduca")
        if caduca:
            # YAML ya convierte 2026-11-30 en fecha; si llega como texto, se parsea
            if isinstance(caduca, str):
                caduca = datetime.strptime(caduca, "%Y-%m-%d").date()
            dias = (caduca - date.today()).days
            if dias < MARGEN_DIAS:
                problemas.append(f"caduca en {dias} días")
        if problemas:
            alertas += 1
            print(f"[REVISAR] {a['tipo']} {a['nombre']}: {'; '.join(problemas)}")
    print(f"{alertas} de {len(activos)} activos necesitan acción")
    # Salida distinta de 0 para lanzarlo como tarea programada y recibir aviso
    return 1 if alertas else 0

if __name__ == "__main__":
    sys.exit(revisar(sys.argv[1] if len(sys.argv) > 1 else "activos.yaml"))

Traducido a negocio: una tarea semanal te dice qué piezas del proyecto siguen dependiendo de terceros. Revisarlo cuesta minutos; recuperar un dominio perdido, días de aplicación caída.

Cómo Evitar que tu Próximo Proyecto Vuelva a Quedar Huérfano

Un proyecto deja de depender de un proveedor cuando el contrato deja los activos y el conocimiento en tu empresa desde el primer día.

  • Propiedad: cesión expresa de los derechos de explotación del código y de la documentación, que se entrega en cada hito.
  • Cuentas: todas a nombre de tu empresa, con el proveedor como usuario invitado.
  • Continuidad: un contrato de mantenimiento y soporte evolutivo con tiempos de respuesta definidos.
Candado holográfico ámbar sellando un documento de líneas de luz abstractas sobre un pedestal de cristal
Las cuentas a tu nombre desde el primer día evitan el siguiente rescate.

Un rescate bien hecho recupera la inversión y devuelve al negocio el control que debió tener desde el principio.

Si tienes un proyecto parado y no sabes en qué estado está, cuéntanos tu caso y revisamos contigo las primeras 72 horas.