Cómo cambiar de proveedor de software sin frenar tu operación
Qué revisar antes de cambiar de proveedor de software: accesos, código, contratos, respaldos y un plan de transición que no rompa tu operación.
Cambiar proveedor de software no debería sentirse como sacar un servidor de un edificio en llamas. Aun así, muchas empresas llegan ahí cuando ya no pueden entrar al hosting, no saben quién paga las licencias o dependen de una sola persona que dejó de responder. Si estás pensando en cambiar proveedor de software, el trabajo importante empieza antes de pedir una nueva cotización.
No se trata de probar que el proveedor anterior hizo todo mal. A veces el equipo creció, cambió de especialidad o simplemente ya no tiene capacidad. El problema es cambiar a ciegas y convertir una transición comercial en una caída de operación.
Primero recupera el control de los accesos
El código es solo una parte del sistema. Para que una aplicación siga viva necesitas saber dónde corre, qué base de datos usa, quién recibe los correos transaccionales, dónde están los dominios y qué servicios externos tienen credenciales activas. También importan las cuentas de Apple y Google si hay apps móviles, las analíticas, los respaldos y las herramientas con las que el equipo despliega cambios.
Haz una lista de cuentas y exige que tengan un propietario de tu empresa, no una cuenta personal del proveedor. Puedes dar acceso de administrador a una agencia, pero el correo de recuperación y la facturación deberían estar bajo tu control. Es una diferencia aburrida hasta que alguien deja de contestar mensajes.
Si no tienes todas las claves, no intentes cambiar contraseñas al azar. Primero identifica qué servicio es crítico para cobrar, vender, atender clientes o cumplir una operación diaria. En DevAces hemos visto transiciones que se complican porque se mueve el dominio antes de entender qué correo o integración depende de él.
Pide una radiografía, no una promesa de reescribir todo
Una agencia nueva puede revisar el repositorio y decir que todo está mal. A veces tendrá razón. Pero una propuesta seria explica qué encontró, qué riesgo representa y qué conviene hacer primero.
Pide una revisión corta del código, la infraestructura y las integraciones. El resultado debe separar lo urgente de lo incómodo. Un respaldo de base de datos que nunca se ha probado es urgente. Una pantalla que podría verse más bonita puede esperar. También vale la pena preguntar si el sistema se puede levantar en otro ambiente, cuánto tarda un despliegue y qué pasa si una integración de pagos o WhatsApp falla.
Ese diagnóstico no es burocracia. Te ayuda a decidir si la transición puede ocurrir por módulos, si necesitas mantener al proveedor actual durante un periodo o si hay un riesgo real que obliga a actuar antes. Cambiar proveedor de software sin esta revisión suele terminar en una cotización enorme que mezcla mejoras deseables con rescates necesarios.
Revisa qué contrataste realmente
Antes de mover código o accesos, revisa el contrato, las facturas y los acuerdos que sí existan. La propiedad y el uso del código, los diseños y las cuentas no siempre se resuelven con un "yo pagué el proyecto". En México, la cesión de derechos y las obligaciones de entrega conviene dejarlas por escrito. Si hay duda seria, habla con un abogado que conozca contratos tecnológicos antes de convertir una discusión operativa en una pelea legal.
También aclara qué componentes son propios y cuáles son licencias de terceros. Un proveedor puede haber usado una cuenta de pago para enviar correos, procesar pagos o monitorear errores. Copiar el repositorio no mueve automáticamente esos servicios. El plan de cambio debe decir quién contrata cada licencia, cómo se transfieren los datos y qué se hará con los accesos del equipo anterior.
Cambia con una transición que se pueda comprobar
No hace falta detener todo para cambiar de equipo. El nuevo proveedor puede preparar un ambiente de prueba, restaurar un respaldo y hacer un despliegue pequeño antes de tocar producción. Si el sistema tiene flujos sensibles, como cobros o inventario, define una ventana de cambio y una forma de volver atrás si algo falla.
La entrega final debería dejar algo más útil que una carpeta comprimida: repositorio accesible, inventario de servicios, guía para levantar el proyecto, método de despliegue, acceso a respaldos y una persona de tu empresa que entienda dónde está cada cosa. No necesitas convertirte en programador. Necesitas dejar de depender de la memoria de una sola persona.
El mejor momento para preparar la salida es cuando todo va bien
Cambiar proveedor de software puede ser una decisión sana. El error es esperar a que haya una crisis para descubrir que nadie tiene las llaves. Si hoy tu aplicación depende de una agencia o un freelancer, pide el inventario de accesos, prueba un respaldo y deja clara la propiedad de las cuentas. Si ya estás por cambiar, una revisión técnica breve y un plan de transición te van a ahorrar semanas de adivinanzas.
En DevAces podemos revisar el punto de partida y proponer una transición realista, sin venderte una reescritura por reflejo. Primero entendemos qué no se puede romper. Luego decidimos qué vale la pena mejorar.