Takeover de un Magento heredado: checklist de los primeros 30 días

• Días 1 a 3: congela cambios, confirma accesos y prueba que el respaldo se restaura en otro servidor.
• Semana 1: versión, parches, usuarios del admin, llave de cifrado y escaneo de malware.
• Semana 2: código heredado: Composer, módulos, cambios al núcleo y ambientes.
• Semana 3: operación: cron, indexadores, colas, logs e integraciones.
• Semana 4: línea base de rendimiento y SEO, documentación y plan priorizado.

En este artículo:

• Qué es un takeover de Magento y dónde empieza esta guía
• Días 1 a 3: congelar, asegurar y respaldar
• Semana 1: versión, parches y seguridad
• Semana 2: código heredado y ambientes
• Semana 3: cron, indexadores, colas, logs e integraciones
• Semana 4: rendimiento, SEO y plan priorizado
• Tabla resumen de los 30 días
• Cuándo no conviene este enfoque
• Preguntas frecuentes

Un takeover de Magento es el momento en que un equipo nuevo recibe una tienda Magento 2 o Adobe Commerce que construyó otra agencia. Los primeros 30 días definen si heredas un sistema controlado o una lista de sorpresas. Esta guía es el checklist técnico, semana por semana, para ese primer mes.

Si todavía no cambias de proveedor, empieza por cómo cambiar de agencia Magento sin perder tu tienda. Ahí explicamos cómo recuperar accesos, revisar el contrato y planear el traspaso. Aquí asumimos que el traspaso ya ocurrió y que ahora la tienda es tu responsabilidad.

¿Qué debo hacer en los primeros 3 días de un takeover de Magento?

Tres cosas, en este orden: congelar cambios, confirmar que el control es tuyo y tener un respaldo que funcione. Nada de esto mejora la tienda, pero evita que el primer incidente te tome sin red.

Congela cambios que no sean de seguridad

Durante el primer mes no instales módulos nuevos ni cambies el tema. Cada cambio de un equipo que aún no conoce el código es un riesgo extra. La excepción son los parches de seguridad urgentes. Si el takeover cae cerca de temporada alta, revisa también nuestro checklist técnico de Buen Fin.

Haz el inventario de accesos y dueños

Arma una tabla con cada sistema, quién es el dueño de la cuenta y quién tiene acceso hoy. Incluye repositorio, servidor y SSH, base de datos, panel de Magento, DNS, CDN, pasarelas de pago, correo transaccional y cuentas de licencias de módulos.

Agrega una columna clave: cómo se revoca. Si no sabes cómo quitarle un acceso a la agencia anterior, todavía no tienes el control.

Respalda y prueba la restauración

Tener archivos de respaldo no es lo mismo que poder volver a vender. Respalda código, base de datos y la carpeta pub/media, y restáuralos en un servidor aparte. Si la tienda levanta ahí, tienes plan B.

No dependas del comando bin/magento setup:backup. Adobe indica que esa función está obsoleta desde las versiones 2.1.16, 2.2.7 y 2.3.0. Recomienda herramientas de respaldo binario como Percona XtraBackup. Usa también los respaldos de tu hosting, pero pruébalos igual.

Semana 1: ¿en qué versión está la tienda y qué parches le faltan?

La primera semana responde una pregunta de negocio: ¿la tienda tiene huecos de seguridad conocidos hoy? Para contestarla necesitas la versión exacta, los parches aplicados y el estado de sus dependencias.

# Versión y modo de ejecución
bin/magento --version
bin/magento deploy:mode:show

# Parches individuales aplicados y disponibles
./vendor/bin/magento-patches status

# Base de datos y esquema al día con el código
bin/magento setup:db:status

Compara contra el calendario de soporte

Adobe da tres años de soporte estándar desde el lanzamiento de cada versión. Adobe Commerce 2.4.6 terminó su soporte estándar el 11 de agosto de 2026. 2.4.7 lo termina el 31 de mayo de 2027, según la política de ciclo de vida de Adobe.

En Magento Open Source el margen es menor. El boletín de octubre de 2026 incluye Open Source solo de 2.4.6 a 2.4.9. Si heredas una 2.4.5 o anterior en Open Source, ya no recibe esos parches. El detalle completo de fechas está en nuestra guía de Magento 2.4.x en 2026.

Revisa PHP y servicios, no solo Magento

Adobe aclara que no corrige dependencias de terceros como PHP, MariaDB u OpenSearch. PHP 8.1 llegó a fin de vida el 31 de diciembre de 2025 y PHP 8.2 llega el 31 de diciembre de 2026. Adobe advierte que seguir en esas versiones pone en riesgo el cumplimiento PCI.

También revisa el buscador. Adobe marca el fin de soporte de Elasticsearch 7.17 el 15 de enero de 2026 y pide migrar a OpenSearch. Valida cada servicio contra los requisitos del sistema de tu versión.

Aplica lo urgente: el hotfix de CVE-2026-75650

