De Adobe Commerce a Mage-OS: la ruta sin downtime
"Downtime cero" suena a frase de folleto. No lo es: es una consecuencia de planear el cutover con meses de anticipación y de tratar el SEO como parte de la ingeniería, no como un parche del final.
// assets/blog/migracion-cover.jpg
Cuando un cliente nos escribe pidiendo salir de Adobe Commerce, casi nunca la conversación empieza por la tecnología. Empieza por la factura. Llega el correo de renovación, alguien hace la cuenta de lo que pagó el año pasado contra lo que de verdad usó de la plataforma, y la pregunta cae sola: ¿de verdad necesito esto?
La respuesta, la mayoría de las veces, es no. Pero entre tomar esa decisión y tener la tienda corriendo sobre Mage-OS hay un trecho que da miedo. Y con razón. Mover un e-commerce en producción es operación a corazón abierto: el paciente tiene que seguir vendiendo mientras lo intervienes. Aquí es donde se separan los proyectos que salen bien de los que terminan en una noche de domingo con todo el equipo conectado rezándole al checkout.
Te cuento cómo lo hacemos, sin endulzarlo.
Primero, una verdad incómoda: el cutover es la parte fácil
Suena al revés, lo sé. La gente le tiene pánico al momento de "prender el switch". Pero si el día del cambio te estás enterando de cosas, el problema no es el cutover: es que llegaste mal preparado. El cutover bien hecho es aburrido. Es el último paso de una lista que ya validaste tres veces.
El trabajo de verdad ocurre semanas antes, en la auditoría. Ahí es donde sudas. Tienes que entender qué tan profundo se metió la tienda actual en cosas propietarias de Adobe Commerce —B2B, segmentación de clientes, staging de contenido, las reglas de precio "avanzadas"— porque cada una de esas piezas necesita un equivalente del lado open source. Algunas las cubre Mage-OS de fábrica. Otras hay que construirlas. Y unas cuantas, sinceramente, nadie las estaba usando y lo mejor es dejarlas morir.
Migrar no es copiar. Es decidir qué se queda, qué se reemplaza y qué se entierra. Esa decisión es del negocio, no del servidor.
El catálogo no es lo difícil. Las URLs sí.
Mover productos, categorías, clientes y pedidos es, técnicamente, un problema resuelto. El modelo EAV de Magento es el mismo en Adobe Commerce, en Magento Open Source y en Mage-OS, porque comparten núcleo. Eso significa que tu catálogo viaja prácticamente intacto.
Donde se cae la gente es en el SEO. Tienes años de tráfico orgánico acumulado en URLs que Google ya indexó, rankeó y aprendió a confiar. Si migras y esas URLs cambian sin avisar, Google lo lee como una tienda nueva que apareció de la nada. Y te castiga. He visto migraciones "exitosas" técnicamente que tiraron el 40% del tráfico orgánico en dos semanas porque a nadie se le ocurrió revisar los url rewrites.
Por eso, en nuestro plan, los 301 y la tabla de rewrites no son una tarea del final: son parte del diseño desde el día uno. Antes de tocar nada, sacamos el inventario completo de URLs vivas, las mapeamos contra el destino, y cualquier ruta que cambie se redirige con un 301 permanente. Sin excepciones.
Staging: tu red de seguridad
Todo —y cuando digo todo, es todo— se construye primero en un ambiente de staging que es copia fiel de producción. Instalación limpia de Mage-OS vía Composer, migración de módulos, el theme (sea conservar Luma o saltar a Hyvä), los datos completos. Ahí corremos QA de verdad: funcional, de regresión, el checkout con pagos reales en sandbox, las integraciones con el ERP, la facturación.
Staging es donde te puedes equivocar gratis. Es el lujo de romper algo a las 3 de la tarde de un martes en lugar de a las 11 de la noche de un sábado con clientes reales del otro lado. Cualquiera que te ofrezca migrar "directo a producción para ahorrar tiempo" te está ofreciendo ahorrarse su tiempo, no protegiendo el tuyo.
El día del cambio
Para cuando llega el cutover, ya no hay sorpresas técnicas. Lo que queda es coreografía: una ventana acordada, una sincronización final de los datos que cambiaron desde el último corte (pedidos nuevos, clientes nuevos), el cambio de DNS, y la verificación contra una checklist que ya conocemos de memoria.
# corte final + verificación $ bin/magento maintenance:enable $ # sync delta de pedidos y clientes $ bin/magento setup:upgrade && bin/magento setup:di:compile $ bin/magento cache:flush $ # smoke test: home, PDP, carrito, checkout, login $ bin/magento maintenance:disable
Los primeros días post-launch no nos vamos. Monitoreamos de cerca: errores en logs, tiempos de respuesta, que Google empiece a recorrer las nuevas rutas, que los pedidos fluyan. Es la parte menos glamorosa del proyecto y la que más tranquilidad da.
¿Y cuánto tarda todo esto?
La respuesta honesta: depende, y desconfía de quien te dé un número antes de auditar. Una tienda con pocas extensiones y código limpio se mueve rápido. Una con diez años de parches encima, módulos abandonados y customizaciones que nadie documentó es otra historia. Por eso el cronograma se cierra después de la auditoría, no antes. Cualquier otra cosa es adivinar, y adivinar con tu tienda en juego no es nuestro estilo.
Lo que sí te garantizamos es el método: nada sale a producción sin haber vivido primero en staging, y ninguna URL con tráfico se queda sin a dónde ir. El resto es ejecución disciplinada. Aburrida, en el buen sentido.
Si estás haciendo la cuenta de tu próxima renovación de Adobe Commerce y la cifra ya no te cuadra, hablemos. La auditoría inicial es sin costo y al final tienes algo concreto: un plan, los riesgos sobre la mesa y un número.