Un vendedor abre una ficha para consultar un pedido; una persona de soporte revisa una garantía sin salir del registro del cliente. Si esas funciones dependen de una CRM Card heredada de HubSpot, su continuidad merece una revisión antes de que termine octubre. El cambio afecta a una pieza de la interfaz que puede parecer pequeña, pero sostener una tarea diaria.
HubSpot está retirando las CRM Cards clásicas y orienta su reemplazo hacia App Cards basadas en React. La primera decisión es identificar si una integración utiliza ese framework. No corresponde tratar todas las tarjetas visibles del sistema de gestión de relaciones con clientes (CRM) como si estuvieran afectadas.
El calendario requiere leer dos documentos
El anuncio original de HubSpot fija el retiro para el 31 de octubre de 2026. Describe tarjetas clásicas limitadas a la barra lateral derecha y explica la transición a extensiones más interactivas. Ese es el calendario que alimentó muchas alertas iniciales.
La guía operativa de migración precisa que las tarjetas se eliminarán de las vistas de clientes el 2 de noviembre de 2026. También indica que la interfaz y la API de migración seguirán disponibles hasta el 1 de diciembre de 2026 y se discontinuarán después. Esa ventana adicional no evita la interrupción de las vistas.
Los documentos oficiales, por tanto, muestran fechas diferentes. Como criterio de planificación, conviene completar las pruebas antes del 31 de octubre y confirmar cualquier duda con el proveedor. Esperar hasta diciembre confundiría la disponibilidad de una herramienta de recuperación con la continuidad del servicio.
Hay otro calendario distinto: las exigencias de publicación y certificación del Marketplace. Desde el 2 de noviembre de 2026, HubSpot exige versiones soportadas de la plataforma para esos procesos. Cumplir una revisión del Marketplace y sustituir una tarjeta son trabajos relacionados, pero no equivalentes.
Identificar la dependencia antes de tocarla
El administrador puede reconocer qué panel usa el equipo, pero el desarrollador o proveedor debe confirmar su implementación. Una captura de pantalla sirve para ubicar la función; por sí sola no identifica el framework.
Proponemos un inventario breve por integración: nombre de la tarjeta, aplicación responsable, registros donde aparece, información consultada, acciones ejecutadas y persona que puede modificarla. Añadir una tarea concreta evita una auditoría puramente visual: «consultar el estado del último pedido» resulta más verificable que «revisar integración comercial».
| Situación encontrada | Primera acción propuesta | Evidencia que conviene pedir |
|---|---|---|
| Aplicación de un proveedor. | Solicitar confirmación de impacto y plan de reemplazo. | Versión entregada, fecha y prueba de la tarea habitual. |
| Integración propia con mantenimiento activo. | Asignar responsable técnico y usuario de prueba. | Inventario de datos, acciones y dependencias. |
| Desarrollo antiguo sin responsable. | Localizar código, documentación y titular de la aplicación. | Acceso legítimo y capacidad real de mantener el servicio. |
| Tarjeta que ya nadie utiliza. | Confirmar su desuso con los equipos afectados. | Validación de que ninguna tarea crítica depende de ella. |
El costo relevante es la tarea que quedaría interrumpida. En un ejemplo hipotético, perder una consulta de pedidos obliga a abrir otro sistema; perder una acción de soporte puede detener una resolución. Esa diferencia debería orientar el orden de trabajo.
Elegir entre continuidad y rediseño
HubSpot ofrece un Legacy CRM Card Converter de ejemplo. Obtiene información desde un endpoint configurable y la muestra con bloques, contenido expandible y botones. Su configuración incluye definición de la tarjeta, tipos de objetos y direcciones permitidas. Es una base de implementación, no una conversión automática que garantice compatibilidad.
El ejemplo también documenta ajustes en el servidor para ciertas acciones POST, PUT o PATCH que dependen de parámetros. Por eso, copiar el aspecto del panel puede dejar incompleta la migración: una consulta que carga correctamente no demuestra que un botón escriba el resultado esperado.
Para un equipo con poco margen, sugerimos priorizar equivalencia funcional: los mismos datos necesarios, las mismas acciones autorizadas y mensajes comprensibles cuando algo falla. Las mejoras de diseño pueden organizarse en una segunda entrega. Si una función antigua ya genera errores o trabajo manual, conviene documentarlo para no reproducirla sin revisión.
La guía exige una aplicación sobre el framework de proyectos, versión 2025.2 o posterior, y recomienda probar en un entorno separado. Para tarjetas de tickets distingue ubicaciones de CRM y help desk. También advierte que la migración de vistas, una vez iniciada, no se puede revertir. El reemplazo masivo debe llegar después de las pruebas.
Una prueba útil reproduce el trabajo real
El siguiente checklist es una propuesta editorial para aceptar el cambio; debe adaptarse al funcionamiento de cada aplicación.
- Consulta: abrir registros con datos completos, incompletos y sin resultados. Comprobar que cada estado se entiende.
- Acciones: ejecutar una operación de prueba y revisar su resultado en el sistema de destino, no solo el mensaje de la tarjeta.
- Permisos: probar con perfiles de uso habituales. Una validación hecha únicamente por un administrador puede ocultar restricciones.
- Errores: simular una respuesta lenta o fallida en un entorno controlado. Verificar qué ve el usuario y cómo puede continuar.
- Datos: contrastar identificadores y valores con la fuente. Una ficha correcta con información de otro cliente sigue siendo un fallo.
- Operación: pedir a una persona del equipo que complete la tarea sin indicaciones del desarrollador y registrar dónde se detiene.
Por ejemplo, una tarjeta de pedidos podría mostrar importe, estado y un enlace al detalle. La aceptación debería comprobar que el pedido corresponde al contacto abierto, que el enlace lleva al destino correcto y que un usuario sin permiso recibe una respuesta adecuada. «Se ve bien» sería una evidencia demasiado débil.
Preparar el día del cambio
Antes de sustituir la tarjeta, conviene acordar quién verifica, quién recibe incidencias y cuál es la vía alternativa para las tareas imprescindibles. Puede ser el acceso directo al sistema de pedidos o una consulta al equipo de soporte; debe estar disponible y ser conocida.
Después, registrar el resultado con fecha, versión y tarea probada permite distinguir una entrega técnica de una aceptación operativa. Si aparece un fallo, describir registro, perfil y acción ayuda mucho más que informar «la integración no funciona».
La misma disciplina sirve para futuras actualizaciones: mantener un dueño por integración, revisar avisos del proveedor y conservar una lista corta de pruebas críticas. Para situar estas dependencias dentro de una decisión más amplia de plataforma, puede servir nuestra guía sobre qué incluye HubSpot Starter y cuándo revisar el plan.
Preguntas frecuentes
¿El retiro afecta a todas las tarjetas de HubSpot?
No. Afecta a las CRM Cards clásicas o heredadas. Antes de intervenir una integración, su responsable debe confirmar qué tecnología utiliza y qué funciones dependen de ella.
¿Qué fecha debo considerar para evitar una interrupción?
El anuncio original señala el 31 de octubre de 2026; la guía operativa sitúa la eliminación de las vistas el 2 de noviembre de 2026. Conviene terminar y verificar la migración antes del primer plazo.
¿Basta con instalar el Legacy CRM Card Converter?
No. Es un ejemplo técnico que debe adaptarse y probarse con los datos, acciones y permisos de cada integración. Una apariencia similar no demuestra que el proceso completo funcione.
¿Quién debe hacerse cargo si la aplicación es de un proveedor?
El proveedor debe confirmar el alcance y la entrega de su reemplazo. La empresa usuaria debería designar a alguien para probar las tareas críticas y conservar un canal alternativo mientras verifica el cambio.
La Tesis de El Ciclo
Nuestra interpretación es que estas migraciones revelan una dependencia que muchas empresas gestionan de forma implícita: una interfaz externa termina convirtiéndose en parte del proceso interno. Cuando cambia, el problema deja de pertenecer únicamente al desarrollador.
La oportunidad está en hacer visible esa relación. Saber qué tarea sostiene cada integración, quién responde por ella y cómo se comprueba su funcionamiento convierte una fecha de retiro en una mejora de gestión. La continuidad depende tanto del código como de esa responsabilidad compartida.
Editor | El Ciclo Tomás Carmona es especialista en crecimiento de negocios, transformación digital y sistemas CRM. En El Ciclo investiga y explica cómo los cambios en tecnología, inteligencia artificial, negocios, finanzas y salud impactan la vida de las personas y las empresas. Su trabajo combina análisis, investigación y experiencia práctica para transformar noticias, estudios y tendencias en contenido claro, basado en evidencia y orientado a la toma de mejores decisiones. Su objetivo es ayudar a los lectores a comprender qué está cambiando, por qué es relevante y cómo esos cambios pueden influir en su trabajo, sus finanzas, su salud o su vida cotidiana.