Cómo preparar una empresa para sustituir una aplicación por otra

Introducción

Sustituir una aplicación empresarial parece, desde fuera, una operación sencilla: elegir otra herramienta, trasladar la información y empezar a utilizarla. En la práctica, el programa visible suele ser solo la parte más evidente de un sistema mucho mayor. Alrededor de él existen datos, permisos, automatizaciones, documentos, informes, hábitos, excepciones, contratos, cuentas técnicas y decisiones que se han acumulado durante años. Cambiar la aplicación sin comprender ese entorno puede interrumpir procesos que aparentemente no tenían relación con ella.

La preparación es la fase que convierte una intención difusa —«tenemos que cambiar de programa»— en una transición gobernable. Su objetivo no es configurar todavía la nueva solución ni ejecutar la migración definitiva, sino reducir las incógnitas antes de que el cambio afecte a la operativa. Una empresa preparada sabe qué está sustituyendo, por qué lo hace, qué debe conservar, qué puede abandonar, qué dependencias tendrá que resolver y qué condiciones deben cumplirse antes de autorizar el cambio.

Esta distinción resulta especialmente importante en pequeñas empresas, donde una misma persona puede administrar cuentas, atender clientes, mantener hojas auxiliares y conocer las excepciones del proceso. La ausencia de departamentos especializados no reduce la complejidad; con frecuencia la vuelve menos visible. Una tarea manual recordada por una sola persona puede ser tan crítica como una integración formal.

Antes de preparar la sustitución debe estar suficientemente justificado que la aplicación actual ya no encaja y que existe una alternativa viable. Para esas decisiones resultan útiles cómo evaluar si una aplicación merece la pena y cómo comparar aplicaciones antes de implantarlas. Este artículo comienza en el paso siguiente: cuando la empresa contempla seriamente reemplazar una herramienta y necesita preparar el terreno sin poner en peligro datos, continuidad ni capacidad de trabajo.

El resultado esperado será un expediente de sustitución suficientemente claro para tomar una decisión de continuidad, aplazamiento o cancelación. Ese expediente debe permitir que la implantación posterior empiece con alcance, responsabilidades, riesgos y criterios de aceptación definidos, en lugar de descubrirlos cuando ambas aplicaciones ya están contratadas y los usuarios esperan instrucciones.

Índice

• Qué significa preparar la sustitución de una aplicación
• Diferenciar sustitución, selección, implantación, migración y retirada
• Definir por qué se cambia y qué resultado debe conseguirse
• Delimitar exactamente qué se va a sustituir
• Construir una línea base del sistema actual
• Descubrir dependencias visibles y ocultas
• Relacionar la aplicación con procesos y niveles de criticidad
• Inventariar datos, documentos e históricos
• Comprobar la viabilidad de salida antes de comprometerse
• Inventariar integraciones, automatizaciones e informes
• Revisar identidades, permisos y cuentas técnicas
• Clasificar qué debe conservarse, mejorarse o dejar de hacerse
• Diseñar el modelo operativo objetivo
• Elegir entre reemplazo equivalente y rediseño del proceso
• Preparar la coexistencia temporal sin crear dos verdades
• Construir un calendario desde las restricciones reales
• Coordinar contratos, licencias y periodos de solapamiento
• Estimar coste total y capacidad interna necesaria
• Construir un registro de riesgos accionable
• Preparar continuidad, reversión y contingencia
• Integrar seguridad, privacidad y conservación
• Preparar a las personas sin iniciar todavía la implantación
• Asignar gobierno y responsabilidades de transición
• Definir criterios de aceptación y una puerta de decisión
• Diseñar las pruebas antes de tocar producción
• Crear un expediente de sustitución mantenible
• Ejemplo práctico de preparación
• Método completo paso a paso
• Indicadores de preparación
• Errores habituales
• Preguntas frecuentes
• Conclusión

Qué significa preparar la sustitución de una aplicación

Preparar una sustitución significa comprender y organizar todo lo que debe ocurrir para que una aplicación deje de sostener una función empresarial y otra pueda asumirla sin pérdida inaceptable de información, control o continuidad. El objeto del cambio no es únicamente el software: es la responsabilidad operativa que actualmente descansa sobre él.

La preparación reduce incertidumbre

Antes de la preparación suelen existir muchas afirmaciones imprecisas: «los datos se pueden exportar», «la nueva herramienta hace lo mismo», «solo la usan cinco personas» o «podemos mantener ambas un tiempo». Cada una puede esconder condiciones importantes. Quizá la exportación no incluya adjuntos, la función equivalente exija un plan superior, existan cuentas técnicas sin usuario humano o la convivencia obligue a duplicar actualizaciones.

Preparar consiste en transformar esas suposiciones en información comprobada y decisiones explícitas.

La preparación no garantiza que el cambio deba realizarse

Una buena fase de preparación puede terminar recomendando aplazar o cancelar la sustitución. Ese resultado no representa un fracaso. Puede descubrirse que la aplicación actual es más reemplazable después de ordenar ciertos datos, que el coste de transición supera el beneficio inmediato o que la candidata todavía no cubre una capacidad crítica.

El producto de esta fase es una decisión ejecutable

Al terminar deberían estar definidos, como mínimo:

• el motivo y el resultado esperado;
• el perímetro exacto del cambio;
• los procesos y usuarios afectados;
• los datos, integraciones y accesos implicados;
• las funciones que deben conservarse o abandonarse;
• el modelo operativo objetivo;
• los riesgos y controles principales;
• el coste y la capacidad necesarios;
• los criterios que permitirán comenzar la implantación;
• las razones que obligarían a detener o replantear el proyecto.

Preparar es hacer reemplazable el sistema actual

En ocasiones la empresa no está lista para cambiar porque apenas conoce la aplicación que quiere abandonar. La primera mejora no consiste en comprar otra, sino en hacer visible lo que existe: documentar dependencias, recuperar titularidad, probar exportaciones, localizar administradores y separar datos de configuración. Esa labor aporta valor incluso si la sustitución se retrasa.

Diferenciar sustitución, selección, implantación, migración y retirada

Los proyectos se vuelven confusos cuando varias fases diferentes reciben el nombre genérico de «migración». Separarlas permite saber qué decisiones corresponden a cada momento y evita que el equipo empiece a ejecutar antes de estar preparado.

La preparación se apoya en la selección, pero puede hacerla retroceder

Aunque exista una candidata preferida, la preparación puede revelar una limitación que obligue a volver a comparar. Por ejemplo, una función anunciada puede no admitir el volumen real, una API puede estar limitada al plan empresarial o la exportación del sistema actual puede exigir una transformación no prevista.

La preparación diseña, pero no ejecuta la implantación

Puede definir qué datos se migrarán, qué perfiles harán falta y qué secuencia se considera segura. Sin embargo, la configuración concreta, las cargas de prueba, el piloto y el despliegue pertenecen a la implantación. Para desarrollar esa fase conviene acudir a cómo implantar una nueva aplicación sin generar caos.

La retirada no debe anticiparse

Cancelar licencias, eliminar usuarios o cerrar el acceso al sistema anterior antes de validar la nueva operativa puede destruir la capacidad de reversión. La preparación debe prever la retirada, pero no ejecutarla hasta que existan pruebas suficientes y obligaciones de conservación resueltas.

Definir por qué se cambia y qué resultado debe conseguirse

«La aplicación se ha quedado antigua» o «la nueva parece mejor» no constituyen una base suficiente para gobernar una sustitución. El proyecto necesita una razón operativa concreta y un resultado que pueda comprobarse después.

Separar causas de síntomas

Que los usuarios mantengan hojas paralelas puede indicar una carencia funcional, pero también una configuración deficiente, falta de formación o ausencia de una regla común. Que el coste haya aumentado puede ser un problema del proveedor, del número de licencias o del uso de un plan sobredimensionado. Si se confunde el síntoma con la causa, la nueva aplicación puede reproducir exactamente el mismo problema.

Describir el problema actual

Una formulación útil identifica:

• qué proceso está afectado;
• qué personas sufren la limitación;
• con qué frecuencia ocurre;
• qué consecuencias tiene;
• qué parte se atribuye realmente a la aplicación;
• qué ocurriría si no se cambia durante uno o dos años.

