Una API suele reducir dependencia de pantallas, selectores y sesiones, pero cambiar el canal no demuestra que el resultado de negocio sea equivalente. El robot puede contener reglas implícitas, tolerancias y pasos manuales que no aparecen en el diagrama.
Inventaría el comportamiento real
Registra durante varias ejecuciones:
- entradas, filtros y calendario;
- decisiones y excepciones;
- efectos creados en el sistema destino;
- reintentos y tratamiento de duplicados;
- evidencias y notificaciones;
- intervención humana;
- tiempos y límites de volumen.
Microsoft recomienda analizar el proceso antes de automatizarlo: objetivo, entradas, salidas, variaciones y excepciones. Usa ese inventario como contrato de migración, no como justificación para copiar cada defecto del robot.
Diseña equivalencia observable
Asigna una clave de negocio compartida, por ejemplo pedido:empresa:numero. Tanto robot como API deben producir un resultado comparable y registrar correlación. Define qué significa igualdad: mismo registro final, impuestos, adjuntos, estado y evento posterior.
| Dimensión | Robot | API | Control |
|---|---|---|---|
| alta | formulario | POST /orders |
clave idempotente |
| consulta | pantalla | GET /orders/{id} |
comparación de campos |
| error | mensaje UI | problema estructurado | catálogo de equivalencias |
| evidencia | captura | respuesta y auditoría | correlación común |
La API necesita autorización por recurso y un contrato de errores; no traslades credenciales personales del robot a una integración de servicio.
Ejecuta en sombra
Cuando sea seguro, deja al robot como escritor y ejecuta la ruta API en modo lectura o simulación. Compara decisiones sin duplicar efectos. Si la API no ofrece dry-run, replica entradas en un entorno representativo.
Después prueba un subconjunto controlado como escritor único de API: una sociedad, tipo de operación o porcentaje determinista. No hagas escribir a ambos sobre el mismo caso salvo que el destino garantice idempotencia.
Mide éxito técnico y equivalencia de negocio:
- casos intentados y completados;
- divergencias por campo;
- duplicados;
- latencia y capacidad;
- excepciones enviadas a revisión;
- efectos posteriores confirmados.
Corte y reversión
Fija umbrales, responsables y ventana. Antes del corte, congela cambios no esenciales, confirma límites de API y conserva el robot desplegable. Cambia el enrutamiento, observa una cohorte y amplía.
El rollback debe evitar reprocesar casos ya aceptados por la API. Conserva el ledger de claves y estados; al volver al robot, este empieza en el primer caso pendiente, no en el inicio del lote.
Retirada controlada
Mantén el robot durante una ventana acordada, sin uso ordinario, y elimina credenciales, máquinas, licencias y programación al cerrar. Actualiza runbooks y ownership. La migración termina cuando el proceso opera por API, las excepciones tienen destino y la antigua ruta ya no puede activarse accidentalmente.
Cambiar interfaz por integración mejora estabilidad si conserva controles. La ejecución comparada y el ledger de efectos permiten demostrar continuidad en lugar de confiar en que dos implementaciones “hacen lo mismo”.