Cómo salir de tu proveedor de software sin detener la operación

Nadie firma un contrato pensando en cómo va a salir.

Y así es como termina pasando. El proveedor que te desarrolló el sistema hace cinco años ya no contesta el correo en el mismo día. Cada cambio chico viene con una cotización. La persona que conocía el sistema se fue de su empresa y el que la reemplazó tampoco lo entiende. Y cuando alguien en tu directorio pregunta "¿por qué no nos cambiamos?", la respuesta honesta es que nadie sabe muy bien qué se llevaría el proveedor si se va.

Cambiar proveedor de software se puede hacer sin detener la operación. Lo he visto salir bien y lo he visto salir mal, y la diferencia casi siempre está en el orden de los pasos, no en lo técnico.

Señales de que estás atrapado

El vendor lock-in rara vez es un acto de mala fe. Es la acumulación de decisiones cómodas: el proveedor contrató el servidor porque era más fácil, registró el dominio porque tú no tenías tiempo, guardó el código en su cuenta porque ahí trabajaba. Cinco años después, todo lo que sostiene tu operación está a su nombre.

Algunas señales concretas:

• No sabes dónde está el código fuente, o sabes que está en una cuenta que no controlas.
• El servidor, la cuenta de nube o el dominio están facturados al proveedor.
• Nadie en tu empresa tiene una clave de administrador de nada.
• Cada cambio, por pequeño que sea, pasa por una cotización y demora semanas.
• La única documentación es lo que recuerda una persona del proveedor.
• Cuando preguntas cómo funciona algo, la respuesta es "déjanos revisarlo".

Si te identificas con tres o más, no estás frente a un proveedor lento. Estás frente a una dependencia que tiene costo, y ese costo sube cada año que pasa.

Antes de avisar: asegura los accesos

El error más caro es anunciar la salida primero. No porque el proveedor vaya a sabotear nada (la mayoría no lo hace), sino porque la relación cambia desde ese día. La disposición a ayudar baja, las respuestas se demoran y cada acceso que pides se vuelve una negociación.

Así que antes de cualquier conversación de término, pide los accesos como parte de la operación normal. Es razonable que una empresa quiera tener copia de lo suyo, y se puede plantear así, sin drama: "estamos ordenando los activos de TI y necesitamos tener todo inventariado a nombre de la empresa".

Lo que tienes que tener en tus manos:

1. Repositorio de código fuente, con el historial completo, no un zip de la última versión.
2. Servidores o cuenta de nube, idealmente transferidos a una cuenta de tu empresa con el proveedor como usuario invitado.
3. Dominio y DNS, registrados a nombre de tu empresa. Si el dominio está a nombre del proveedor, tu correo y tu sitio dependen de él.
4. Base de datos y respaldos, con un respaldo reciente que alguien de tu lado haya restaurado. Un respaldo que nunca se probó no es un respaldo.
5. Credenciales de servicios externos: correo transaccional, pasarelas de pago, certificados, integración con el SII, APIs de terceros.

Si el proveedor se niega a entregar el código o las credenciales de lo que tú pagas, ya sabes algo muy importante sobre la relación. Y ahí es donde entra el contrato.

---

Revisa el contrato (con un abogado)

Una aclaración: no soy abogado y esto no es asesoría legal. La interpretación de tu contrato la tiene que hacer alguien que sepa de propiedad intelectual y contratos en Chile. Lo que sí puedo hacer es decirte qué buscar, porque son las cláusulas que después determinan qué tan difícil es la salida técnica.

Revisa con tu abogado cuatro cosas:

• Propiedad intelectual del código. ¿El desarrollo a medida quedó a nombre de tu empresa o el proveedor se reservó derechos? Muchos contratos no dicen nada, y eso es un problema en sí mismo.
• Licencias. ¿El sistema usa componentes o productos propios del proveedor que se licencian aparte? Si es así, puede que el código a medida sea tuyo pero no funcione sin algo que no lo es.
• Obligación de traspaso. ¿Hay una cláusula que obligue al proveedor a entregar información y apoyo al término? Con cuántas horas y a qué costo.
• Confidencialidad. Qué puede y qué no puede compartir tu nuevo proveedor al recibir el sistema.

En la práctica, la propiedad del código fuente en el contrato y el control técnico del repositorio son dos cosas distintas. Puedes tener la razón en el papel y aun así no tener el código. Por eso la revisión legal y el aseguramiento de accesos van en paralelo, no uno después del otro.

Documenta lo crítico y quién sabe qué