Definir resultados y no una lista de funciones

«La nueva herramienta tendrá automatizaciones» describe una capacidad. «Las solicitudes completas se registrarán sin doble introducción y quedarán asignadas en menos de diez minutos» describe un resultado operativo. Los resultados permiten evaluar si la sustitución ha merecido la pena y evitan que el proyecto se convierta en una carrera por reproducir funciones.

Reconocer los objetivos defensivos

No todos los cambios buscan aumentar productividad. Una empresa puede sustituir una aplicación para recuperar portabilidad, evitar un fin de soporte, reducir una dependencia, cumplir un requisito de seguridad o asegurar continuidad. Estos objetivos son válidos, pero deben explicarse porque condicionan la elección de riesgos y criterios de aceptación.

Registrar también lo que no se pretende conseguir

El proyecto gana claridad cuando declara sus límites: no rediseñará todos los procesos, no centralizará toda la información, no eliminará cada tarea manual ni resolverá problemas ajenos a la aplicación. Esta lista protege el alcance frente a expectativas que aparecen una vez iniciado el cambio.

Delimitar exactamente qué se va a sustituir

Una aplicación puede cubrir más funciones de las que aparecen en su nombre comercial. Un CRM puede enviar campañas, alojar formularios, gestionar documentos y autenticar integraciones. Sustituir «el CRM» no define todavía qué componentes abandonarán el sistema actual ni cuáles seguirán temporal o permanentemente.

Construir un perímetro de sustitución

Conviene clasificar cada componente relacionado con la aplicación:

Delimitar por procesos, grupos y fechas

El alcance puede ser funcional —solo gestión comercial—, organizativo —un equipo antes que otro—, geográfico, contractual o temporal. En una pequeña empresa suele ser más útil definirlo por procesos y tipos de caso que por organigramas. Un mismo equipo puede necesitar utilizar ambas aplicaciones para funciones diferentes durante un periodo.

Separar el perímetro inicial del destino final

La empresa puede tener una visión a largo plazo más amplia y, aun así, preparar una primera sustitución limitada. Por ejemplo, el objetivo final puede retirar una suite completa, mientras que la primera fase reemplaza únicamente la gestión de proyectos. Confundir ambas escalas conduce a proyectos demasiado grandes para la capacidad disponible.

Registrar exclusiones justificadas

Cuando un módulo, histórico o integración queda fuera, debe anotarse quién seguirá responsabilizándose de él y hasta cuándo. «Fuera de alcance» no puede significar «nadie sabe qué ocurrirá».

Construir una línea base del sistema actual

La sustitución necesita una fotografía operativa del punto de partida. Sin ella no se puede estimar el esfuerzo, diseñar pruebas ni demostrar que la nueva situación es mejor. La línea base no debe describir el sistema ideal ni la documentación antigua, sino cómo se trabaja realmente.

Medir uso y volumen

Conviene recopilar datos representativos sobre:

• usuarios activos y perfiles;
• registros nuevos y modificados por periodo;
• volumen total de datos y adjuntos;
• operaciones frecuentes;
• picos estacionales;
• integraciones ejecutadas;
• incidencias y trabajo manual asociado;
• tiempos relevantes del proceso;
• coste actual de licencias, soporte y administración.

Observar casos reales

Las estadísticas no muestran todas las excepciones. Resulta útil recorrer varios casos normales y difíciles con las personas que los gestionan. Una aplicación puede parecer simple hasta que se analiza cómo se corrige un pedido, se reasigna un expediente, se fusionan contactos o se recupera documentación de hace tres años.

Identificar procedimientos paralelos

Hojas de cálculo, carpetas, correos, plantillas, mensajes y notas personales pueden compensar limitaciones del sistema. Excluirlos de la línea base produce una visión falsa: la empresa cree que sustituye una aplicación cuando en realidad sustituye una combinación de aplicación y trabajo auxiliar.

Registrar calidad, no solo cantidad

Hay que conocer el nivel de duplicados, campos vacíos, valores inconsistentes, documentos no vinculados y registros obsoletos. La calidad condicionará tanto el coste como el diseño de la migración. No toda deficiencia debe limpiarse antes de cambiar, pero ninguna debería descubrirse durante la carga definitiva.

Utilizar una referencia temporal adecuada

Un mes puede bastar para una herramienta cotidiana y ser engañoso para procesos trimestrales o anuales. La línea base debe cubrir un periodo que represente el ciclo real de trabajo.

Descubrir dependencias visibles y ocultas

La sustitución se vuelve peligrosa cuando una aplicación realiza más trabajo del que la organización recuerda. El inventario técnico suele recoger conexiones formales, pero las dependencias también pueden vivir en hábitos, documentos, enlaces, cuentas y conocimientos individuales.

Dependencias funcionales

Son tareas que solo pueden completarse con una función concreta: generar un documento, aplicar una tarifa, aprobar una operación, consultar un histórico o realizar un cálculo. Debe comprobarse si esa función existe realmente en el destino o si necesita otro procedimiento.

Dependencias de datos

Otros sistemas pueden consultar identificadores, estados, categorías o archivos procedentes de la aplicación. Incluso una copia aparentemente secundaria puede ser la base de un informe o de una decisión periódica.

Dependencias técnicas

Incluyen API, webhooks, conectores, tareas programadas, scripts, extensiones, direcciones de correo, dominios, certificados, carpetas sincronizadas o accesos directos. Algunas no aparecen en el panel principal de la herramienta.

Dependencias de identidad

Una aplicación puede actuar como proveedor de inicio de sesión, almacenar grupos, emitir tokens o utilizarse para recuperar otras cuentas. Sustituirla sin identificar esta función puede bloquear servicios que continúan en producción.

Dependencias contractuales

Descuentos por paquete, compromisos mínimos, módulos ligados, almacenamiento incluido o soporte conjunto pueden hacer que cancelar una pieza modifique el precio o las condiciones de otras.

Dependencias humanas

Una persona puede conocer filtros, convenciones, correcciones manuales o secuencias que no están documentadas. También puede existir dependencia de un proveedor que administra la aplicación sin entregar configuración ni evidencias suficientes.

Construir un registro de dependencias

Para ampliar esta visión resulta útil cómo evitar dependencias peligrosas. La finalidad no es eliminar cualquier relación, sino saber cuáles deben resolverse, conservarse o vigilarse durante el cambio.

Relacionar la aplicación con procesos y niveles de criticidad

Una misma herramienta puede ser auxiliar para un proceso y esencial para otro. Preparar la sustitución requiere observar qué papel cumple en cada recorrido empresarial, no asignarle una criticidad global basada únicamente en su nombre.

Partir de procesos reales

Para cada proceso afectado conviene identificar inicio, resultado, participantes, datos principales, decisiones, excepciones y aplicaciones utilizadas. El objetivo no es crear un manual exhaustivo, sino entender dónde entra y sale la aplicación que se quiere sustituir. Cómo mapear procesos empresariales ofrece una base útil cuando esos recorridos todavía no están claros.

Clasificar la función de la aplicación

Puede actuar como:

• sistema principal de registro;
• herramienta de captura;
• motor de reglas o automatización;
• repositorio documental;
• interfaz de consulta;
• canal de comunicación;
• plataforma de análisis;
• archivo histórico;
• componente de autenticación.

La misma aplicación puede cumplir varios papeles y cada uno necesitar una solución distinta.

Valorar impacto y tolerancia a interrupción

La criticidad depende de las consecuencias de una indisponibilidad y del tiempo durante el que el proceso puede continuar por otro medio. Una herramienta usada pocas veces puede ser crítica si concentra obligaciones importantes. Otra utilizada a diario puede admitir una contingencia manual durante algunas horas.

Identificar ventanas de menor riesgo

Los ciclos comerciales, cierres, campañas, renovaciones, auditorías o periodos de vacaciones pueden influir en el momento del cambio. El calendario técnico debe adaptarse a la operativa, no al revés.

Distinguir proceso y aplicación

El proceso debe poder describirse sin convertir cada paso en un botón de la herramienta actual. Esta separación permite decidir qué merece conservarse y qué solo existe por una limitación histórica del software.

Inventariar datos, documentos e históricos

