La migración a la nube no es un destino. Es una decisión de negocio sobre riesgo, coste y capacidad de evolución.
Durante años, muchas empresas han abordado la nube como un proyecto de infraestructura. El debate se reducía a comparar servidores propios con servicios cloud, calcular almacenamiento y estimar cuánto costaría mover determinadas cargas. Ese enfoque es insuficiente cuando la organización quiere modernizar procesos, conectar datos, automatizar operaciones y preparar su arquitectura para Copilot, agentes e inteligencia artificial.
La pregunta ya no es únicamente cuánto cuesta mantener un entorno on-premises. También hay que valorar cuánto cuesta seguir dependiendo de versiones antiguas, personalizaciones difíciles de mantener, integraciones frágiles, ciclos de actualización largos y equipos que dedican demasiado tiempo a sostener tecnología en lugar de mejorar el negocio.
Migrar puede significar varias cosas: llevar infraestructura a Azure, sustituir un ERP local por Business Central o Dynamics 365 Finance, modernizar aplicaciones, activar una plataforma de datos, desplegar Power Platform o construir una arquitectura preparada para IA. Cada escenario exige una lógica económica, técnica y operativa distinta. Una buena decisión no parte de la moda ni del miedo: parte de una línea base, un modelo objetivo, un coste total comparable y una lectura clara del riesgo de no actuar.
El entorno actual sigue siendo viable
Puede tener sentido cuando la plataforma está soportada, el coste es razonable, el riesgo está controlado y no bloquea iniciativas prioritarias. La condición es que exista una fecha de revisión y criterios claros para volver a decidir.
Reducir dependencia y riesgo
Reubicar o sustituir cargas cuando el entorno actual limita continuidad, soporte, escalabilidad o coste. La migración debe ordenar dependencias, arquitectura, seguridad y operación para evitar que el destino herede los problemas del origen.
Cambiar la capacidad, no sólo la ubicación
Aprovechar la transición para simplificar procesos, retirar deuda técnica, adoptar servicios gestionados, mejorar datos, automatizar y preparar nuevas capacidades de analítica e IA.
El coste real de no migrar suele estar repartido entre presupuestos, equipos y riesgos que nadie consolida.
La infraestructura es sólo una parte. Una evaluación seria debe sumar operación, seguridad, actualización, soporte, continuidad, personalización, dependencia de perfiles escasos y tiempo de negocio perdido. Cuando estas partidas se analizan por separado, el coste de continuidad parece bajo; cuando se consolidan, la lectura puede cambiar.
También existe un coste de oportunidad. Un entorno difícil de integrar puede retrasar automatización, impedir adoptar servicios gestionados, limitar analítica en tiempo casi real o hacer inviable conectar Copilot y agentes con datos gobernados. Ese coste no siempre aparece en una factura, pero influye en velocidad, margen y capacidad competitiva.
Hardware y renovación
Servidores, almacenamiento, red, energía, instalaciones, garantías y ciclos de sustitución.
Administración y soporte
Monitorización, incidencias, copias, parches, capacidad, rendimiento y disponibilidad.
Protección y respuesta
Herramientas, especialistas, auditoría, recuperación, controles y exposición a versiones obsoletas.
Licencias y mantenimiento
Sistemas operativos, bases de datos, middleware, aplicaciones, soporte y contratos.
Deuda técnica
Desarrollos, interfaces y conocimiento especializado que encarecen cada cambio.
Oportunidad perdida
Automatización tardía, datos fragmentados, IA bloqueada y menor velocidad para lanzar nuevas capacidades.
El TCO explica cuánto cuesta operar. El ROI explica por qué merece la pena cambiar.
El coste total de propiedad debe comparar escenarios durante un periodo suficiente para capturar renovaciones, evolución, soporte y crecimiento. Un análisis de un solo año puede favorecer artificialmente la continuidad porque no refleja actualizaciones, sustituciones o deuda acumulada.
La comparación debe incluir inversión inicial, costes recurrentes, costes internos y contingencias. En cloud, además de consumo y licencias, hay que considerar arquitectura, seguridad, monitorización, gobierno, formación, soporte y evolución. En on-premises, deben incluirse infraestructura, personal, mantenimiento, instalaciones, renovación, riesgo y dependencia.
El retorno no debe limitarse al ahorro directo. Puede aparecer en capacidad liberada, menor tiempo de ciclo, mejor servicio, reducción de errores, menor riesgo de interrupción, mejor trazabilidad, crecimiento sin ampliar estructura o posibilidad de activar nuevas capacidades. La mejor decisión no siempre es la opción con menor coste nominal; puede ser la que reduce variabilidad, mejora continuidad y permite cambiar más rápido.
Inversión inicial
Infraestructura, migración, implantación, datos, integración, pruebas, formación y transición.
Coste recurrente
Licencias, consumo, soporte, administración, monitorización, seguridad y evolución.
Coste de la organización
Usuarios clave, arquitectura, pruebas, gestión del cambio, gobierno y soporte.
Coste esperado
Interrupción, obsolescencia, seguridad, dependencia, retrasos y contingencia.
Valor cuantificable
Ahorro, capacidad, automatización, menor error, mejor servicio, margen y velocidad.
Sensibilidad
Crecimiento, reducción, estacionalidad, nuevas cargas, datos, IA y expansión.
Azure no es sólo infraestructura: puede ser la base para modernizar aplicaciones, datos, seguridad e IA.
Un proyecto cloud puede comenzar con máquinas virtuales, pero el mayor valor aparece cuando la arquitectura aprovecha servicios gestionados, automatización, observabilidad, integración, datos y capacidades de inteligencia artificial. La transición debe decidir qué cargas se reubican, cuáles se modernizan y cuáles conviene sustituir por SaaS.
Mover una aplicación sin cambiar su arquitectura puede conservar deuda técnica, dependencia y coste operativo. Por eso la página de Microsoft Azure para empresas y los Solution Assessments de Azure son dos rutas naturales para profundizar antes de comprometer una ejecución.
No todas las cargas deben seguir el mismo camino
Una cartera empresarial combina aplicaciones estables, sistemas críticos, plataformas heredadas y nuevas capacidades. La estrategia debe clasificar y priorizar cada activo según valor, riesgo, dependencia, coste y horizonte de vida.
Reubicar
Mover con cambios mínimos para reducir dependencia física o acelerar la salida del centro de datos.
Ajustar la plataforma
Adoptar servicios gestionados o cambiar componentes sin reconstruir completamente la aplicación.
Modernizar
Cambiar arquitectura, componentes o código para mejorar escalabilidad, resiliencia y evolución.
Sustituir por SaaS
Adoptar una solución estándar como Business Central, Dynamics 365 o Microsoft 365 cuando cubre mejor la necesidad.
Mantener temporalmente
Conservar una carga cuando el riesgo de cambio supera el beneficio inmediato, pero con revisión y condiciones de salida.
Retirar
Eliminar aplicaciones, datos o interfaces que ya no aportan valor o que pueden consolidarse en otra plataforma.
Migrar el ERP cambia el modelo operativo, no sólo la ubicación del software.
En un ERP, la nube implica pasar de ciclos largos de actualización y personalizaciones profundas a una plataforma que evoluciona con mayor frecuencia. Esto exige disciplina sobre estándar, extensiones, integración, datos y gobierno.
Dynamics 365 Business Central puede encajar en organizaciones que buscan un ERP SaaS para finanzas, compras, ventas, inventario, proyectos, servicios y fabricación con una arquitectura conectada a Microsoft 365 y Power Platform.
Dynamics 365 Finance & Operations responde a escenarios de mayor complejidad organizativa, operativa, internacional, industrial o de supply chain. La decisión no debe tomarse únicamente por número de usuarios, sino por procesos, países, volumen, gobierno, fabricación, proyectos, logística, integración y modelo de crecimiento.
Si el punto de partida es un ERP antiguo, puedes profundizar en migración ERP legacy a Microsoft Cloud.
Modernizar alrededor del núcleo sin convertir el ERP o el CRM en una aplicación imposible de actualizar.
Power Apps puede resolver movilidad, captura, validación, aplicaciones departamentales y experiencias específicas. Power Automate puede orquestar aprobaciones, avisos, integraciones, tareas y escalados. Power BI aporta visibilidad sobre rendimiento, capacidad, riesgo y resultados.
El valor aparece cuando estas capacidades se conectan con una arquitectura clara y con datos gobernados. Crear aplicaciones sin control puede sustituir hojas de cálculo por una nueva proliferación difícil de mantener. La plataforma necesita entornos, políticas, seguridad, ALM, responsables, catálogo y métricas.
En una migración cloud, Power Platform puede acelerar quick wins y reducir personalizaciones, pero no debe utilizarse para esconder un proceso mal diseñado. Si este es uno de tus escenarios, consulta Power Platform conectada al ERP.
La nube prepara el terreno para Copilot y agentes, pero la IA no corrige datos pobres ni procesos inconsistentes.
La arquitectura debe permitir que modelos y agentes accedan a información autorizada, utilicen herramientas y actúen dentro de límites claros. Eso requiere fuentes actualizadas, identidad, permisos, conectores, APIs, evaluación, observabilidad y supervisión humana cuando la decisión lo exige.
Una empresa que migra sólo infraestructura puede seguir teniendo datos fragmentados y procesos manuales. Una empresa que utiliza la migración para ordenar identidad, integración, datos y operación crea una base más útil para nuevos escenarios de IA.
Para profundizar en esa arquitectura, consulta Azure + IA empresarial y ERP + IA Microsoft.
Migrar a la nube no elimina el riesgo. Cambia cómo se diseña, se opera y se comparte la responsabilidad.
La seguridad debe incorporarse desde la arquitectura, no añadirse al final. Identidad, segmentación, configuración, cifrado, monitorización, recuperación y gestión de vulnerabilidades forman parte del diseño. La continuidad debe medirse por objetivos de recuperación, dependencias, pruebas y capacidad de operar durante una incidencia. Tener copias no equivale a disponer de una estrategia de recuperación.
La nube puede mejorar resiliencia y control, pero sólo cuando existe gobierno sobre suscripciones, entornos, identidades, datos, costes y cambios. El modelo de responsabilidad compartida no significa delegar todo en el proveedor cloud; significa entender con precisión qué controla Microsoft, qué controla el partner y qué sigue siendo responsabilidad de la organización.
Esperar puede ser una decisión correcta si existe una razón concreta, medible y revisable.
No toda carga debe migrarse de inmediato. Lo importante es evitar que la espera se convierta en una decisión indefinida sin plan. Mantener una aplicación puede ser sensato si existe una restricción real y una fecha o condición para volver a evaluarla.
Dependencia técnica
La carga depende de hardware, latencia o interfaces que todavía no tienen alternativa viable.
Cambio crítico en curso
La organización no puede absorber dos transformaciones simultáneas sin comprometer operación.
Base de datos insuficiente
Calidad, clasificación o propiedad no permiten todavía una transición segura.
Caso económico no justificado
El beneficio no compensa todavía el coste, el riesgo o la complejidad del cambio.
Restricciones específicas
Existen requisitos de regulación, residencia, latencia o contrato que condicionan la ubicación.
Retención temporal con plan
La carga se mantiene con una fecha, condiciones de salida y medidas para reducir riesgo mientras tanto.
Las migraciones fallan cuando el proyecto confunde movimiento técnico con transformación.
Los errores más costosos suelen aparecer antes de la puesta en marcha: alcance poco claro, datos sin preparar, personalizaciones incuestionadas, falta de gobierno y ausencia de una lógica de priorización.
Mover sin clasificar
Todas las cargas reciben el mismo tratamiento aunque tengan valor y riesgo diferentes.
Replicar el entorno
La nube hereda arquitectura, procesos y deuda técnica del sistema anterior.
Subestimar los datos
La calidad, el histórico y la reconciliación se dejan para el final.
Ignorar adopción
Los usuarios reciben la plataforma, pero mantienen circuitos paralelos y hábitos antiguos.
No gobernar costes
Consumo, capacidad y recursos crecen sin propiedad ni límites claros.
Activar IA demasiado pronto
Se añaden modelos y agentes sobre procesos, permisos y datos todavía inestables.
Ocho preguntas para decidir si migrar, modernizar, convivir o esperar
La decisión debe combinar urgencia, valor, riesgo, viabilidad y capacidad organizativa. Si una de estas dimensiones queda fuera, el proyecto puede parecer correcto desde tecnología y ser débil desde negocio.
Coste, seguridad, obsolescencia, crecimiento, integración, datos, automatización o IA.
Riesgo, pérdida de soporte, interrupción, deuda, limitación comercial o incapacidad de evolucionar.
Infraestructura, licencias, personas, soporte, instalaciones, personalización y riesgo.
Azure, SaaS, arquitectura híbrida, modernización de aplicaciones o combinación.
Estándar, roles, integraciones, calidad, seguridad y adopción.
Tiempo, capacidad, servicio, errores, margen, continuidad y riesgo evitado.
Patrocinio, equipo, proveedores, decisiones, formación, soporte y gobierno.
Fases, piloto, coexistencia, migración por oleadas o sustitución completa.
Una migración sólida se construye por decisiones y dependencias, no por una fecha de corte aislada.
La primera fase debe establecer objetivos, alcance, cargas, procesos, riesgos y criterios de éxito. Después se construye una línea base económica y técnica. La arquitectura objetivo debe definir identidad, red, seguridad, datos, integración, observabilidad, continuidad y gobierno. En paralelo, negocio debe validar procesos futuros, prioridades y cambios organizativos.
Las migraciones de prueba y los pilotos sirven para validar supuestos, no para demostrar únicamente que una carga puede arrancar. Deben medir rendimiento, coste, seguridad, operación y experiencia. La transición debe incluir contingencia, soporte reforzado, comunicación, formación y seguimiento. La puesta en marcha no cierra el proyecto: abre una fase de estabilización, optimización y evolución.
Evaluar
Cargas, procesos, costes, riesgos, contratos, datos, integraciones y capacidades.
Diseñar
Modelo objetivo, arquitectura, seguridad, gobierno, procesos y métricas.
Preparar
Landing zones, identidades, red, datos, pruebas, automatización y adopción.
Migrar
Oleadas, coexistencia, reconciliación, rendimiento, validación y corte.
Estabilizar
Soporte, incidencias, adopción, costes, capacidad y continuidad.
Optimizar
Modernización, automatización, IA, FinOps, seguridad y mejora continua.
La migración de datos debe diseñarse como un proyecto de negocio, no como una copia técnica.
Los datos suelen convertirse en uno de los mayores factores de riesgo porque concentran años de duplicidades, campos sin uso, criterios diferentes, documentos dispersos y relaciones que sólo conocen determinadas personas. Mover todo sin clasificar puede trasladar problemas históricos al nuevo entorno y aumentar el coste de validación.
La estrategia debe separar datos maestros, transacciones abiertas, histórico operativo, documentos y evidencias. Cada grupo necesita una decisión sobre limpieza, transformación, archivo, retención, acceso y reconciliación.
El negocio debe validar que la información migrada permite operar, analizar y cumplir obligaciones. Tecnología puede ejecutar cargas y controles, pero no puede decidir por sí sola qué dato es correcto o qué histórico sigue aportando valor.
Modernizar exige decidir qué conservar, qué reconstruir y qué dejar de mantener.
Las aplicaciones heredadas suelen contener conocimiento valioso, pero también capas de código, integraciones y excepciones acumuladas. La modernización debe distinguir la lógica que diferencia al negocio de la complejidad creada por limitaciones antiguas.
Reescribir todo puede resultar innecesario y arriesgado. Mantener todo puede perpetuar dependencia y coste. La mejor ruta puede combinar reubicación temporal, sustitución por SaaS, modernización de componentes y retirada progresiva.
Cada decisión debe considerar criticidad, frecuencia de cambio, talento disponible, seguridad, observabilidad, coste operativo y horizonte de vida. Una aplicación estable con bajo valor puede mantenerse temporalmente; una aplicación estratégica y frágil puede requerir prioridad.
La nube necesita responsabilidad financiera continua, no una revisión anual de facturas.
El consumo cloud cambia con uso, capacidad, diseño y comportamiento. Por eso el control económico debe integrarse en arquitectura, operación y producto. No basta con negociar precios o reservar capacidad; hay que comprender quién consume, por qué y qué valor produce.
FinOps conecta tecnología, finanzas y negocio para asignar responsabilidad, mejorar previsión, detectar anomalías y optimizar. El objetivo no es reducir coste de forma indiscriminada, sino utilizar recursos de manera proporcional al valor y al nivel de servicio.
Una arquitectura sobredimensionada puede parecer segura, pero inmoviliza presupuesto. Una optimización agresiva puede deteriorar rendimiento y resiliencia. El equilibrio debe apoyarse en métricas, automatización y decisiones compartidas.
Visibilidad
Etiquetado, asignación, unidades, productos, entornos y propietarios.
Previsión
Tendencias, crecimiento, proyectos, estacionalidad y escenarios.
Optimización
Capacidad, apagado, reservas, almacenamiento y arquitectura.
Valor
Coste por transacción, usuario, producto, cliente o resultado.
El proyecto termina mal cuando la organización migra tecnología, pero no cambia su modelo de operación.
La nube introduce nuevas responsabilidades sobre consumo, configuración, automatización, seguridad y ciclo de vida. Los equipos necesitan procesos de operación adecuados al nuevo entorno y no una réplica de prácticas on-premises.
La adopción debe incluir formación por roles, comunicación, soporte, métricas de uso y mecanismos para recoger fricciones. En ERP, CRM y Power Platform, la calidad del resultado depende de que los usuarios trabajen dentro del nuevo proceso y abandonen circuitos paralelos.
La estabilización debe revisar incidencias, rendimiento, costes, seguridad y experiencia. Después comienza la optimización: automatización, modernización, IA, reducción de deuda y mejora continua.
La migración necesita decisiones ejecutivas claras, propietarios y criterios que no cambien en cada reunión.
Los proyectos cloud atraviesan infraestructura, aplicaciones, ERP, datos, seguridad, finanzas, compras, operaciones y usuarios. Sin un modelo de gobierno, cada área interpreta el objetivo desde su propia prioridad y el alcance se fragmenta.
El patrocinador debe proteger el resultado empresarial, resolver conflictos y decidir qué riesgos son aceptables. El propietario del programa coordina dependencias, presupuesto y avance. Los responsables de carga o producto validan arquitectura, datos, pruebas, adopción y operación posterior.
Las decisiones importantes deben registrarse con contexto, alternativas, impacto y responsable. El gobierno no debe convertirse en burocracia: debe acelerar decisiones, hacer visible el riesgo y mantener coherencia entre arquitectura, negocio y operación.
20 preguntas antes de aprobar una migración cloud
Si la organización no puede responder a estas preguntas con suficiente claridad, todavía hay trabajo de assessment y diseño antes de comprometer presupuesto y calendario.
Una migración empresarial exige más que mover cargas.
Una transformación cloud puede afectar infraestructura, aplicaciones, ERP, CRM, seguridad, datos, Microsoft 365, Power Platform, integración y operación. El riesgo crece cuando cada capa se diseña como un proyecto aislado.
Ayesa aborda estos escenarios desde una visión de extremo a extremo para ayudar a ordenar assessment, arquitectura, migración, integración, seguridad, adopción, operación y evolución. El objetivo no es mover más tecnología, sino construir una ruta ejecutable con decisiones claras.
Qué debería dejar una primera evaluación
Conecta la decisión cloud con ERP, Azure, Power Platform e IA empresarial
ERP legacy a Microsoft Cloud
Cómo modernizar procesos, datos y arquitectura antes de sustituir un ERP heredado.
Microsoft Azure para empresas
Cloud, modernización, datos, integración, seguridad, continuidad e IA.
Azure + IA empresarial
Arquitectura para datos, aplicaciones, Microsoft Foundry y agentes inteligentes.
Power Platform conectada al ERP
Apps, flujos, movilidad, analítica y agentes conectados con el núcleo.
ERP + IA Microsoft
Cómo conectar ERP, datos, Copilot, agentes y automatización empresarial.
Servicios gestionados Azure
Soporte, operación, optimización y evolución de entornos Azure después de la migración.
Dudas habituales antes de migrar a la nube
¿Qué significa migrar a la nube?
Puede significar trasladar infraestructura a Azure, sustituir aplicaciones por SaaS, modernizar software, conectar datos o adoptar una arquitectura preparada para automatización e IA. No existe una única ruta.
¿La nube siempre es más barata?
No necesariamente. Puede reducir determinados costes y riesgos, pero requiere arquitectura, gobierno, seguridad, operación y control de consumo. La comparación debe hacerse con TCO completo, no sólo con la factura de infraestructura.
¿Qué diferencia existe entre TCO y ROI?
El TCO calcula el coste total de operar una alternativa. El ROI compara inversión y beneficios para estimar el retorno del cambio. Ambos son necesarios para defender una decisión ante dirección.
¿Qué costes suelen olvidarse en on-premises?
Renovación, instalaciones, energía, copias, seguridad, personal, soporte, personalizaciones, interrupciones y oportunidad perdida.
¿Qué costes suelen olvidarse en cloud?
Migración, arquitectura, seguridad, monitorización, soporte, consumo, formación, gobierno, integración y evolución.
¿Conviene migrar todo a la vez?
No siempre. Las oleadas permiten reducir riesgo y aprender, aunque exigen gestionar coexistencia y dependencias. El orden debe responder a criticidad, valor, riesgo y capacidad de ejecución.
¿Cuándo conviene mantener una carga on-premises?
Cuando existen dependencias, restricciones, latencia, regulación o un caso económico que todavía no justifica el cambio. La decisión debe quedar documentada y revisarse periódicamente.
¿Qué papel tiene Azure?
Puede alojar, modernizar e integrar aplicaciones, datos, seguridad, observabilidad y capacidades de IA. Su valor depende de cómo se diseñe la arquitectura y de qué cargas se decida migrar o modernizar.
¿Qué papel tiene Business Central?
Puede sustituir ERP locales por una plataforma SaaS conectada con Microsoft 365 y Power Platform en organizaciones donde su alcance funcional y complejidad encajen con el modelo operativo.
¿Qué papel tiene Power Platform?
Permite crear apps, automatizar procesos, analizar datos y construir agentes alrededor del ERP, CRM y otras aplicaciones sin sobrecargar el núcleo con personalizaciones innecesarias.
¿Qué papel tiene la IA?
Puede asistir, recomendar y ejecutar acciones, pero necesita datos fiables, permisos claros, evaluación, observabilidad y supervisión. La migración puede ser una oportunidad para crear esa base.
¿Cómo se evita trasladar deuda técnica?
Clasificando cargas, cuestionando personalizaciones, limpiando datos, retirando integraciones obsoletas y modernizando de forma selectiva en lugar de copiar el entorno tal cual.
¿Qué es una landing zone?
Es una base de arquitectura y gobierno para identidad, red, seguridad, políticas, suscripciones y operación que permite desplegar cargas de forma coherente y controlada.
¿Qué es FinOps?
Es una disciplina para gestionar consumo cloud, responsabilidad financiera, previsión, optimización y valor, conectando decisiones técnicas y económicas.
¿Cómo se mide el éxito?
Con indicadores de coste, disponibilidad, seguridad, tiempo, calidad, adopción, capacidad, continuidad y retorno. Las métricas deben definirse antes de ejecutar para poder comparar.
¿Cuánto tarda una migración?
Depende del alcance, número de cargas, datos, integraciones, procesos, seguridad, pruebas y capacidad organizativa. Un assessment permite estimar escenarios con mayor realismo.
¿Qué datos deben migrarse?
Los necesarios para operar, analizar y cumplir obligaciones. Parte del histórico puede archivarse o mantenerse en otra capa cuando no aporta valor operativo directo.
¿Cómo se controla el riesgo?
Con assessment, arquitectura, pruebas, oleadas, contingencia, recuperación, soporte y métricas. El objetivo no es eliminar todo riesgo, sino hacerlo visible, aceptable y gobernable.
¿Qué ocurre después de la migración?
Empieza una fase de estabilización, optimización, seguridad, costes, automatización y evolución. La operación posterior condiciona gran parte del valor real conseguido.
¿Qué información necesita Ayesa para una primera evaluación?
Inventario de aplicaciones, infraestructura, usuarios, costes, incidencias, integraciones, datos, prioridades, restricciones y horizonte de cambio.
Convierte la decisión cloud en una hoja de ruta económica, técnica y operativa.
Cuéntanos qué aplicaciones, ERP, infraestructura o procesos quieres modernizar y revisamos coste, riesgos, arquitectura objetivo, prioridades y siguientes pasos. El objetivo de una primera evaluación no es vender una migración a toda costa, sino saber qué merece la pena mover, qué debe modernizarse y qué puede esperar.
¿Estás valorando una migración a la nube y necesitas ordenar la decisión?
Indícanos qué entorno tienes hoy, qué problemas quieres resolver, qué cargas te preocupan y qué horizonte manejas. Podemos ayudarte a construir una primera lectura de alcance, riesgo, coste y arquitectura objetivo.