Cambio de partner Microsoft Dynamics 365
Cambiar de partner Dynamics 365 sin perder control, conocimiento ni continuidad
Una revisión ordenada de accesos, documentación, desarrollos, integraciones, licencias, entornos, incidencias y servicio antes de mover una sola pieza.
Cambiar de partner no debería empezar con una propuesta de mantenimiento. Debería empezar entendiendo qué tienes, qué depende de quién, qué riesgos existen y qué necesita el negocio para seguir operando mientras se produce el traspaso. Ayesa revisa el entorno actual y plantea una transición viable para Business Central, Dynamics 365 Finance, Supply Chain Management, CRM y Power Platform.
Una decisión operativa
Cambiar de partner no es romper con el pasado. Es recuperar capacidad de decisión.
La mayoría de las empresas no se plantea un cambio porque quiera empezar de cero. Lo hace porque la relación actual ha dejado de responder a la realidad del negocio. El soporte tarda demasiado, las mejoras se eternizan, los desarrollos están poco documentados, las integraciones dependen de conocimientos individuales o el sistema funciona, pero no evoluciona.
El riesgo no está únicamente en que una incidencia tarde en resolverse. Está en que cada nueva necesidad se convierta en una negociación difícil, en que nadie pueda explicar con precisión el mapa completo de la solución o en que la empresa quede atrapada entre versiones antiguas, personalizaciones frágiles y decisiones aplazadas.
Una transición bien preparada permite conservar lo que funciona, ordenar lo que está disperso y decidir con criterio qué debe mantenerse, corregirse, modernizarse o retirarse. El objetivo no es cambiar de proveedor por cansancio. Es conseguir un modelo de servicio, gobierno y evolución acorde con la importancia real de la plataforma.
La pregunta correcta
¿Tu partner actual protege el presente y prepara el siguiente paso?
Responder solo incidencias ya no basta cuando Dynamics 365 está conectado con finanzas, operaciones, ventas, servicio, datos, automatización, Microsoft 365, Azure o inteligencia artificial.
Señales que justifican una revisión
No hace falta esperar a que el sistema se convierta en una emergencia.
Una sola señal grave puede justificar una revisión. Varias a la vez indican que la continuidad del servicio y la capacidad de evolución ya están comprometidas.
Respuesta lenta o imprevisible
Incidencias críticas sin plazos claros, consultas que pasan de mano en mano y ausencia de información sobre el estado real de cada petición.
Dependencia de una persona
El conocimiento reside en uno o dos consultores. Cuando no están disponibles, nadie puede explicar el funcionamiento completo del entorno.
Documentación incompleta
No hay inventario fiable de desarrollos, interfaces, procesos críticos, decisiones funcionales, credenciales técnicas o dependencias externas.
Todo termina en un parche
Cada necesidad añade otra excepción, otro desarrollo o una automatización aislada sin revisar el impacto sobre el conjunto.
Falta de transparencia
No se entiende qué se factura, qué entra en el servicio, cómo se estiman los evolutivos o por qué determinadas tareas requieren tantas horas.
El negocio ha superado al proveedor
La empresa ha crecido, opera en más países, tiene más sociedades o procesos más exigentes, pero el modelo de atención sigue siendo el mismo.
Sin conversación de futuro
Nadie plantea modernización, automatización, Power Platform, datos, Copilot, inteligencia artificial o una mejora ordenada de la arquitectura.
El sistema funciona, pero no mejora
La plataforma sigue operativa, aunque los usuarios continúan trabajando con Excel, tareas manuales y decisiones basadas en información tardía.
El riesgo real
Lo peligroso no es cambiar de partner. Es hacerlo sin saber qué debe protegerse.
Una transición no puede depender de una lista improvisada de accesos ni de una reunión de traspaso de dos horas. Necesita inventario, responsables, prioridades, criterios de aceptación, plan de contingencia y una etapa de estabilización con seguimiento real.
Antes del traspaso
Nueve áreas que deben quedar claras antes de asumir el servicio.
El diagnóstico inicial no busca señalar culpables. Busca reducir incertidumbre. Cuanto más transparente sea el punto de partida, más fácil será proteger la operación, dimensionar el servicio y separar necesidades urgentes de mejoras que pueden planificarse.
1. Accesos y propiedad administrativa
Hay que confirmar quién controla el tenant, los centros de administración, los entornos, las suscripciones, las cuentas de servicio, los repositorios de código, las herramientas de despliegue y los portales de soporte. También es necesario revisar roles, permisos privilegiados, usuarios externos y credenciales compartidas. Una empresa no debería descubrir durante una incidencia que una cuenta crítica pertenece al proveedor saliente o que nadie puede recuperar una contraseña de servicio.
2. Documentación funcional y técnica
El traspaso debe localizar manuales, mapas de procesos, decisiones funcionales, especificaciones, diseños técnicos, inventarios de objetos, modelos de datos, procedimientos de operación y actas relevantes. Cuando la documentación no existe, el nuevo equipo debe reconstruirla mediante entrevistas, revisión del sistema y validación con usuarios clave. No es un detalle administrativo: es la base para reducir dependencia y evitar que cada petición empiece desde cero.
3. Personalizaciones y desarrollos
No basta con contar extensiones, objetos, plugins, flujos o componentes. Hay que entender qué problema resuelve cada uno, quién lo usa, qué impacto tiene, cómo se despliega, qué dependencias mantiene y si sigue teniendo sentido. Parte de la deuda técnica suele estar formada por desarrollos que nadie se atreve a retirar porque no existe una visión completa de sus consecuencias. La revisión permite clasificar lo que debe conservarse, corregirse, sustituirse por estándar o retirar.
4. Integraciones y procesos automáticos
ERP, CRM y Power Platform rara vez operan aislados. Existen conexiones con bancos, comercio electrónico, nómina, logística, fabricación, portales, proveedores, sistemas fiscales, herramientas sectoriales, Microsoft 365, Azure, Power BI u otras plataformas. Cada integración debe tener propietario, frecuencia, tecnología, controles, registro de errores, plan de recuperación y persona responsable. Una interfaz invisible hasta que falla es uno de los mayores riesgos de cualquier transición.
5. Entornos, versiones y ciclo de despliegue
Debe quedar claro qué entornos existen, qué finalidad tiene cada uno, cómo se actualizan, quién aprueba los cambios y cómo se pasa de desarrollo a pruebas y producción. También hay que revisar versiones, ventanas de mantenimiento, copias, restauración, capacidad, políticas de retención, herramientas de control de versiones y procedimientos de vuelta atrás. Sin este mapa, una mejora aparentemente pequeña puede convertirse en una interrupción difícil de explicar.
6. Licencias, contratos y relación con Microsoft
La transición debe revisar productos contratados, número y tipo de licencias, renovaciones, compromisos, canales de compra, roles administrativos y posibles servicios asociados. Cambiar de partner de servicio no siempre implica cambiar inmediatamente el canal de licenciamiento, pero ambos temas deben entenderse para evitar duplicidades, renovaciones imprevistas o usuarios mal asignados. El objetivo es que la empresa sepa qué está pagando, para qué se utiliza y quién puede gestionarlo.
7. Incidencias abiertas y calidad del servicio
Hay que recopilar incidencias abiertas, problemas recurrentes, peticiones pendientes, deuda acumulada, tiempos históricos y compromisos adquiridos. Esta información ayuda a identificar qué debe resolverse antes del cambio, qué puede asumirse en la transición y qué requiere una decisión de negocio. También permite distinguir entre fallos puntuales y problemas estructurales del modelo de soporte, la arquitectura o el diseño funcional.
8. Datos, seguridad y cumplimiento
La revisión debe identificar datos sensibles, perfiles de acceso, segregación de funciones, cuentas inactivas, integraciones con identidad, registros de auditoría y obligaciones aplicables. El cambio de partner es un buen momento para retirar accesos que ya no son necesarios, revisar usuarios externos y asegurar que los nuevos permisos siguen el principio de mínimo privilegio. La continuidad no consiste solo en que el sistema arranque: también debe seguir siendo seguro y gobernable.
9. Prioridades de negocio y evolución
Una transición pierde valor si solo replica el servicio anterior. Es necesario entender qué preocupa a dirección, qué procesos generan más fricción, dónde se pierde tiempo, qué información llega tarde y qué cambios están previstos en la organización. Con esa base puede construirse una hoja de ruta realista: estabilizar primero, resolver riesgos después y avanzar hacia automatización, analítica, modernización o nuevas capacidades cuando el entorno esté preparado.
Cómo se plantea la transición
Un cambio ordenado se construye por etapas, con responsables y criterios de salida.
No todos los entornos necesitan el mismo esfuerzo. Una instalación estándar de Business Central no exige el mismo traspaso que un escenario internacional de Finance y Supply Chain con múltiples integraciones. El método debe adaptarse al nivel de criticidad, personalización y dependencia, sin omitir los controles esenciales.
Alineación y gobierno del cambio
Se definen alcance, patrocinador, responsables de negocio y tecnología, interlocutores del partner saliente, fechas clave, restricciones, riesgos conocidos y forma de tomar decisiones. También se aclara qué se espera del nuevo servicio: soporte, continuidad, evolución funcional, modernización, integración o una combinación de varios objetivos.
Inventario y acceso controlado
Se obtiene acceso a los componentes necesarios, se valida la propiedad administrativa y se construye un inventario funcional y técnico. El acceso se concede de forma gradual y trazable, evitando cuentas compartidas o privilegios innecesarios. La revisión identifica dependencias críticas, elementos sin responsable y áreas donde falta información.
Transferencia de conocimiento
Se organizan sesiones por procesos, aplicaciones e integraciones. El objetivo no es acumular reuniones, sino convertir el conocimiento en documentación reutilizable: flujos críticos, calendario operativo, cierres, interfaces, tareas recurrentes, excepciones, desarrollos, incidencias y procedimientos de recuperación. Las lagunas se validan con usuarios clave y responsables técnicos.
Plan de continuidad y toma de servicio
Se acuerda la fecha de responsabilidad efectiva, el tratamiento de peticiones abiertas, los canales de atención, prioridades, escalados, guardias si aplican y comunicación a usuarios. Para procesos críticos se definen contingencias y responsables. El cambio debe ser comprensible para quienes utilizan el sistema: dónde pedir ayuda, quién responde y cómo se informa del avance.
Estabilización y seguimiento intensivo
Durante las primeras semanas se revisan incidencias, tiempos, dudas funcionales, integraciones, trabajos programados y puntos de fricción. Se realizan reuniones de seguimiento con una frecuencia mayor que la del servicio ordinario. Esta etapa sirve para verificar que el nuevo equipo puede operar con autonomía, completar documentación y corregir riesgos detectados durante la toma de servicio.
Hoja de ruta y mejora continua
Con el entorno estabilizado se priorizan acciones por impacto, urgencia, coste y dependencia. Algunas estarán relacionadas con soporte y deuda técnica; otras con simplificación funcional, actualización, automatización, Power Platform, datos, reporting, integración o inteligencia artificial. La empresa obtiene una visión ordenada de qué hacer primero y qué no merece inversión inmediata.
Aplicable a todo el entorno Dynamics 365
La transición cambia según la solución. Los principios de control y continuidad no.
Cada carga de trabajo tiene riesgos específicos. La revisión debe adaptarse al producto, a la arquitectura y al uso real que hace la organización, manteniendo una visión común de usuarios, datos, integraciones, licencias, soporte y evolución.
Dynamics 365 Business Central
La revisión suele centrarse en extensiones, objetos heredados de NAV, integraciones, trabajos programados, informes, aplicaciones de terceros, política de actualización, entornos sandbox y procesos de cierre, compras, ventas, almacén, proyectos o fabricación.
En instalaciones antiguas es especialmente importante diferenciar personalizaciones imprescindibles de código que ya podría sustituirse por funcionalidad estándar, apps o Power Platform.
Dynamics 365 Finance
En escenarios financieros complejos hay que revisar sociedades, localizaciones, consolidación, dimensiones, cierres, tesorería, seguridad por roles, integraciones bancarias, reporting, datos maestros, procesos periódicos y dependencias con Supply Chain u otras aplicaciones.
La continuidad exige coordinar el calendario financiero y evitar cambios de responsabilidad en momentos críticos como cierres mensuales, auditorías o periodos de alta carga.
Dynamics 365 Supply Chain Management
La transición debe conocer planificación, demanda, producción, almacenes, transporte, activos, calidad, dispositivos, interfaces con planta, automatizaciones y procesos que no pueden detenerse. Una incidencia en estos ámbitos puede afectar directamente a entregas, inventario o capacidad productiva.
Es fundamental identificar procesos de alta criticidad, ventanas operativas y mecanismos de contingencia antes de asumir el servicio.
Dynamics 365 CRM
En CRM hay que revisar modelo de datos, formularios, plugins, automatizaciones, seguridad, integraciones con ERP, Outlook, marketing, portales, telefonía, servicio al cliente y herramientas externas. También debe analizarse el uso real: una solución técnicamente estable puede estar fallando por baja adopción o procesos mal diseñados.
El cambio de partner puede servir para recuperar gobierno, calidad del dato, coherencia comercial y capacidad de evolución sin reiniciar todo el proyecto.
Microsoft Power Platform
Power Apps, Power Automate, Power BI, Power Pages y Copilot Studio pueden contener procesos críticos aunque hayan empezado como iniciativas departamentales. La revisión debe identificar propietarios, conexiones, cuentas utilizadas, flujos dependientes, soluciones administradas, entornos, políticas de datos, capacidad, licencias y procedimientos de despliegue.
Sin gobierno, la automatización puede crear nuevas dependencias. Con un modelo ordenado, Power Platform permite evolucionar el entorno sin sobrecargar el núcleo.
Una única visión de servicio
El mayor riesgo aparece cuando ERP, CRM, Power Platform, Azure y Microsoft 365 se gestionan como piezas separadas. Una incidencia puede cruzar varias tecnologías y quedar atrapada entre equipos que solo conocen una parte.
Ayesa puede abordar la revisión desde una visión conectada de aplicaciones, integraciones, datos, identidad, seguridad, operación y evolución.
Una oportunidad de mejora
Cambiar de manos sin cambiar de enfoque solo aplaza el mismo problema.
La transición debe asegurar el servicio actual, pero también revelar qué frena el valor de la plataforma. Cuando el entorno está entendido y estabilizado, pueden priorizarse mejoras reales: simplificar desarrollos, elevar adopción, conectar datos, automatizar procesos, revisar licencias o preparar una modernización.
Riesgos habituales
Qué puede salir mal y cómo se reduce el riesgo.
No existe una transición sin trabajo. Sí existe una transición sin método. La diferencia está en anticipar los puntos de fallo y asignarles una respuesta concreta.
| Riesgo | Consecuencia | Cómo se controla |
|---|---|---|
| Accesos incompletos | Imposibilidad de investigar, desplegar o recuperar servicios críticos. | Inventario de portales, cuentas, roles, repositorios y validación de acceso antes de la toma de responsabilidad. |
| Conocimiento no documentado | Resoluciones lentas y dependencia de entrevistas urgentes. | Sesiones estructuradas, validación con usuarios y documentación viva de procesos e incidencias. |
| Integración desconocida | Fallos en pedidos, cobros, inventario, producción, atención o reporting. | Mapa de interfaces, propietarios, frecuencia, alertas, errores conocidos y procedimiento de recuperación. |
| Cambio en una fecha crítica | Mayor exposición durante cierres, campañas, auditorías o picos operativos. | Calendario acordado con negocio, periodos protegidos y contingencias específicas. |
| Incidencias heredadas | Confusión sobre responsabilidades, prioridades y compromisos previos. | Lista validada, decisión caso a caso y comunicación clara del tratamiento acordado. |
| Expectativas irreales | Pensar que todo se corregirá en las primeras semanas y generar frustración. | Separar estabilización, riesgos urgentes, mejoras de corto plazo y evolución posterior. |
Por qué Ayesa
Capacidad para asumir el servicio y conectar la siguiente evolución.
Una transición exige conocimiento del producto, pero también organización, continuidad, perfiles funcionales y técnicos, capacidad de escalado, gobierno del servicio y acceso a otras disciplinas cuando el problema cruza los límites de una aplicación.
Ayesa Digital combina una práctica especializada en Microsoft con capacidades en aplicaciones empresariales, Azure, datos, inteligencia artificial, seguridad, Microsoft 365, integración, automatización y operaciones. Esto permite tratar una incidencia por su causa real, aunque afecte a varias tecnologías, y plantear mejoras sin convertir cada necesidad en un proyecto aislado.
El cambio de partner puede comenzar por una necesidad concreta de soporte. La diferencia está en disponer de capacidad para acompañar también una migración, una revisión funcional, un despliegue internacional, un proyecto de datos, una automatización o una modernización cuando el negocio lo requiera.
Conoce la capacidad Microsoft de Ayesa
Consulta la propuesta empresarial y las capacidades acreditadas que respaldan proyectos de ERP, CRM, Cloud, datos, seguridad, productividad e inteligencia artificial.
Qué aporta la revisión inicial
Una visión ejecutiva para decidir si cambiar, cómo hacerlo y qué priorizar.
La revisión no obliga a cambiar de partner. Su valor está en convertir una percepción difusa —“el servicio no funciona”, “dependemos demasiado”, “no avanzamos”— en hechos, riesgos y opciones concretas.
Diagnóstico ejecutivo
Resumen claro del punto de partida, principales fricciones, dependencias, nivel de riesgo y capacidad actual del servicio para acompañar al negocio.
Mapa del entorno
Soluciones, versiones, entornos, integraciones, desarrollos, licencias, cuentas críticas, procesos y responsables que deben formar parte de la transición.
Riesgos y medidas
Clasificación de riesgos por impacto y probabilidad, junto con medidas para reducir exposición antes, durante y después del cambio.
Perímetro de servicio
Definición de cobertura, niveles de atención, canales, horarios, escalados, responsabilidades y tratamiento de evolutivos.
Plan de transición
Etapas, responsables, entregables, dependencias, calendario y criterios que deben cumplirse antes de asumir la responsabilidad completa.
Hoja de ruta posterior
Prioridades de estabilización, deuda técnica, mejoras funcionales, automatización, datos, adopción y modernización ordenadas por valor y urgencia.
Antes de elegir al sustituto
No compares solo tarifas. Compara la capacidad de hacerse responsable del entorno.
Una oferta económica puede parecer atractiva y seguir siendo insuficiente. El coste real del servicio aparece cuando hay que resolver una incidencia compleja, coordinar varias tecnologías, recuperar conocimiento perdido o tomar una decisión que afecta a finanzas, operaciones y clientes. Antes de elegir, conviene exigir respuestas concretas y verificables.
Equipo y cobertura
Pregunta qué perfiles atenderán la cuenta, cómo se sustituyen ausencias, qué niveles de escalado existen y quién interviene cuando el problema cruza funcional, desarrollo, integración, infraestructura o fabricante.
Método de toma de servicio
Solicita una explicación detallada de cómo se revisarán accesos, documentación, integraciones, desarrollos, incidencias y procesos críticos. Una respuesta genérica suele anticipar una transición improvisada.
Experiencia comparable
No basta con conocer Dynamics 365. El partner debe comprender el nivel de complejidad, sector, países, procesos, criticidad e integraciones del escenario que va a asumir.
Gobierno y transparencia
Debe quedar claro cómo se priorizan peticiones, cómo se estiman trabajos, qué información recibirá el cliente, con qué frecuencia se revisará el servicio y cómo se gestionarán desviaciones.
Capacidad de evolución
El nuevo partner debería poder resolver el presente y acompañar decisiones futuras sobre actualización, migración, automatización, datos, seguridad, integración o nuevas aplicaciones.
Responsabilidad compartida
El cliente también debe asignar responsables, facilitar información, validar procesos y tomar decisiones. Ningún proveedor puede asegurar una transición ordenada si la organización no participa en ella.
Una comparación útil debería responder a una pregunta sencilla:
¿Este partner puede entender el entorno, proteger la operación, asumir responsabilidades y ayudar a que la plataforma avance dentro de un modelo de servicio comprensible?
Preguntas frecuentes
Lo que conviene aclarar antes de tomar una decisión.
¿Es complicado cambiar de partner Microsoft Dynamics 365?
La parte administrativa suele ser asumible. La complejidad real depende del entorno: personalizaciones, integraciones, documentación, criticidad, versiones, países, licencias y calidad del modelo actual. Un cambio sencillo puede resolverse con una toma de servicio breve. Un entorno complejo necesita inventario, transferencia de conocimiento, pruebas y estabilización. Lo importante es no tratar ambos casos como si fueran iguales.
¿Es necesario informar al partner actual?
La empresa debe revisar sus contratos, preavisos, compromisos y condiciones de salida. Para una transferencia ordenada suele ser necesario coordinar documentación, accesos, repositorios, incidencias y sesiones de conocimiento. La relación debe gestionarse con profesionalidad y con un alcance claro. El objetivo no es prolongar el conflicto, sino asegurar que la compañía conserva el control de sus sistemas y su información.
¿Puede interrumpirse el servicio durante la transición?
Una transición bien planificada busca que el usuario no perciba una interrupción relevante. Para ello se revisan fechas críticas, incidencias abiertas, procesos periódicos, integraciones, responsables y contingencias. El riesgo aumenta cuando faltan accesos, documentación o colaboración. Por eso la toma de servicio debe incluir una etapa de preparación y otra de seguimiento intensivo.
¿Hay que cambiar también las licencias Microsoft?
No necesariamente. El partner que presta soporte, el canal de compra y la relación administrativa con Microsoft pueden requerir decisiones distintas. Conviene revisar contratos, renovaciones, compromisos, productos y responsables para decidir con información. Una transición es un buen momento para comprobar que las licencias contratadas se corresponden con el uso real y que la empresa mantiene control sobre su tenant y sus administradores.
¿Qué ocurre si no existe documentación?
La ausencia de documentación no impide el cambio, pero aumenta el esfuerzo de descubrimiento. Será necesario combinar revisión técnica, entrevistas, análisis de procesos, observación de tareas, validación con usuarios y documentación progresiva. Esta situación debe reflejarse desde el principio para no prometer una toma de servicio inmediata sobre un entorno que todavía no se comprende.
¿Ayesa puede asumir solo soporte o también evolutivos?
El modelo puede incluir soporte funcional, soporte técnico, gestión de incidencias, desarrollos, formación, evolutivos y acompañamiento continuo, según la solución y el alcance acordado. La revisión inicial sirve precisamente para dimensionar qué cobertura tiene sentido y evitar una propuesta genérica que no responda a la criticidad o complejidad reales.
¿Tiene sentido cambiar si el sistema todavía funciona?
Sí, cuando el problema está en la falta de evolución, la dependencia, la lentitud, el coste, la baja transparencia o la imposibilidad de abordar nuevas necesidades. Esperar a que exista una crisis aumenta el riesgo y reduce la capacidad de negociar una transición ordenada. También puede concluirse que no conviene cambiar todavía. Lo importante es decidir con evidencias, no por inercia ni por frustración puntual.
¿Cambiar de partner implica migrar de NAV o AX a la nube?
No. La toma de servicio y la migración son decisiones diferentes. Puede ser necesario estabilizar primero el entorno actual y plantear la modernización después. En otros casos la obsolescencia, el riesgo o el coste de mantener la plataforma hacen recomendable estudiar una migración. La revisión debe separar urgencias operativas de decisiones de transformación para no forzar un proyecto que la organización aún no está preparada para ejecutar.
¿Cuánto tiempo requiere el cambio?
Depende de la solución, el número de países y sociedades, la calidad de la documentación, la cantidad de integraciones, el volumen de personalizaciones y la colaboración disponible. La estimación responsable se realiza después de una primera revisión. Prometer un plazo cerrado sin conocer el entorno suele ser una señal de que se está infravalorando el riesgo.
¿Qué información conviene preparar para una primera conversación?
Producto y versión, número de usuarios, países y sociedades, áreas funcionales, principales integraciones, nivel de personalización, modelo actual de soporte, incidencias recurrentes, renovaciones próximas y motivo principal de la revisión. No es necesario disponer de toda la documentación para empezar, pero sí explicar con claridad qué preocupa y qué resultado espera la empresa.
Continúa la evaluación
Recursos relacionados para entender soporte, plataforma y modernización.
Customer Care
Modelo de soporte funcional, técnico y evolutivo con trazabilidad, escalado y continuidad del conocimiento.
Finance & Operations
Capacidades ERP para compañías con finanzas, operaciones, supply chain, sociedades y procesos de alta complejidad.
Modernización ERP Microsoft
Cómo evaluar la evolución de NAV, AX y otros ERP legacy hacia una plataforma cloud conectada.
Business Value
Una forma de ordenar objetivos, impacto, prioridades, inversión y riesgos antes de comprometer un proyecto.
Revisión del entorno actual
Antes de cambiar de partner, conviene saber exactamente qué hay que proteger.
Cuéntanos qué solución utilizas, qué está fallando en la relación actual y qué te preocupa de una posible transición. Revisaremos el escenario para determinar el alcance, los principales riesgos y la forma más segura de avanzar.
Solicita una revisión inicial
Indica la solución actual, versión si la conoces, número aproximado de usuarios y principal motivo para revisar el servicio.