Los datos suelen convertirse en el centro visible de una sustitución, pero «migrar la base» es una expresión demasiado amplia. La empresa necesita decidir qué información debe seguir activa, qué puede archivarse, qué relaciones deben preservarse y qué datos no merece trasladar.

Clasificar conjuntos de información

Conviene separar:

• datos maestros, como clientes, productos o usuarios;
• datos operativos activos;
• transacciones y estados;
• historial de cambios;
• comentarios y comunicaciones;
• documentos y adjuntos;
• configuración, plantillas y reglas;
• registros técnicos y auditoría;
• datos derivados utilizados en informes;
• información obsoleta o sin propietario.

Definir la autoridad de cada dato

No toda información que aparece en la aplicación nace allí. Un cliente puede proceder del sistema comercial, un importe de contabilidad y un documento de un repositorio externo. La sustitución debe respetar las fuentes de verdad y evitar convertir copias de trabajo en datos maestros. Para profundizar en esta materia puede consultarse cómo controlar los datos empresariales sin complicar la operativa.

Decidir el tratamiento del histórico

Existen varias opciones razonables:

• migración completa al nuevo sistema;
• migración de un periodo limitado;
• resumen de históricos y conservación detallada fuera;
• archivo estructurado consultable;
• mantenimiento temporal del sistema anterior en modo lectura;
• conservación únicamente de evidencias exigibles.

La opción debe depender del uso futuro, las obligaciones y el coste, no del deseo abstracto de «llevarlo todo».

Conservar relaciones y contexto

Un CSV con registros aislados puede contener los valores y perder el significado. Relaciones entre clientes y proyectos, comentarios y autores, versiones y aprobaciones, o documentos y expedientes pueden ser esenciales. El inventario debe describir esas relaciones antes de decidir el formato de salida.

Identificar datos que no deben migrarse

Duplicados, pruebas, usuarios antiguos, campos abandonados y registros sin finalidad pueden aumentar coste y ruido. La exclusión debe ser deliberada, documentada y compatible con las obligaciones de conservación.

Comprobar la viabilidad de salida antes de comprometerse

Una promesa de exportación no basta para preparar una sustitución. Antes de contratar el cambio conviene realizar una extracción real, entender su estructura y verificar que la empresa dispone de derechos, tiempo y medios para utilizarla.

Probar una exportación representativa

La muestra debe incluir registros simples y complejos, adjuntos, relaciones, caracteres especiales, estados cerrados, usuarios inactivos y casos con histórico. Una exportación de diez contactos limpios puede ocultar problemas que aparecerán con años de actividad.

Comprobar qué queda fuera

Es frecuente que la exportación estándar excluya alguno de estos elementos:

• archivos adjuntos;
• comentarios o conversaciones;
• historial de modificaciones;
• automatizaciones;
• plantillas;
• permisos;
• identificadores externos;
• relaciones entre objetos;
• campos de módulos adicionales;
• registros eliminados o archivados.

Distinguir acceso a datos y migrabilidad

Disponer de un archivo no significa que el destino pueda interpretarlo. Puede ser necesario transformar códigos, normalizar formatos, reconstruir relaciones, descargar adjuntos por separado o utilizar una API. La preparación debe estimar esa distancia entre extracción y carga.

Revisar límites y ventanas

Algunos servicios aplican límites de API, colas de exportación, descargas fragmentadas o periodos cortos de acceso tras la cancelación. Otros requieren permisos administrativos específicos o servicios profesionales. Estas condiciones afectan al calendario y al coste.

Conservar una copia inalterada

Antes de transformar datos conviene guardar una extracción original con fecha, alcance y método documentados. Esa copia permite repetir procesos, investigar diferencias y demostrar qué información estaba disponible.

No esperar al final para descubrir la salida

La prueba de exportación es una puerta temprana. Si la empresa no puede recuperar información crítica con suficiente integridad, debe resolverlo antes de comprometer fechas, cancelar contratos o comunicar un cambio definitivo.

Inventariar integraciones, automatizaciones e informes

Las integraciones suelen ser el lugar donde una sustitución aparentemente local se convierte en un cambio de arquitectura. Cada conexión debe analizarse por su finalidad empresarial, no solo por la tecnología que utiliza.

Buscar más allá del catálogo oficial

El inventario puede incluir:

• conectores nativos;
• plataformas de automatización;
• scripts propios;
• webhooks;
• importaciones y exportaciones programadas;
• consultas directas a bases de datos;
• hojas vinculadas;
• complementos de correo o navegador;
• informes que leen archivos descargados;
• tareas manuales que actúan como integración humana.

Documentar el contrato operativo de cada flujo

Para cada conexión debe saberse qué acontecimiento la inicia, qué datos mueve, quién es autoridad, qué ocurre si falla, cómo se detecta el error y quién responde. Esta descripción permite decidir si la integración se recrea, se simplifica o desaparece.

No copiar automáticamente la arquitectura antigua

Una integración puede existir porque la aplicación actual no cubre una necesidad o porque el proceso se diseñó alrededor de sus limitaciones. La nueva herramienta puede resolverla de forma distinta. Recrear todas las conexiones sin cuestionarlas traslada deuda técnica al destino.

Separar integración crítica y comodidad

Una sincronización que evita un clic no tiene el mismo peso que otra que crea pedidos, actualiza cobros o mantiene permisos. La criticidad condiciona pruebas, monitorización, reversión y fecha de disponibilidad.

Evitar sincronizaciones ambiguas

Durante la transición puede resultar tentador mantener ambos sistemas actualizados en las dos direcciones. Ese diseño aumenta conflictos y dificulta saber cuál originó un cambio. Siempre que sea posible deben definirse flujos con dirección clara y periodos de autoridad explícitos.

El artículo cómo integrar aplicaciones sin crear dependencias innecesarias desarrolla los criterios arquitectónicos que ayudan a evitar que el nuevo sistema quede atrapado en una red más frágil que la anterior.

Revisar identidades, permisos y cuentas técnicas

Las cuentas de usuario no son un detalle administrativo posterior. Determinan quién puede acceder, qué acciones quedan atribuidas, cómo se recupera el control y qué integraciones seguirán funcionando durante el cambio.

Inventariar tipos de identidad

Hay que distinguir:

• usuarios internos nominativos;
• administradores;
• usuarios externos o invitados;
• cuentas compartidas;
• cuentas técnicas;
• propietarios contractuales;
• identidades utilizadas para facturación;
• cuentas de recuperación;
• tokens y credenciales de integración.

Mapear roles actuales y responsabilidades reales

Un perfil llamado «gestor» puede tener permisos distintos según el equipo. La preparación debe entender qué operaciones necesita cada función y qué accesos excesivos se han acumulado. La nueva aplicación no debería heredar privilegios simplemente porque existían en la antigua.

Identificar recursos cuya propiedad depende de una cuenta

Formularios, informes, automatizaciones, carpetas o paneles pueden pertenecer a un usuario concreto. Eliminar o desactivar esa identidad antes de transferirlos puede dejar recursos huérfanos.

Preparar la correspondencia de identidades

No siempre existe una equivalencia directa. La nueva herramienta puede utilizar otros roles, dominios, métodos de autenticación o reglas para usuarios externos. Conviene diseñar la correspondencia antes de crear cuentas masivamente.

Integrar altas, bajas y recuperación

La sustitución debe dejar la aplicación nueva dentro del proceso normal de gestión de accesos. También necesita administradores alternativos, recuperación comprobada y protección proporcional de las cuentas críticas. Cómo crear políticas de acceso en una empresa pequeña ofrece criterios para ordenar esta parte sin convertirla en burocracia.

Clasificar qué debe conservarse, mejorarse o dejar de hacerse

Uno de los mayores errores consiste en tratar cada función de la aplicación actual como un requisito obligatorio. Algunas capacidades son esenciales, otras se utilizan por costumbre y otras compensan defectos del proceso. La sustitución ofrece una oportunidad para separar valor real e inercia.

Utilizar escenarios y no nombres de botones

«Necesitamos el campo Prioridad 2» puede ser una petición heredada. «Necesitamos distinguir expedientes que deben atenderse en el mismo día» expresa la necesidad real. Formular requisitos mediante escenarios permite que la nueva herramienta resuelva el problema con otra estructura.