El 7 de septiembre de 2026 Adobe publicó el boletín APSB26-146 por una falla crítica que permite ejecutar código sin autenticación. Adobe confirmó que se estaba explotando. El hotfix va aparte de los parches mensuales y Adobe pide rotar la llave de cifrado y las credenciales.

El 13 de octubre salió APSB26-153, con fallas críticas, altas y medias. Si la tienda heredada no tiene ninguno de los dos, esa es tu prioridad número uno. Prueba primero en staging, como recomienda Adobe para cualquier parche.

Audita usuarios, llaves y malware

• Usuarios del admin: desactiva cuentas de la agencia anterior y de personas que ya no están. Confirma que la autenticación de dos factores siga activa.
• Integraciones y API: revisa tokens de integración, usuarios SSH y llaves de despliegue. Cámbialos si la agencia anterior los conocía.
• Llave de cifrado: vive en app/etc/env.php y protege contraseñas e integraciones de pago. Desde 2.4.8 se cambia solo por CLI con bin/magento encryption:key:change.
• Escaneo: registra el dominio en el Security Scan Tool de Adobe. Es gratuito para Adobe Commerce y Magento Open Source.
• Archivos y base de datos: busca scripts desconocidos en pub/ y código inyectado en bloques CMS y configuración.

Rotar la llave cierra las sesiones de clientes y administradores. Hazlo en una ventana de bajo tráfico y avisa al equipo. Si quieres entender el contexto de las fallas recientes, lee PHP2Shell y las fallas de PHP en 2026.

Semana 2: ¿qué código heredaste realmente?

Aquí descubres cuánto cuesta mantener la tienda. Dos tiendas con la misma versión pueden tener costos muy distintos según cómo se hicieron las personalizaciones.

Composer y módulos de terceros

# Módulos instalados y desactivados
bin/magento module:status
bin/magento module:status --disabled

# Paquetes y versiones según composer.lock
composer show
composer outdated

Para cada módulo de terceros anota cuatro datos: si se usa, quién lo vende y si la licencia está a tu nombre. El cuarto: si tiene versión compatible con tu siguiente actualización. Un módulo sin soporte del fabricante suele ser el que bloquea el upgrade.

Cambios al núcleo y a vendor

La mala práctica más cara de un Magento heredado es modificar archivos dentro de vendor/ o del núcleo. Esos cambios se pierden en cada actualización y nadie los documenta.

• Instala una copia limpia con el mismo composer.lock y compara la carpeta vendor/ contra producción.
• Revisa app/code: ahí deben vivir los módulos propios, cada uno con su propósito claro.
• Busca plantillas sobrescritas en app/design que copian archivos completos del tema base.
• Cuenta los parches locales en composer.json. Adobe advierte que acumular muchos parches complica las actualizaciones.

Ambientes y despliegue

Confirma que existe un staging con una copia reciente y sin datos personales reales. Revisa que producción corra en modo production y que el despliegue sea repetible desde el repositorio. Si alguien sube archivos por FTP directo a producción, eso se corrige antes que cualquier mejora.

Semana 3: ¿cron, indexadores, colas e integraciones funcionan?

Muchos síntomas de negocio vienen de aquí: precios que no se actualizan, correos que no salen, stock que no cuadra. Es la semana de revisar la operación que nadie ve.

# Estado de los indexadores
bin/magento indexer:status
bin/magento indexer:show-mode

# Consumidores de colas disponibles
bin/magento queue:consumers:list

• Cron: confirma que corre con bin/magento cron:install y revisa la tabla cron_schedule. Busca tareas en error o atoradas en estado running.
• Indexadores: que ninguno quede como invalid o con backlog creciente. En catálogos grandes, revisa que el modo sea Update by Schedule.
• Colas: Adobe documenta qué consumidores necesita cada función. Por ejemplo, inventory.reservations.updateSalabilityStatus debe estar siempre activo si usas Inventory Management.
• Logs: revisa var/log/system.log, var/log/exception.log y var/report, además de los logs del servidor web y de PHP.
• Integraciones: ERP, pasarelas de pago, paqueterías y facturación. Documenta qué dispara cada sincronización, qué pasa si falla y quién recibe la alerta.

Para integraciones complejas, como ERP o marketplaces, conviene un diagrama simple de flujos. Nuestro equipo de integraciones Magento parte siempre de ese mapa.

Semana 4: ¿cómo mido rendimiento y SEO antes de cambiar algo?

Sin línea base no puedes demostrar mejoras ni detectar regresiones. Esta semana mides; no optimizas todavía.

Rendimiento

• Core Web Vitals: Google considera bueno un LCP de hasta 2.5 segundos, un INP de hasta 200 ms y un CLS de hasta 0.1. Se miden en el percentil 75.
• Caché de página: confirma si Varnish está activo y qué porcentaje de solicitudes sirve. Las versiones 2.4.8 y 2.4.9 listan Varnish 8 en sus requisitos.
• Caché y sesiones: revisa si usas Redis o Valkey. Adobe ya lista Valkey en los requisitos de las versiones recientes.
• Servidor: tiempo de respuesta del backend (TTFB), uso de CPU y memoria en horas pico, y configuración de OPcache.

