Hay proyectos que empiezan con una búsqueda razonable: ¿qué herramienta uso para migrar este entorno Domino a Exchange Online? Y hay proyectos que acaban con un agente de LotusScript generando JSON compatible con Microsoft Graph. Este es uno de esos.
El ecosistema de migración existe, pero no siempre encaja
Migrar desde HCL Domino a Microsoft 365 no es un problema sin solución. Existe un ecosistema de herramientas especializadas que van mucho más allá de una migración IMAP: algunas cubren correo, calendarios, contactos y hasta aplicaciones Domino. El mercado está ahí.
El problema no es la ausencia de opciones. El problema es que esas opciones tienen su propia opinión sobre qué migrar, cómo hacerlo y en qué condiciones. Cuando el entorno del cliente no encaja en esos parámetros, las herramientas pueden no ajustarse a los objetivos.
En este caso concreto, la necesidad era clara: migrar calendarios y contactos con fidelidad, con visibilidad completa sobre qué se había migrado y qué no, y con la capacidad de revertir elementos concretos sin depender de lo que la herramienta decidiera hacer por su cuenta. Las herramientas del mercado ofrecen ese control dentro de sus propios parámetros — el problema es que esos parámetros no siempre coinciden con los esperados por el cliente y su estructura de coste puede no encajar con el volumen y el contexto de la migración, aunque eso ya es conversación para otro departamento.
Cuando eso pasa, vale la pena preguntarse qué tienes disponible dentro del propio entorno.
LotusScript como punto de partida
HCL Domino lleva décadas con LotusScript como lenguaje nativo de automatización. Es una herramienta potente, con acceso directo a las bases de datos NSF, a las vistas, a los documentos y a todos sus campos. Si el objetivo es extraer datos de Domino en el formato exacto que necesitas, LotusScript es el sitio donde empezar.
La pregunta que orienta el diseño es sencilla: ¿qué formato espera el destino? Microsoft Graph API es explícita al respecto. Sus endpoints de calendario aceptan JSON con un esquema bien definido. Si puedes construir ese JSON desde LotusScript, el problema de extracción y transformación está resuelto. La inyección es entonces responsabilidad de PowerShell y el módulo Microsoft.Graph.
La arquitectura: tres piezas, una responsabilidad cada una
El pipeline resultante tiene tres componentes bien separados:
Agente de descubrimiento de schema. Antes de construir nada, hay que entender qué hay dentro de los buzones NSF. Este agente es transversal: inspecciona las vistas de Domino y vuelca la estructura de campos disponibles. El objetivo no es migrar, sino entender. Sin este paso, el mapeo posterior sería especulación.
Agente de exportación de calendarios. Opera sobre la estructura descubierta y extrae los eventos del calendario, transformándolos en un JSON listo para inyectar vía Graph. Lee el fichero mapping.csv con la lista de usuarios a procesar, itera sobre sus buzones NSF y genera dos archivos por usuario: data.json con los eventos en formato Graph, y state.csv con el estado de migración de cada elemento.
Scripts PowerShell con Microsoft.Graph. Consumen el data.json generado por el agente y llaman a Graph API para crear los eventos en Exchange Online. Una vez completada la operación, escriben el ExchangeId devuelto por Graph en el state.csv.
El state.csv es el contrato entre ambos mundos:
|
UNID
|
Status
|
MigratedDate
|
ExchangeId
|
|
ABC123...
|
migrated
|
2026-01-22T10:30:00
|
AAMkAGI2...
|
|
DEF456...
|
pending
|
|
|
|
XYZ789...
|
error
|
2026-01-22T10:31:00
|
|
El UNID es el identificador universal de Domino. El ExchangeId es el identificador que devuelve Graph tras crear el evento. Tener ambos en el mismo registro te da algo que las herramientas de terceros raramente exponen: control granular sobre el proceso desde fuera de la herramienta. Sabes exactamente qué elemento de Domino corresponde a qué elemento en Exchange Online, puedes actuar sobre esa información con lógica propia, y puedes deshacer la migración con precisión quirúrgica —eliminando únicamente los elementos con ExchangeId— sin tocar nada de lo que ya existía en Exchange Online antes de empezar.
Esto presenta una segunda funcionalidad que es importante en el proyecto de migración y es que permite la incrementalidad. Futuras pasadas del proceso respetarán entradas anteriores y solamente incorporarán nuevas entradas de calendario en Exchange Online.
El flujo completo:
1. EXPORT (LotusScript) → Genera data.json + state.csv
2. IMPORT (PowerShell) → Inyecta en Exchange Online, actualiza ExchangeId
3. VERIFY (Outlook Web) → Validación manual
4. CLEAR (si necesario) → Elimina solo elementos con ExchangeId
El caso difícil: recurrencias
Los eventos simples son triviales. La complejidad real aparece con las recurrencias, y en particular con las recurrencias relativas: el último viernes de noviembre, el segundo martes de cada mes, el cuarto jueves de octubre. Fechas que no son un número fijo en el calendario sino una posición relativa dentro de un período.
Antes de entrar en el mapeo, hay un elemento conceptual que no es obvio si no has trabajado con Domino: una serie recurrente no se representa como un único documento, sino como dos tipos distintos. El documento padre contiene la definición completa de la recurrencia — el patrón, el intervalo, el rango. Las instancias son materializaciones individuales de esa serie, una por cada ocurrencia. Exportar ambos sin distinción produciría duplicados y rompería la lógica del calendario en destino. El agente tiene que ser capaz de identificar y procesar solo el padre, descartando las instancias.
El problema no es que Domino no tenga esta información. La tiene. El problema es encontrarla en el lugar correcto y entender cómo mapearla al esquema que espera Graph.
Domino almacena el tipo de recurrencia en el campo RepeatUnit. El mapeo hacia los tipos de Graph es el siguiente:
|
Domino RepeatUnit
|
Graph pattern.type
|
Descripción
|
|
D
|
daily
|
Diaria
|
|
W
|
weekly
|
Semanal
|
|
MD
|
absoluteMonthly
|
Día fijo del mes (ej: día 15)
|
|
MP
|
relativeMonthly
|
Día relativo (ej: 2º martes)
|
|
Y
|
absoluteYearly
|
Fecha fija anual (ej: 15 de marzo)
|
|
YD
|
relativeYearly
|
Relativo anual (ej: 4º viernes de noviembre)
|
El mapeo directo de RepeatUnit a pattern.type es la parte sencilla. La complejidad está en los parámetros adicionales que cada tipo de recurrencia requiere. Para relativeMonthly y relativeYearly, Graph necesita saber qué día de la semana y en qué posición dentro del mes o año. Esa información en Domino vive en el campo RepeatAdjust, codificada como un número decimal donde la parte entera representa la semana y la parte decimal el día. Entender ese encoding y traducirlo correctamente al esquema de Graph es donde está la mayor parte del trabajo real.
Para las recurrencias semanales, RepeatHow almacena los días de la semana como un bitmap: 1 para domingo, 2 para lunes, 4 para martes, y así sucesivamente. Un evento que ocurre lunes y miércoles tiene RepeatHow = 10. El agente descompone ese bitmap para construir el array daysOfWeek que espera Graph.
Además de la lógica de recurrencia, hubo una decisión de diseño relevante en el tratamiento de los asistentes. Graph API no permite crear eventos con asistentes sin que se disparen invitaciones (lo único que puede gestionar es la capacidad de aceptar/declinar pero no elimina las notificaciones). En una migración de eventos históricos, eso es un problema: enviar invitaciones a reuniones de hace tres años generaría ruido innecesario y en algunos casos rebotes de cuentas que ya no existen. La solución fue incluir los asistentes en el cuerpo del evento como texto estructurado, preservando la información sin activar ningún flujo de notificaciones:
Asistentes originales (migrado de Lotus Notes):
Requeridos: María González, Carlos Rodríguez
Opcionales: Pedro Sánchez, Laura Fernández
Al tratarse de una limitación conocida de Graph, este workaround es una decisión de diseño aplicada a este proyecto específico que puede o no encajar con vuestros objetivos, pero que puede revisarse sin afectar el funcionamiento troncal de la solución.
El modelo es extensible
Todo lo descrito para calendarios aplica directamente a contactos y a cualquier otro tipo de objeto que Domino almacene. El patrón es el mismo: agente de descubrimiento, agente de exportación con su mapeo de campos, script de importación vía Graph, y state.csv como mecanismo de control. Los contactos están implementados y validados end-to-end con 40 campos mapeados. Añadir nuevos tipos de objeto es cuestión de añadir el agente correspondiente, sin modificar la infraestructura existente.
Los sistemas legacy tienen salida, si sabes dónde buscarla
Este proyecto no empezó con LotusScript en mente. Empezó con una necesidad concreta, un análisis de las opciones disponibles y la conclusión de que ninguna de ellas se ajustaba al objetivo. A partir de ahí, la pregunta fue: ¿qué tiene el propio entorno que pueda resolver esto?
La respuesta estaba en las capacidades nativas de Domino. No en una herramienta de terceros, no en una integración compleja, sino en el lenguaje de scripting que lleva décadas disponible en la plataforma. El trabajo fue entender qué necesitaba el destino, mapear la estructura del origen, y construir el puente entre ambos.
Ese es el principio que aplica más allá de esta migración concreta: los sistemas legacy rara vez son callejones sin salida. Suelen ser entornos con capacidades que no se han usado porque nadie se ha preguntado si podían resolver el problema nuevo.
Y esto es solo una parte del proceso. El mismo modelo de razonamiento permite ir más lejos: construir un agente de inyección sintética que pueble el laboratorio con los casos edge que necesitas validar, sin depender de que esos escenarios existan en los datos reales. El nivel de rigor que puedes alcanzar con herramientas nativas del propio entorno suele sorprender.
Si tienes un entorno HCL Domino con una migración pendiente y las herramientas estándar no se ajustan a tus objetivos, nuestro equipo puede ayudarte a definir el enfoque adecuado para tu caso concreto.