Conservar controles, no necesariamente rituales

Un proceso puede incluir una hoja firmada, una doble introducción o una aprobación por correo porque era la única manera de obtener trazabilidad. Si el destino ofrece un control equivalente o mejor, no hace falta reproducir el ritual. Lo que debe preservarse es la finalidad: autorización, evidencia, separación de funciones o comprobación.

Registrar decisiones negativas

Las funciones que se abandonan necesitan una explicación breve. Sin ella, durante la implantación alguien puede pedir que se reconstruyan por miedo o costumbre, ampliando el alcance sin revisar su valor.

Diseñar el modelo operativo objetivo

Antes de configurar la nueva aplicación, la empresa necesita describir cómo debería funcionar el proceso una vez completada la sustitución. Este modelo objetivo actúa como puente entre la necesidad empresarial y la implantación técnica.

Definir dónde empieza y termina la responsabilidad del nuevo sistema

La aplicación nueva no tiene que asumir todo lo que hacía la anterior. Puede recibir información desde un formulario, coordinar una fase y entregar resultados a un repositorio o sistema económico. Las fronteras deben ser visibles para evitar que el destino se convierta en otra plataforma que hace «un poco de todo».

Asignar fuentes de verdad

Para cada dato importante debe indicarse dónde se crea, dónde puede modificarse y qué copias son de consulta. La autoridad puede repartirse por dominios: el sistema comercial gobierna los clientes, el gestor de trabajo los proyectos, el repositorio los documentos y la herramienta económica las facturas.

Definir papeles de las aplicaciones

El modelo puede apoyarse en cómo organizar aplicaciones por procesos de negocio para distinguir sistemas principales, auxiliares, de archivo, integración o contingencia. Esa clasificación ayuda a explicar el futuro entorno a usuarios y administradores.

Diseñar excepciones principales

El recorrido ideal rara vez es suficiente. Debe saberse qué ocurrirá con cancelaciones, duplicados, devoluciones, reasignaciones, registros incompletos, accesos externos y operaciones iniciadas antes del cambio. No hace falta resolver cada caso raro, pero sí aquellos que pueden bloquear la transición.

Definir qué trabajo seguirá siendo manual

Una sustitución no tiene que automatizarlo todo. Los pasos manuales pueden ser razonables si tienen responsable, información de entrada, resultado y control claros. Lo peligroso es que queden ocultos como conocimiento personal.

Mantener el modelo suficientemente estable

El diseño debe describir responsabilidades y reglas, no cada detalle de pantalla. Las interfaces y campos pueden ajustarse durante la implantación; las decisiones sobre autoridad, límites y resultados necesitan mayor estabilidad.

Elegir entre reemplazo equivalente y rediseño del proceso

No todas las sustituciones persiguen el mismo grado de cambio. Definirlo evita una expectativa contradictoria: pedir que la nueva herramienta se comporte exactamente como la anterior y, al mismo tiempo, transforme por completo la operativa.

Reemplazo equivalente

Busca mantener el proceso con cambios mínimos. Puede ser adecuado cuando el motivo principal es el fin de soporte, el coste, la seguridad, la continuidad del proveedor o una obligación técnica. Reduce el número de variables y facilita comparar antes y después.

Mejora controlada

Conserva el proceso esencial, pero corrige fricciones conocidas: campos redundantes, aprobaciones poco claras, informes manuales o duplicación de datos. Suele ser un equilibrio razonable para una pequeña empresa.

Rediseño amplio

Cambia proceso, responsabilidades, datos y herramienta simultáneamente. Puede producir un beneficio mayor, pero también dificulta diagnosticar incidencias y aumenta formación, pruebas y riesgo. Requiere más capacidad y una justificación clara.

Sustitución por varias piezas

Una plataforma amplia puede reemplazarse por aplicaciones especializadas. Esto reduce concentración y puede mejorar encaje, pero añade fronteras, integraciones y responsabilidades. El diseño debe demostrar que la modularidad resultante será gobernable.

Consolidación en una plataforma

Varias herramientas pueden trasladarse a una suite. La simplificación de contratos y accesos no garantiza una operativa más sencilla si la plataforma obliga a adaptar procesos o concentra demasiado riesgo.

Elegir conscientemente el nivel de transformación

El tipo de sustitución debe quedar escrito junto con lo que se mantendrá estable. Cuando los recursos son limitados, cambiar primero la aplicación y mejorar después puede ser más seguro que intentar resolver todas las deficiencias históricas en un único proyecto.

Preparar la coexistencia temporal sin crear dos verdades

Durante un cambio puede ser inevitable que ambas aplicaciones estén disponibles. La coexistencia no debe improvisarse una vez iniciada la migración; necesita reglas previas para que el solapamiento no multiplique trabajo ni contradicciones.

Definir por qué deben coexistir

Puede ser necesario por validación, migración gradual, consulta histórica, reversión o contratos. Cada motivo implica una duración y unos permisos diferentes. Mantener el sistema antiguo «por si acaso» sin condición de salida conduce a una transición permanente.

Asignar autoridad por periodo y tipo de dato

Antes del corte, la aplicación actual puede seguir siendo autoridad. Durante un piloto, un conjunto delimitado de casos puede nacer en el destino. Después del corte, el origen puede quedar en modo lectura. Estas reglas deben poder explicarse en pocas frases.

Evitar doble actualización generalizada

Obligar a los usuarios a introducir lo mismo en ambos sistemas crea fatiga y divergencias. Si una duplicación temporal es imprescindible, debe limitarse a datos concretos, tener responsable y utilizarse durante el menor tiempo posible.

Controlar casos abiertos

Los expedientes iniciados antes del cambio pueden terminar en el sistema antiguo, migrarse en un punto determinado o dividirse según estado. La decisión debe tomarse por tipos de caso, no dejarse a la preferencia de cada usuario.

Definir accesos del sistema anterior

Conservar lectura no implica mantener todos los administradores ni todas las integraciones. Los permisos pueden reducirse progresivamente, siempre que no se destruya la capacidad de consulta o reversión necesaria.

Establecer la condición de fin

La coexistencia termina cuando se cumplen criterios definidos: datos validados, procesos activos en el destino, periodo de observación completado, obligaciones de histórico resueltas y reversión ya innecesaria. La retirada definitiva llegará después mediante su propio procedimiento.

Construir un calendario desde las restricciones reales

Una fecha deseada no es todavía un plan. El calendario debe construirse hacia atrás desde contratos, periodos críticos, disponibilidad de personas, pruebas y dependencias, incorporando margen para corregir lo que la preparación descubra.

Identificar fechas externas

Pueden existir:

• fin de soporte o servicio;
• renovación automática;
• preaviso contractual;
• cierre contable o fiscal;
• campaña comercial;
• periodo de alta actividad;
• auditoría;
• ausencias de personas clave;
• cambios de infraestructura;
• caducidad de una oferta o de un entorno de prueba.

Diferenciar hitos de preparación y ejecución

El calendario debería incluir primero decisiones: alcance aprobado, exportación verificada, dependencias inventariadas, modelo objetivo validado, coste autorizado y puerta de inicio superada. Después pueden programarse configuración, pruebas, piloto, cargas y corte.

Reservar tiempo para corregir

Una prueba que no deja margen para repetir no es una prueba, sino un ensayo del cambio definitivo. Las cargas, integraciones y permisos necesitan ciclos de ajuste.

No fijar el corte por agotamiento contractual

Esperar hasta los últimos días de una licencia para empezar obliga a elegir entre renovar o cambiar sin preparación. En aplicaciones importantes conviene aceptar un periodo de solapamiento presupuestado en lugar de convertir el ahorro de una cuota en un riesgo operativo.

Proteger la disponibilidad de quienes conocen el sistema

La persona que entiende datos, excepciones o integraciones no puede estar ausente en los hitos decisivos. Si esa disponibilidad es limitada, debe influir en la secuencia y fomentar documentación temprana.

Coordinar contratos, licencias y periodos de solapamiento

La transición tecnológica y la contractual avanzan a ritmos distintos. Una empresa puede estar preparada técnicamente y seguir obligada por un compromiso, o cancelar demasiado pronto y perder acceso necesario para comprobar información.