Si el hosting es parte del problema, compara opciones con nuestra guía de hosting Magento en México.

SEO

• Exporta las URLs indexadas y las que reciben tráfico orgánico.
• Revisa errores de rastreo, redirecciones en cadena y páginas 404 con tráfico.
• Guarda el robots.txt, el sitemap y las reglas de URL reescritas actuales.
• Anota los datos estructurados de producto y categoría que ya existen.

Este respaldo de SEO te protege en el siguiente paso: cualquier upgrade o rediseño se compara contra esta foto.

Documentación y plan priorizado

El entregable del día 30 no es una lista de 200 problemas. Es un documento corto con el estado de la tienda y un plan ordenado por riesgo y por impacto en ventas.

1. Riesgo crítico: parches faltantes, accesos sin revocar, respaldos que no restauran.
2. Riesgo alto: versión o PHP fuera de soporte, módulos abandonados, cambios al núcleo.
3. Impacto en ventas: checkout, velocidad móvil, integraciones de stock y precio.
4. Deuda técnica: limpieza de código, documentación y automatización de despliegues.

Con ese plan, el upgrade deja de ser un salto al vacío. Para esa etapa, revisa cómo actualizar Magento sin perder datos ni romper integraciones.

Resumen: checklist de los primeros 30 días

¿Cuándo no conviene este enfoque de 30 días?

No siempre aplica tal cual. Si la tienda está caída o comprometida, primero va la respuesta a incidentes: contener, limpiar y rotar credenciales. El checklist viene después.

Tampoco conviene si la tienda sigue en Magento 1. Ahí la conversación es de migración a Magento 2, no de takeover. Y si el negocio ya decidió cambiar de plataforma, limita el mes a seguridad y respaldos.

¿Cómo lo hacemos en Panamerik?

En Panamerik trabajamos con Magento, Adobe Commerce y Hyvä. En un takeover de tienda Magento seguimos este orden: control, seguridad, código, operación y plan. Usamos IA en auditorías de seguridad y en la corrección de errores. Una persona del equipo revisa cada hallazgo y cada cambio antes de que toque producción. Lo explicamos en cómo proteger Magento con inteligencia artificial.

Hemos atendido casos como PHP2Shell, StyleSmuggler y BlockStrap. No prometemos un tiempo fijo para parches: depende del caso y de cuándo el fabricante libera la corrección. Trabajamos de la mano con Cloudways y usamos el Cloudflare Enterprise incluido en sus servidores. Después del primer mes, el trabajo continúa como soporte Magento con prioridades claras.

Conclusión

Un takeover de Magento sale bien cuando el primer mes se dedica a ganar control, no a lucirse con cambios. Accesos, respaldos y parches primero; código y operación después; medición al final.

El resultado es un plan que puedes defender ante tu dirección, con riesgos y costos claros. Si aún no haces el cambio de proveedor, empieza por la guía para cambiar de agencia Magento.

Sobre el autor

Panamerik dirige Panamerik, agencia especializada en Magento y Adobe Commerce desde Guadalajara. Su equipo diseña, desarrolla, integra y da soporte a tiendas en línea.

Fuentes

• Adobe Experience League: Lifecycle policy (actualizada el 18 de septiembre de 2026)
• Adobe Experience League: System requirements (actualizada el 13 de octubre de 2026)
• Adobe Experience League: Patch release schedule (actualizada el 8 de octubre de 2026)
• Adobe Security Bulletin APSB26-146 (7 de septiembre de 2026)
• Adobe Experience League: Urgent action required, APSB26-146 (actualizada el 21 de septiembre de 2026)
• Adobe Security Bulletin APSB26-153 (13 de octubre de 2026)
• Adobe Experience League: Quality Patches Tool, installation and usage (consultado el 27 de octubre de 2026)
• Adobe Experience League: Backup and rollback (consultado el 27 de octubre de 2026)
• Adobe Experience League: Encryption key (consultado el 27 de octubre de 2026)
• Adobe Experience League: Security scan (consultado el 27 de octubre de 2026)
• Adobe Experience League: Two-factor authentication (consultado el 27 de octubre de 2026)
• Adobe Experience League: Manage the indexers (consultado el 27 de octubre de 2026)
• Adobe Experience League: Configure and run cron (consultado el 27 de octubre de 2026)
• Adobe Experience League: Message queue consumers (consultado el 27 de octubre de 2026)
• Adobe Experience League: Application modes (consultado el 27 de octubre de 2026)
• web.dev: Web Vitals (consultado el 27 de octubre de 2026)
• PHP: Supported versions (consultado el 27 de octubre de 2026)