Con los accesos en la mano, el siguiente paso es entender qué tienes. No hace falta documentar todo el sistema; hace falta documentar lo que, si falla, detiene la operación.

Yo parto por tres preguntas. ¿Qué procesos del negocio pasan por este sistema? ¿Qué integraciones tiene (ERP, SII, bodega, e-commerce, bancos)? ¿Qué tareas corren solas, de noche o a fin de mes, que nadie recuerda hasta que fallan?

Después viene el mapa de personas. Quién en tu empresa sabe cómo se usa cada módulo, quién en el proveedor sabe cómo está construido, y qué conocimiento existe solo en la cabeza de alguien. Ese último grupo es tu mayor riesgo, y el traspaso tiene que priorizarlo.

Un plan de salida por etapas

Salir de un proveedor de software sin detener la operación no es un evento, es un proceso. El que mejor nos ha funcionado tiene cuatro etapas:

1. Asegurar. Accesos, respaldos probados, contrato revisado. Hasta aquí, la operación no se entera de nada.
2. Entender. El nuevo equipo lee el código, levanta el sistema en un ambiente propio, documenta integraciones y tareas programadas. Es el momento de descubrir sorpresas, no en producción.
3. Operar en paralelo. El nuevo equipo hace cambios reales, chicos primero, mientras el proveedor anterior sigue disponible como respaldo. Algunas empresas lo llaman operar en sombra. Es la etapa que más gente quiere saltarse y la que más protege.
4. Cortar. Cuando el nuevo equipo ya resolvió incidentes y desplegó cambios sin ayuda, se cambian las credenciales, se revocan los accesos del proveedor anterior y se cierra el contrato.

La fecha de corte no se fija en el calendario. Se fija cuando el nuevo equipo ya demostró que puede operar solo.

Un consejo sobre la tentación de reescribir: no lo hagas en medio del traspaso. Un sistema feo que funciona sigue siendo el que sostiene tu operación. Primero control, después estabilidad, y recién ahí decides qué se refactoriza. Escribí más sobre esa decisión en deuda técnica vs reescribir desde cero.

---

Qué pedirle al proveedor saliente

Cuando llegue la conversación de término, llévala por escrito y con una lista concreta. Lo razonable de pedir:

• Traspaso del repositorio con historial y de todas las cuentas a nombre de tu empresa.
• Un documento de arquitectura, aunque sea breve: componentes, dónde corre cada cosa, cómo se despliega.
• Lista de integraciones con sus credenciales y contactos técnicos.
• Lista de tareas programadas y procesos manuales que el proveedor hacía por ti (esta suele sorprender).
• Un número acotado de horas de acompañamiento durante la etapa de operación en paralelo.

La mayoría de los proveedores, cuando la salida se plantea con respeto y con tiempo, coopera. Salir peleado no le conviene a nadie, y menos a la empresa que todavía depende del sistema.

Qué exigir en el próximo contrato

El mejor momento para evitar el vendor lock-in es antes de firmar. Con el próximo proveedor, sea quien sea, pide:

• Código en un repositorio de tu empresa desde el primer día, con el proveedor como colaborador.
• Propiedad intelectual del desarrollo a medida explícitamente a tu nombre.
• Documentación como entregable, con criterio de aceptación, no como buena intención.
• Cláusula de traspaso con horas y plazo definidos al término.
• SLA medible: tiempos de respuesta y de resolución por severidad.
• Si el sistema depende de un producto propio del proveedor, un acuerdo de escrow del código, si aplica a tu caso.

Si un proveedor se resiste a que el código viva en tu repositorio, esa es tu respuesta. Tengo una guía completa sobre esto en cómo evaluar un proveedor de software a medida en Chile, y si estás pensando en armar equipo propio para no depender de nadie, revisa equipo externo TI vs headcount permanente.

Cómo lo hacemos en AW

Buena parte de nuestro trabajo en rescate de proyectos TI empieza exactamente así: una empresa con un sistema que funciona a medias y un proveedor que ya no está. Parto siempre por los accesos y por un diagnóstico del código antes de prometer nada, porque lo que encontramos adentro define el plan. A veces el sistema está mejor de lo que se temía. A veces peor. En los dos casos, la operación sigue funcionando mientras hacemos el traspaso.

Si quieres ver cómo diagnosticamos un proyecto así, lo detallé en rescate de proyectos TI parados en Chile.

Si te sientes atrapado con tu proveedor actual, en 45 minutos revisamos qué controlas hoy, qué te falta asegurar y en qué orden conviene moverse. Sin compromiso de cambiar nada. Agenda un diagnóstico.