Revisar las condiciones del sistema actual

Conviene identificar:

• fecha de renovación y preaviso;
• periodo mínimo;
• procedimiento de cancelación;
• derechos de exportación;
• acceso tras cancelar;
• costes de servicios de salida;
• propiedad de configuraciones y desarrollos;
• efecto sobre productos contratados en paquete;
• obligaciones de devolución o eliminación de datos;
• soporte disponible durante la transición.

Revisar las condiciones del destino

No basta con el precio de entrada. Hay que comprobar plan mínimo válido, límites, usuarios externos, API, almacenamiento, entornos de prueba, soporte, exportación futura y condiciones de aumento o reducción de licencias.

Presupuestar el solapamiento

Pagar temporalmente ambas aplicaciones puede ser una medida de control. Debe definirse la duración máxima, el motivo y la condición para finalizarla. Sin ese límite, el periodo provisional puede convertirse en otro coste permanente.

Evitar compromisos largos antes de validar

Cuando sea posible, la contratación inicial debería conservar margen de reversibilidad hasta que las capacidades críticas estén probadas. Un descuento anual no compensa quedar comprometido con una herramienta que todavía no ha demostrado el proceso real.

Coordinar titularidad y medios de pago

La nueva solución debe quedar bajo control empresarial desde el principio, con cuentas administrativas, facturación y recuperación apropiadas. Cómo gestionar correctamente las licencias de software desarrolla el gobierno del ciclo contractual y de asignación que la sustitución debe respetar.

Estimar coste total y capacidad interna necesaria

El coste de sustituir software no se limita a la diferencia entre dos cuotas. La preparación debe estimar el esfuerzo de transición y comprobar que la empresa dispone de tiempo, conocimiento y atención suficientes para ejecutarla sin descuidar su actividad ordinaria.

Componentes de coste

Entre otros, pueden aparecer:

• licencias solapadas;
• configuración del destino;
• servicios profesionales;
• extracción, limpieza y transformación de datos;
• reconstrucción de integraciones;
• pruebas;
• formación;
• documentación;
• soporte reforzado;
• trabajo manual temporal;
• pérdida de productividad durante la adaptación;
• archivo o conservación del sistema anterior;
• contingencias y repetición de tareas.

Separar gasto y esfuerzo interno

Una tarea sin factura sigue consumiendo capacidad. Si la misma persona administra el cambio y realiza trabajo crítico, sus horas tienen un coste de oportunidad y una disponibilidad limitada. La planificación debe indicar qué actividad ordinaria se reducirá o quién cubrirá las tareas.

Estimar por escenarios

Un escenario mínimo, probable y adverso resulta más útil que una cifra aparentemente exacta. La variación puede depender de la calidad de los datos, el número de integraciones que deban reconstruirse o la necesidad de mantener el sistema anterior más tiempo.

Definir una reserva de contingencia

Las sustituciones contienen incertidumbre real. Reservar margen económico y temporal no significa planificar mal, sino reconocer que algunas dependencias solo se revelan al probar.

Comparar coste de cambio y coste de permanencia

La decisión necesita ambos lados. Permanecer puede implicar subidas de precio, riesgos de soporte, trabajo manual y limitaciones de crecimiento. Cambiar introduce un coste inicial y nuevos riesgos. Cómo calcular el coste real de software ayuda a ampliar esta comparación sin reducirla a la licencia visible.

Comprobar capacidad de mantener el destino

Una aplicación puede ser viable para implantar y difícil de administrar durante años. Hay que valorar altas, permisos, integraciones, cambios, copias o exportaciones, soporte y conocimiento necesario después del proyecto.

Construir un registro de riesgos accionable

Una lista genérica de riesgos no protege la transición. Cada riesgo debe relacionarse con un escenario, una señal, una medida preventiva, una respuesta y una persona responsable.

Riesgos habituales

• exportación incompleta;
• pérdida de relaciones o adjuntos;
• integración no descubierta;
• función crítica inexistente en el destino;
• usuarios que mantienen sistemas paralelos;
• permisos excesivos o insuficientes;
• incompatibilidad con un proceso externo;
• retraso contractual;
• dependencia de una persona o proveedor;
• volumen superior al probado;
• rendimiento insuficiente;
• coste mayor de lo previsto;
• imposibilidad de volver atrás;
• conservación inadecuada de información;
• interrupción durante un periodo crítico.

Describir causa, acontecimiento e impacto

«Problemas con los datos» es demasiado vago. Una formulación útil sería: «Si la exportación no conserva los identificadores de relación, los proyectos podrían quedar desvinculados de sus clientes y sería necesario reconstruirlos manualmente». Esa frase permite diseñar una prueba y asignar una respuesta.

Utilizar señales tempranas

El riesgo puede vigilarse mediante indicadores: porcentaje de registros rechazados, diferencias entre recuentos, integraciones sin propietario, usuarios sin correspondencia de rol o pruebas que no cubren el volumen previsto.

Definir umbrales de parada

Algunos hallazgos deben detener el proyecto: pérdida no explicada de datos críticos, incapacidad para recuperar el sistema, incumplimiento de un requisito obligatorio o falta de una persona responsable. Continuar por presión de calendario convierte una señal de advertencia en una incidencia real.

Mantener el registro vivo

Los riesgos cambian al obtener evidencia. Algunos se cierran, otros aumentan y aparecen nuevos. La revisión debe formar parte de cada puerta de decisión, no guardarse como documento ceremonial.

Preparar continuidad, reversión y contingencia

Una sustitución responsable asume que algo puede fallar. La continuidad define cómo seguirá funcionando la empresa; la reversión, cómo se recuperará el estado anterior cuando todavía sea posible; y la contingencia, qué solución temporal se utilizará ante una incidencia concreta.

Definir funciones mínimas que deben continuar

No todos los procesos necesitan el mismo nivel de protección. Conviene identificar qué operaciones no pueden detenerse, cuáles pueden esperar y cuáles pueden realizarse manualmente durante un periodo limitado.

Diseñar una contingencia simple

Puede consistir en un formulario temporal, una plantilla controlada, un procedimiento de registro posterior o acceso de solo lectura al sistema anterior. La contingencia debe capturar la información necesaria para reconciliar después, no crear una tercera operativa permanente.

Definir el punto de no retorno

La reversión es más fácil antes de que existan cambios distribuidos entre ambos sistemas. Hay que saber hasta qué momento puede volverse al origen sin perder datos, qué información habría que recapturar y quién autoriza esa decisión.

Proteger copias y configuraciones

Además de los datos, puede ser necesario conservar exportaciones de configuración, documentación, instaladores, claves válidas, versiones o imágenes de sistemas cuando el modelo técnico lo requiera. La protección debe ser legal y operativamente adecuada.

Evitar prometer reversión ilimitada

Mantener dos sistemas plenamente operativos durante meses puede costar más y aumentar el riesgo. La capacidad de volver atrás debe tener una ventana definida. Después, la estrategia cambia de reversión a recuperación o corrección sobre el destino.

Probar la contingencia

Un procedimiento que nadie ha ejecutado puede fallar por permisos, formatos o falta de instrucciones. Las pruebas de preparación deben incluir al menos los escenarios de interrupción con mayor impacto.

Integrar seguridad, privacidad y conservación

La transición aumenta temporalmente la superficie de exposición: existen dos aplicaciones, más administradores, exportaciones completas, entornos de prueba y archivos intermedios. La preparación debe controlar ese periodo excepcional.

Minimizar datos en pruebas

Cuando sea posible, deben utilizarse conjuntos reducidos, anonimizados o sintéticos. Si se necesitan datos reales para validar casos complejos, el acceso y la eliminación posterior requieren reglas explícitas.

Proteger exportaciones e intermedios

Los archivos de migración suelen contener información más concentrada que la aplicación cotidiana. Debe definirse dónde se guardan, quién accede, cómo se transfieren, cuánto tiempo se conservan y cómo se eliminan cuando dejan de ser necesarios.

Aplicar mínimo privilegio a equipos y proveedores

Los permisos elevados utilizados para extraer o cargar datos deben ser temporales. También conviene separar cuentas de administración, integración y uso ordinario, manteniendo trazabilidad sobre acciones críticas.

