Es posible cambiar de agencia de desarrollo Magento a mitad de proyecto sin interrupciones si la entrega del código, la protección de los accesos y la auditoría de código se realizan paso a paso, según un plan documentado de antemano y empezando antes de cerrar el contrato actual. Según nuestra experiencia, el cambio de agencia se vuelve arriesgado cuando el directivo solo empieza a ocuparse de la entrega técnica después de rescindir el contrato, porque en ese momento la motivación del equipo saliente es mínima y los accesos pueden perderse fácilmente o retenerse de forma intencionada. En buena parte de los casos, el éxito del cambio no depende de la firma del contrato, sino de si el cliente ya tiene acceso a los sistemas críticos en el momento de tomar la decisión. Este artículo muestra paso a paso cómo traspasar un proyecto Magento en marcha a un nuevo equipo de desarrollo de forma discreta y sin incidencias, de modo que la tienda online siga funcionando de forma continua e ininterrumpida durante el cambio.
Protección de los accesos: el primer paso y el más crítico
La protección de los accesos es la base de todo cambio de agencia Magento con éxito, porque sin ella el cliente queda prácticamente a merced de su antiguo socio, por buena que sea la relación personal. Según nuestra experiencia, la mayoría de los problemas surgen porque los accesos al dominio, al servidor, al panel de administración y a las pasarelas de pago siguen a nombre de la agencia o bajo su gestión exclusiva, y el cliente solo descubre en el momento del cambio que no tiene acceso propio a ellos. En los casos que hemos analizado, los cambios se desarrollaron sin problemas cuando el directivo ya había establecido al firmar el contrato que todos los accesos críticos se crearan en cuentas de su propiedad y que el equipo de desarrollo trabajara en ellas solo como usuario invitado.
¿Qué accesos debes mantener siempre bajo tu control?
La lista de accesos que debes mantener bajo tu control va más allá del inicio de sesión en el panel de administración: incluye la cuenta del registrador del dominio, la configuración DNS, la cuenta del servidor o del hosting, el repositorio del sistema de control de versiones (normalmente Git), el panel de administración de las pasarelas de pago y todas las licencias de terceros. ¿Cuándo no se recomienda iniciar el cambio? Cuando aunque sea uno solo de estos accesos está gestionado en exclusiva por la agencia actual, porque en ese caso, en lugar de una transición discreta, puede acabar produciéndose una negociación forzada y tensa que incluso provoque interrupciones del servicio.
Entrega y auditoría del código paso a paso
La entrega del código no consiste en copiar unos archivos, sino en un proceso estructurado que implica recibir toda la base de código, la base de datos y la documentación, y después realizar una auditoría de código independiente antes de que el nuevo equipo empiece a trabajar de verdad. En buena parte de los casos hemos comprobado que el mayor riesgo no es una obstrucción malintencionada, sino que las modificaciones a medida de la base de código antigua no estén documentadas y el nuevo equipo de desarrollo tarde semanas en averiguar por qué cada cosa funciona como funciona. Hemos observado esta relación en varios proyectos: cuando el desarrollo de la tienda online con Magento partió desde el principio de una base de código ordenada y bajo control de versiones, el cambio de agencia fue mucho más rápido y menos arriesgado que en los proyectos en los que el código solo existía en el servidor, sin documentación.
¿En qué orden conviene realizar la entrega del código?
La entrega del código es segura si primero se copia toda la base de código y la base de datos a un repositorio independiente propiedad del cliente, y solo después se comunica oficialmente el cambio. ¿Para quién es adecuado este orden? Para toda empresa que quiera evitar que, en el tenso periodo posterior al anuncio, la agencia saliente ralentice o dificulte la entrega. La auditoría de código se realiza a continuación sobre el código que ya está en poder del cliente, de modo que el nuevo equipo puede evaluar el estado del sistema de forma imparcial y con acceso completo, incluida la situación actual de la integración con el ERP y del entorno de servidores.
| Paso | Objetivo | Riesgo crítico |
| Toma de control de los accesos | Dominio, servidor, administración y pagos en tus manos | Accesos perdidos o retenidos |
| Copia de la base de código | Todo el código y la base de datos en un repositorio propio | Desarrollos a medida sin documentar |
| Auditoría de código | Evaluación del estado con el nuevo equipo | Informe incompleto o sesgado |
| Anuncio discreto | Comunicación oficial del cambio al antiguo socio | Periodo de entrega tenso y prolongado |
Transición discreta: cómo evitar las interrupciones
La clave de una transición discreta es que ni los usuarios finales ni la operativa diaria noten nada del cambio que se produce entre bastidores, y eso solo es posible si el nuevo equipo obtiene una visión completa del sistema antes del anuncio oficial. Según nuestra experiencia, la mayoría de los clientes evita las interrupciones cuando no programa el cambio para un único momento decisivo, sino que planifica un periodo de transición en paralelo de unas semanas, durante el cual el nuevo equipo ya trabaja en segundo plano pero el acceso de la agencia saliente todavía no se ha retirado por completo.
¿Qué debes tener en cuenta si cambias de agencia Magento por primera vez?
Antes de comunicar el cambio a tu socio actual, conviene aclarar las condiciones de rescisión del contrato, porque un plazo de preaviso largo o una cláusula de penalización influyen considerablemente en el calendario y en el momento en que puedes empezar a trabajar abiertamente con el nuevo equipo. ¿Merece la pena que las pequeñas empresas actúen con tanta cautela? Sí, porque unas pocas horas de caída inesperada en una tienda online activa suponen una pérdida inmediata de ingresos, sea cual sea el tamaño de la empresa, y una transición discreta y bien preparada reduce este riesgo al mínimo.
Para que el cambio de agencia salga bien y sin interrupciones, conviene seguir estos pasos en orden:
- Poner los accesos críticos (dominio, servidor, administración, pasarelas de pago) bajo tu propiedad.
- Hacer una copia de toda la base de código y la base de datos en un repositorio propio e independiente.
- Implicar al nuevo equipo de desarrollo en una auditoría de código imparcial.
- Planificar un periodo de transición en paralelo breve, de unas semanas.
- Comunicar oficialmente el cambio a la agencia actual, solo después de los pasos anteriores.
Al preparar el cambio, conviene tener en cuenta sin falta estos aspectos:
- El plazo de preaviso del contrato y las posibles penalizaciones.
- La titularidad de las licencias y de los módulos de terceros.
- Las obligaciones de protección de datos y confidencialidad, tanto con el socio saliente como con el nuevo.
- La continuidad del mantenimiento de Magento durante y después del cambio.
- El tiempo de respuesta del nuevo equipo ante un error crítico durante el periodo de transición.
Condiciones legales y de confidencialidad antes de cambiar de agencia
Aclarar el marco legal suele quedar relegado frente a la preparación técnica, aunque un acuerdo de confidencialidad mal redactado o inexistente puede suponer un riesgo serio tanto con el socio saliente como con el nuevo. Según nuestra experiencia, la mayoría de los directivos solo se da cuenta de ello cuando el cambio ya está en marcha, y es entonces cuando descubre que el contrato actual incluye una cláusula de exclusividad o de no competencia que limita cuándo y cómo se puede incorporar al nuevo equipo de desarrollo. En los casos que hemos analizado, los cambios se desarrollaron de forma segura también desde el punto de vista legal cuando el directivo había hecho revisar el contrato por un experto antes de tomar la decisión y sabía exactamente qué plazo de preaviso y qué obligaciones de protección de datos se aplicaban al proceso.
¿A qué trampas contractuales conviene prestar especial atención?
La trampa contractual más habitual es la cláusula de renovación tácita, que vincula automáticamente al cliente durante un nuevo periodo si no rescinde el contrato a tiempo, así como la disposición que reserva a la agencia la propiedad intelectual del código desarrollado. ¿Cuándo no se recomienda seguir adelante sin firmar nada? Cuando el contrato no establece claramente que el código fuente de los desarrollos a medida encargados pasa a ser propiedad del cliente, porque sin ello la entrega del código puede volverse también discutible desde el punto de vista legal, aunque técnicamente se disponga de una copia de los archivos.
Estrategia de comunicación con el equipo saliente y el nuevo
El momento y el contenido de la comunicación determinan el éxito del cambio tanto como los propios pasos técnicos, porque un anuncio hecho en un momento inoportuno puede complicar innecesariamente la entrega. Según nuestra experiencia, la mayoría de los clientes evita situaciones conflictivas cuando mantiene un tono profesional y objetivo con la agencia saliente y solo hace el anuncio después de que todos los accesos críticos y la base de código estén ya a salvo bajo su propia gestión. Hemos observado esta relación en varios proyectos: cuando el cliente había preparado de antemano un calendario de entrega breve y concreto y lo compartía con el equipo saliente al mismo tiempo que el anuncio, la colaboración se mantuvo constructiva durante todo el plazo de preaviso.
¿Qué debe incluir la comunicación del anuncio?
La comunicación del anuncio debe incluir la fecha exacta del cambio, la aceptación de las condiciones de rescisión previstas en el contrato y una solicitud concreta para programar la entrega de la documentación técnica pendiente y la transferencia de conocimiento. ¿Conviene explicar con detalle a la agencia saliente los motivos del cambio? No es imprescindible, porque una explicación detallada a menudo genera discusiones innecesarias; basta con una comunicación breve y objetiva, basada en una decisión de negocio, que se centre en la entrega legal y técnica.
La incorporación del nuevo equipo al proyecto en marcha
La incorporación del nuevo equipo de desarrollo transcurre sin problemas si recibe los resultados de la auditoría de código antes de sus primeros días de trabajo y no tiene que ir descubriendo las particularidades del sistema sobre la marcha. En buena parte de los casos hemos comprobado que la mayoría de los retrasos y malentendidos de las primeras semanas tras el cambio se deben a que el nuevo equipo no conoce el contexto de las decisiones de negocio anteriores, por ejemplo, por qué una determinada funcionalidad se implementó de una manera concreta. Según nuestra experiencia, este riesgo se reduce considerablemente si el cliente recoge ya durante la entrega el contexto de negocio más importante en un documento breve y estructurado.
¿Cómo se minimiza el riesgo durante el periodo de incorporación?
Para minimizar el riesgo durante el periodo de incorporación, conviene prever una breve fase de observación de dos o tres semanas, durante la cual el nuevo equipo solo corrige errores críticos y no inicia cambios estructurales de envergadura. ¿Para quién no es recomendable lanzar desarrollos inmediatos y de gran volumen tras el cambio? Para las empresas en las que la estabilidad del sistema es especialmente importante, porque en un sistema desconocido es más arriesgado alterar un estado que funciona bien, aunque no sea perfecto, que irlo perfeccionando poco a poco tras conocerlo.
¿Qué estrategia de cambio es realmente la acertada?
La decisión acertada nunca es cerrar el contrato anterior lo más rápido posible, sino ordenar los accesos, la entrega del código y las condiciones legales en una secuencia que ponga al cliente en una posición de control incluso antes de comunicar formalmente el cambio a la agencia saliente. Cada paso debe respetar los derechos contractuales del cliente y sus obligaciones de protección de datos: copiar el código y la base de datos solo es lícito si el contrato lo permite, y los datos personales deben tratarse conforme al RGPD. Según nuestra experiencia, lo que tienen en común la mayoría de los cambios de agencia Magento con éxito es que el directivo no empezó el proceso con el anuncio, sino asegurando en segundo plano y en silencio la propiedad del dominio, el servidor, el panel de administración y la base de código, y solo después contactó con el nuevo equipo para realizar la auditoría de código. En buena parte de los casos, esta secuencia (accesos, copia del código, auditoría y solo después el anuncio oficial) fue lo que decidió si el cambio degeneraba en un conflicto tenso y prolongado o se desarrollaba de forma discreta y sin incidencias. Es importante que la aclaración del marco legal (el plazo de preaviso, la propiedad intelectual y las obligaciones de confidencialidad) tenga el mismo peso que los pasos técnicos, porque incluso una entrega de código bien preparada puede perder su valor en una situación contractual poco clara.
Según nuestra experiencia, el error más habitual es que el directivo programe el cambio para un único momento decisivo en lugar de planificar un breve periodo de transición de unas semanas, durante el cual el nuevo equipo ya va conociendo el sistema mientras la operativa diaria continúa sin interrupciones. ¿Para quién no es recomendable un cambio precipitado y sin una preparación minuciosa? Para las empresas cuya tienda online es su principal canal de ingresos, porque en su caso un solo paso apresurado puede causar un daño de negocio directo e inmediato. La decisión realmente acertada, por tanto, no depende de un único truco técnico, sino de que la protección de los accesos, la auditoría de código, la clarificación legal y una transición discreta y gradual se lleven a cabo juntas, como pasos que se apoyan unos en otros. Esta es la estructura que da a la tienda online con Magento las mejores posibilidades de seguir funcionando de forma estable y sin interrupciones durante todo el cambio.