Conservar evidencias relevantes

Contratos, aprobaciones, históricos, registros o documentos pueden tener plazos y finalidades de conservación distintos. Archivar no significa guardar todo indefinidamente; significa conservar lo necesario en un formato accesible, protegido y comprensible.

Revisar transferencias y ubicaciones

La nueva solución puede cambiar dónde se almacenan los datos, qué subproveedores participan o cómo acceden usuarios móviles y externos. Estas diferencias deben evaluarse antes de aprobar el destino, no después del traslado.

Preparar la eliminación final sin ejecutarla todavía

La fase de preparación debe identificar qué copias, usuarios, tokens y datos deberán retirarse del sistema anterior y de los espacios intermedios. La eliminación se realizará cuando la transición esté validada y ya no comprometa la continuidad.

Preparar a las personas sin iniciar todavía la implantación

La sustitución modifica tareas, responsabilidades y referencias. Comunicar demasiado tarde genera resistencia; comunicar demasiado pronto un resultado todavía incierto puede crear expectativas y fatiga. La preparación debe involucrar a las personas adecuadas en el momento adecuado.

Identificar grupos afectados

No solo participan los usuarios frecuentes. También pueden verse afectados responsables que reciben informes, administradores, colaboradores externos, personas que consultan históricos, soporte y quienes realizan tareas antes o después del proceso.

Recoger conocimiento operativo

Las entrevistas deben buscar hechos y escenarios: qué tarea se realiza, qué información se necesita, qué excepción aparece y qué ocurre si el sistema no responde. Preguntar únicamente si gusta la aplicación produce opiniones difíciles de convertir en requisitos.

Detectar prácticas no oficiales sin culpabilizar

Las hojas y herramientas alternativas suelen revelar necesidades que el sistema no cubre. Ocultarlas por miedo a una reprimenda perjudica la preparación. El objetivo es comprender por qué existen y decidir si se integran, sustituyen o abandonan.

Crear una red de usuarios clave

Un grupo pequeño y representativo puede validar procesos, datos, terminología y criterios de aceptación. No debe estar formado solo por entusiastas ni por administradores; necesita personas que conozcan trabajo frecuente, ocasional y excepcional.

Definir el mensaje de cambio

Antes de anunciar fechas conviene poder explicar:

• por qué se estudia la sustitución;
• qué problemas pretende resolver;
• qué todavía no está decidido;
• quién participará;
• cómo se recogerán incidencias y necesidades;
• cuándo se comunicará el plan definitivo.

Separar consulta y decisión

Escuchar a los usuarios no significa que cada preferencia se convierta en requisito. Debe existir un criterio transparente para distinguir necesidad operativa, control, comodidad y costumbre.

Asignar gobierno y responsabilidades de transición

Una sustitución pequeña también necesita gobierno. No se trata de crear una estructura pesada, sino de evitar que datos, contratos, decisiones y configuración queden repartidos entre personas sin una autoridad clara.

Patrocinador o decisor

Valida el motivo, autoriza recursos, resuelve conflictos de prioridad y decide si el proyecto continúa ante cambios relevantes.

Responsable funcional

Representa el proceso y confirma que el modelo objetivo permite trabajar. Debe entender resultados y excepciones, no solo conocer la interfaz actual.

Responsable técnico

Analiza integraciones, identidades, datos, seguridad, entornos y capacidad de operación. Puede ser interno o externo, pero sus entregables deben quedar bajo control de la empresa.

Responsable de datos

Decide criterios de calidad, alcance histórico, fuentes de verdad y validación. En una empresa pequeña puede coincidir con el responsable funcional, siempre que la responsabilidad sea explícita.

Responsable contractual

Controla licencias, renovaciones, preavisos, facturación y condiciones de salida y entrada.

Usuarios validadores

Ejecutan escenarios representativos y confirman que las tareas reales se han entendido correctamente.

Proveedor o especialista

Debe tener alcance, accesos, entregables y responsabilidades delimitados. La empresa necesita conservar documentación, credenciales y capacidad de supervisión.

Matriz mínima de decisiones

Para cada decisión importante conviene saber quién propone, quién valida, quién ejecuta y quién debe ser informado. Esa sencillez evita que una duda sobre datos o alcance quede bloqueada durante semanas.

Definir criterios de aceptación y una puerta de decisión

La preparación termina cuando existen condiciones suficientes para empezar la implantación de forma controlada. No debe terminar porque llegue una fecha arbitraria o porque ya se haya comprado la nueva licencia.

Requisitos obligatorios

Son condiciones sin las que no se autoriza el cambio: capacidad funcional crítica, exportación, seguridad, volumen, permisos, integración o continuidad. No deben compensarse con ventajas secundarias.

Criterios medibles

Siempre que sea razonable, los criterios deben expresarse mediante evidencia:

• el 100 % de los conjuntos de datos críticos tiene tratamiento definido;
• todas las integraciones críticas tienen propietario y estrategia;
• la exportación de muestra conserva relaciones obligatorias;
• los roles del destino cubren los perfiles necesarios;
• el coste probable está autorizado;
• existe una contingencia para los procesos de criticidad alta;
• las responsabilidades y decisiones pendientes están asignadas;
• no queda ningún bloqueo contractual desconocido.

Clasificar asuntos pendientes

No todo debe resolverse antes de empezar. Conviene separar:

• bloqueos, que impiden continuar;
• condiciones, que deben cerrarse antes de un hito concreto;
• riesgos aceptados, con respuesta y responsable;
• mejoras posteriores, fuera del alcance inicial.

Celebrar una revisión de preparación

La puerta de decisión debe responder cuatro preguntas: ¿sabemos qué cambia?, ¿podemos demostrar que el destino puede asumirlo?, ¿tenemos recursos y controles suficientes?, ¿sabemos detenernos o volver atrás si falla? La decisión puede ser continuar, continuar con condiciones, aplazar o cancelar.

Documentar la razón final

La aprobación debe registrar qué evidencia la sostiene y qué supuestos permanecen. Esto permite revisar después si el proyecto se desvió o si cambió una condición esencial.

Diseñar las pruebas antes de tocar producción

Las pruebas forman parte de la implantación, pero su estrategia debe prepararse antes. Si se decide qué probar después de configurar, la tendencia será comprobar únicamente lo que ya funciona y olvidar las condiciones que justificaron el cambio.

Crear escenarios representativos

La batería debe incluir:

• recorrido normal de principio a fin;
• operaciones frecuentes;
• excepciones importantes;
• correcciones y reversión de errores;
• perfiles con permisos diferentes;
• integraciones críticas;
• volumen y rendimiento razonables;
• exportación y recuperación;
• indisponibilidad o fallo de una dependencia;
• consulta de históricos.

Definir datos de prueba

Deben representar la diversidad real sin exponer información innecesaria. Conviene incluir caracteres, relaciones, adjuntos, estados y casos límite que hayan causado problemas en el sistema actual.

Asignar resultado esperado

Cada escenario necesita una salida observable. «Probar la integración» es ambiguo; «al crear una solicitud válida, se genera un registro con identificador, responsable y fecha, y el error queda registrado si el destino no responde» permite aceptar o rechazar.

Distinguir pruebas técnicas y aceptación funcional

Que una API devuelva datos no demuestra que el proceso sea correcto. Los usuarios validadores deben confirmar que la información, secuencia y resultado permiten realizar el trabajo.

Preparar trazabilidad de incidencias

Las pruebas deben registrar versión, datos, resultado, evidencia, gravedad, responsable y repetición. Esta disciplina evita aceptar una solución basándose en recuerdos o capturas aisladas.

Definir criterios de salida de las pruebas

No es necesario eliminar cualquier defecto, pero sí cerrar los bloqueos y aceptar conscientemente las limitaciones restantes. La gravedad debe relacionarse con el proceso, no solo con la apariencia de la interfaz.

Crear un expediente de sustitución mantenible

La preparación produce mucha información. Si queda dispersa entre correos, chats, hojas y conversaciones, la implantación repetirá preguntas y perderá decisiones. El expediente debe reunir lo necesario para ejecutar y auditar el cambio sin convertirse en un documento gigantesco imposible de mantener.

Contenido mínimo recomendado

• motivo y resultados esperados;
• alcance, exclusiones y fases;
• línea base;
• mapa de procesos afectados;
• inventario de datos y decisión por conjunto;
• registro de dependencias;
• inventario de integraciones e identidades;
• modelo operativo objetivo;
• clasificación de capacidades;
• calendario y restricciones;
• contratos y licencias;
• estimación de coste y capacidad;
• registro de riesgos;
• continuidad y reversión;
• criterios de aceptación;
• estrategia de pruebas;
• responsables y decisiones pendientes.

Separar hechos, decisiones y supuestos

Un hecho está comprobado; una decisión tiene responsable y fecha; un supuesto necesita validación. Mezclarlos hace que una afirmación provisional termine tratándose como verdad durante la ejecución.

Utilizar anexos vivos

Inventarios, matrices y registros pueden mantenerse como documentos estructurados separados y enlazados desde un resumen. Así es posible actualizar datos sin reescribir todo el expediente.

Versionar cambios de alcance

Cuando se añade un módulo, se elimina un histórico o cambia una fecha, debe quedar constancia de la razón y el impacto. El objetivo no es burocratizar, sino evitar que el proyecto termine ejecutando un alcance distinto del autorizado sin saberlo.

Proteger información sensible

El expediente puede contener arquitectura, contratos, nombres de administradores y detalles de datos. Los secretos y credenciales deben mantenerse en sistemas apropiados, no incrustarse en documentación de acceso amplio.

Preparar una versión operativa para cada audiencia

Dirección necesita decisiones, coste y riesgo; el equipo técnico, dependencias y pruebas; los usuarios, cambios de proceso y responsabilidades. Un núcleo común puede generar vistas distintas sin mantener narrativas contradictorias.

Ejemplo práctico de preparación

Imaginemos una empresa de servicios profesionales con diez personas que utiliza desde hace seis años una aplicación para gestionar oportunidades, presupuestos y seguimiento de trabajos. El proveedor ha aumentado el precio, algunas funciones dependen de un plan superior y los usuarios mantienen hojas auxiliares para controlar entregas. La empresa ha comparado alternativas y dispone de una candidata, pero todavía no sabe qué implicaría sustituir el sistema.

1. Motivo y resultado

El objetivo no se formula como «pagar menos». Se define así: centralizar el seguimiento comercial y operativo, eliminar la doble actualización de estados, conservar el histórico necesario y reducir la dependencia de una configuración que solo conoce una persona. El ahorro de licencia es un beneficio adicional, no el único criterio.

2. Perímetro

La aplicación actual también envía formularios y almacena documentos. Se decide que la primera fase sustituirá oportunidades, presupuestos y proyectos activos. Los formularios continuarán temporalmente y los documentos definitivos permanecerán en el repositorio existente. El histórico de proyectos cerrados no se cargará completo en la nueva herramienta; se preparará un archivo consultable.

3. Línea base

Se identifican ocho usuarios frecuentes, dos usuarios de consulta, unas 2.500 organizaciones, 7.000 contactos, 430 proyectos cerrados y 38 activos. Cada semana se actualizan manualmente dos hojas. El cierre mensual utiliza un informe que combina una exportación con datos económicos.

4. Dependencias

La revisión descubre cuatro conexiones: un formulario crea oportunidades, una automatización genera carpetas, una hoja importa estados y el correo registra conversaciones. También existe una cuenta técnica utilizada por el informe mensual y una plantilla de presupuestos mantenida por una persona.

5. Datos

La exportación estándar incluye contactos y proyectos, pero no adjuntos ni historial completo. Una prueba revela que las relaciones entre organizaciones y contactos se conservan mediante identificadores, mientras que determinados estados antiguos necesitan transformación. Se decide migrar datos maestros, oportunidades abiertas, presupuestos vigentes y proyectos activos; el resto se archivará con un índice.

6. Capacidades

Se clasifican como obligatorias la asignación de responsables, el historial de actividad, los presupuestos y la relación entre cliente y proyecto. Se mejorará la gestión de estados y se abandonará una clasificación de veinte categorías que nadie utiliza de forma consistente. La hoja de entregas no se reproducirá si la nueva vista operativa supera las pruebas.

7. Modelo objetivo

El sistema nuevo será autoridad para oportunidades y estado operativo. El repositorio seguirá siendo autoridad para documentos finales. El sistema económico mantendrá importes facturados. Las integraciones tendrán dirección clara: formulario hacia sistema nuevo, sistema nuevo hacia repositorio y exportación controlada hacia el informe.

8. Coexistencia

Durante el piloto, solo cinco casos nuevos se crearán en el destino. El resto seguirá en origen. Tras el corte, los nuevos trabajos nacerán en la nueva aplicación y la anterior quedará en lectura para históricos. No se permitirá que un mismo proyecto activo se edite libremente en ambas.

9. Contratos y calendario

La licencia actual se renueva en cuatro meses y exige treinta días de preaviso. Se presupuestan dos meses de solapamiento. El corte no se realizará durante el cierre anual ni durante la ausencia del responsable de datos.

10. Riesgos y continuidad

El mayor riesgo es perder contexto de presupuestos y comunicaciones. Se diseña una prueba específica y se conserva una exportación original. Si la integración del formulario falla, las solicitudes se almacenarán temporalmente en una bandeja controlada y se cargarán después. La reversión será posible hasta una semana después del corte, siempre que se registren los cambios nuevos.

11. Puerta de decisión

La implantación no comenzará hasta que la exportación de muestra sea validada, los roles cubran a usuarios internos y externos, el informe mensual tenga diseño alternativo, el coste probable esté autorizado y las cuatro dependencias dispongan de tratamiento y responsable.

12. Resultado de la preparación

La empresa descubre que no va a «cambiar una aplicación», sino a reasignar varias responsabilidades entre tres sistemas. El proyecto queda limitado, se evitan dos migraciones innecesarias y la candidata puede probarse contra escenarios reales. También aparece una posible conclusión honesta: si el informe y los presupuestos no superan las pruebas, la sustitución se aplazará aunque ya exista preferencia por la nueva herramienta.

Método completo paso a paso

1. Confirmar la necesidad de cambio. Definir el problema y comprobar que no puede resolverse razonablemente mediante configuración, formación o ajuste contractual.
2. Confirmar una candidata viable. Verificar requisitos obligatorios y evitar preparar una transición alrededor de una herramienta todavía no comparada.
3. Nombrar responsables. Asignar decisión, proceso, técnica, datos, contratos y validación.
4. Delimitar el perímetro. Separar procesos, módulos, datos, integraciones, informes, identidades y contratos.
5. Registrar exclusiones. Indicar qué no cambia, quién lo mantiene y hasta cuándo.
6. Construir la línea base. Medir uso, volumen, coste, calidad, incidencias y trabajo auxiliar.
7. Recorrer casos reales. Incluir operaciones frecuentes y excepciones con usuarios representativos.
8. Mapear procesos. Identificar el papel de la aplicación y la criticidad de cada función.
9. Inventariar dependencias. Funcionales, de datos, técnicas, contractuales, de identidad y conocimiento.
10. Inventariar datos. Clasificar maestros, activos, históricos, documentos, configuración y registros.
11. Probar la salida. Realizar una exportación representativa y comprobar integridad, relaciones y límites.
12. Inventariar integraciones. Documentar origen, destino, propósito, errores y responsable.
13. Revisar identidades. Usuarios, roles, administradores, cuentas técnicas, propiedad y recuperación.
14. Clasificar capacidades. Conservar, mejorar, simplificar, separar, posponer, abandonar o investigar.
15. Definir el grado de transformación. Reemplazo equivalente, mejora controlada, rediseño, consolidación o separación.
16. Diseñar el modelo objetivo. Fronteras, fuentes de verdad, excepciones y pasos manuales.
17. Preparar coexistencia. Autoridad, casos abiertos, accesos, duración y condición de fin.
18. Revisar calendario. Contratos, periodos críticos, disponibilidad, pruebas y margen de corrección.
19. Revisar licencias y contratos. Entrada, salida, solapamiento, soporte y titularidad.
20. Estimar coste y capacidad. Incluir esfuerzo interno, escenarios y contingencia.
21. Construir el registro de riesgos. Causa, impacto, señal, control, respuesta y responsable.
22. Diseñar continuidad. Funciones mínimas, contingencia, reversión y punto de no retorno.
23. Integrar seguridad y conservación. Datos de prueba, exportaciones, accesos, evidencias y eliminación futura.
24. Preparar participación y comunicación. Usuarios clave, conocimiento operativo y mensaje de cambio.
25. Definir la estrategia de pruebas. Escenarios, datos, resultados esperados, evidencia y criterios de salida.
26. Crear el expediente. Reunir hechos, decisiones, supuestos y anexos bajo control de versiones.
27. Resolver bloqueos. No trasladar incertidumbres críticas a la implantación.
28. Celebrar la puerta de decisión. Continuar, continuar con condiciones, aplazar o cancelar.
29. Entregar a implantación. Transferir alcance, modelo, riesgos, pruebas y responsabilidades de forma explícita.
30. Actualizar durante la ejecución. Mantener el expediente como referencia cuando aparezcan cambios relevantes.

El método puede adaptarse al tamaño y criticidad. Una herramienta auxiliar no necesita el mismo nivel de documentación que un sistema central, pero las preguntas esenciales siguen siendo válidas: qué sustituye, qué depende de él, qué información debe sobrevivir y qué evidencia autoriza el cambio.

Indicadores de preparación

Los indicadores no deben convertir la sustitución en una puntuación automática. Sirven para descubrir huecos y comprobar si la incertidumbre disminuye antes de comprometer la operativa.

Cobertura del perímetro

Porcentaje de procesos, módulos y grupos afectados con decisión explícita. Los elementos «por decidir» deben ser visibles.

Dependencias con propietario

Proporción de dependencias identificadas que tienen criticidad, tratamiento y responsable.

Datos con estrategia definida

Conjuntos clasificados para migrar, archivar, conservar en origen, transformar o eliminar de forma justificada.

Exportación verificada

Porcentaje de tipos de dato críticos incluidos en una extracción real y validados, no solo anunciados por documentación.

Integraciones cubiertas

Conexiones críticas con alternativa, diseño o decisión de retirada.

Roles correspondidos

Perfiles de usuario actuales que disponen de un tratamiento definido en el destino.

Requisitos obligatorios demostrados

Condiciones no negociables verificadas mediante prueba, documentación contractual o evidencia técnica.

Riesgos sin respuesta

Número de riesgos altos que todavía carecen de control, contingencia o responsable. Debería tender a cero antes de la puerta de inicio.

Coste y capacidad autorizados

Confirmación de que existe presupuesto y disponibilidad real de personas durante los hitos previstos.

Decisiones pendientes vencidas

Asuntos que no se han cerrado en la fecha necesaria. Su crecimiento suele indicar falta de gobierno o un alcance demasiado amplio.

Preparación de continuidad

Procesos críticos con contingencia documentada y, cuando corresponda, probada.

Confianza basada en evidencia

Puede registrarse qué afirmaciones clave están comprobadas, cuáles dependen de un proveedor y cuáles siguen siendo supuestos. El objetivo es reducir la parte del plan basada únicamente en confianza verbal.

Errores habituales

Tratar la sustitución como una compra

Elegir y contratar la nueva herramienta no resuelve datos, dependencias, procesos ni continuidad.

Empezar a configurar antes de cerrar el alcance

La aplicación comienza a llenarse de campos y automatizaciones mientras todavía se discute qué debe asumir.

Creer que todo lo que hace el sistema actual debe reproducirse

Se trasladan funciones obsoletas, rituales y deuda operativa al destino.

Definir requisitos con nombres de pantallas

Se obliga a la nueva herramienta a imitar la anterior en vez de resolver la necesidad.

Ignorar hojas, correo y procedimientos paralelos

La empresa sustituye la aplicación visible y deja sin solución parte del proceso real.

Confiar en una exportación no probada

Los problemas de adjuntos, relaciones, históricos o límites aparecen cuando ya no hay margen.

Migrar todo por defecto

Se aumenta coste y ruido sin distinguir información activa, histórica, obsoleta o exigible.

Olvidar integraciones humanas

Copias manuales, correos y controles personales pueden ser dependencias críticas aunque no tengan API.

Recrear todas las automatizaciones

Se copia una arquitectura antigua sin preguntar si cada flujo sigue teniendo sentido.

No revisar identidades y propiedad

Recursos, tokens o contratos quedan ligados a cuentas que desaparecerán.

Prometer una fecha antes de conocer restricciones

El calendario obliga después a sacrificar pruebas o aceptar riesgos no resueltos.

Cancelar para evitar pagar solapamiento

Un pequeño ahorro elimina lectura histórica, soporte o capacidad de reversión.

Comprar un compromiso largo antes de validar

La empresa pierde capacidad de corregir una elección todavía no probada en su contexto.

Subestimar el esfuerzo interno

Las tareas no facturadas compiten con el trabajo ordinario y retrasan ambos.

Crear un registro de riesgos decorativo

Los riesgos no tienen señal, respuesta ni responsable y no influyen en ninguna decisión.

Confundir contingencia con mantener tres sistemas

Una solución temporal sin fecha de cierre se convierte en otra operación permanente.

Involucrar solo a administradores

Se validan configuraciones, pero no excepciones ni trabajo cotidiano.

Convertir cada preferencia en requisito

El alcance crece y la herramienta se personaliza antes de demostrar el proceso principal.

No definir condiciones de parada

El proyecto continúa por inercia incluso cuando falla un requisito esencial.

Retirar el sistema anterior durante la preparación

Se destruye evidencia y reversibilidad antes de validar la nueva operativa.

No documentar decisiones negativas

Las funciones abandonadas reaparecen como peticiones urgentes durante la implantación.

Preparar una sustitución perfecta e interminable

El análisis también necesita proporcionalidad. Cuando la incertidumbre residual es asumible, debe pasar a pruebas y ejecución controladas.

Preguntas frecuentes

Conclusión

Preparar una empresa para sustituir una aplicación por otra exige dejar de pensar en software como una pieza aislada. La herramienta actual sostiene procesos, datos, identidades, integraciones, informes, hábitos y compromisos que deben hacerse visibles antes de mover la operativa.

La preparación empieza definiendo por qué se cambia y qué resultado debe alcanzarse. Después delimita el perímetro: qué funciones se sustituyen, qué componentes se mantienen, qué datos deben migrarse, qué históricos se archivarán y qué responsabilidades cambiarán de sistema. Una línea base real permite medir el punto de partida y descubrir procedimientos paralelos que la documentación formal no muestra.

Las dependencias son el núcleo del análisis. Exportaciones, automatizaciones, cuentas técnicas, documentos, informes, contratos y conocimiento individual pueden convertir una sustitución sencilla en un cambio de arquitectura. Identificarlas pronto permite decidir cuáles se recrean, se rediseñan, se separan o se abandonan.

También es necesario diseñar el modelo operativo objetivo. La nueva aplicación debe tener fronteras claras, fuentes de verdad conocidas y un papel comprensible dentro del ecosistema. No todas las funciones antiguas merecen sobrevivir: algunas deben conservarse, otras mejorarse y otras desaparecer para no trasladar deuda operativa.

El calendario debe construirse desde restricciones reales, con periodos de prueba, margen de corrección y un solapamiento contractual controlado cuando sea necesario. El coste incluye tanto facturas como tiempo interno, pérdida temporal de productividad, trabajo de datos, integraciones, formación, contingencias y mantenimiento posterior.

Una sustitución preparada dispone de riesgos accionables, continuidad, reversión limitada, seguridad para los datos intermedios y responsabilidades explícitas. También define pruebas y criterios de aceptación antes de configurar, de modo que la decisión no dependa de impresiones o del entusiasmo por una interfaz nueva.

El objetivo no es producir un plan perfecto ni eliminar cualquier incertidumbre. Es llegar a una puerta de decisión en la que la empresa pueda continuar, aplazar o cancelar con conocimiento suficiente. Cuando esa condición se cumple, la implantación deja de ser un salto de fe y se convierte en una transición controlada.