Quien paga las migraciones?

Un colega me pregutó como manejábamos los procesos de migración y fundamentalmente si le cobrábamos algo adicional a los clientes en los procesos de migraciones.

Cuando hablo de migración, me refiero cuando quiero cambiar la version de mi herramienta de desarrollo (en mi caso GeneXus), para una mas nueva y con mejores prestaciones, pero sin agregar funcionalidad ninguna.

Es muy dificil vender estos proyectos a los clientes, pues el valor de los mismos pasan bastante desapercibidos. Funcionalmente la aplicación luego de terminar el proyecto tiene que hacer exactamente los mismo que antes, pero al regenerar toda la aplicación se agrega el riesgo de que algo funcione diferente y peor que antes.

Si bien no hay una receta única para esto, en general es bueno tratar de absorber el costo de los proyectos de migración. En el futuro, se le puede cobrar a los clientes, por las nuevas funcionalidades que se van a desarrollar con las nuevas tecnologías o mejoras al sistema.
Por ejemplo al migrar a Evolution 3, puede cobrarse por hacer una aplicación responsive que se adapte a todos los dispositivos, o con navegación smooth, o que soporte HTML5 y los ultimas versiones de los navegadores.

Dentro de las diferencias de funcionamiento podemos tener :

• Cambios en la performance (cambios en sentencias, optimizaciones, etc)
• Cambios en la seguridad (aplicaciones mas seguras)
• Cambios tecnológicos (soporte de nuevas tecnológicas, html, responsive, etc)

En los proyectos de migración, lo que hay que hacer es mitigar los riesgos que cosas que funcionaban bien, empiecen a funcionar mal. Para esto lo mejor es detectar las diferencias y analizarlas para ver si hay algun problema. Según mi experiencia, el porcentaje de objetos que funcionan diferente es bastante bajo de una versión a la siguiente, por lo que si hacemos el ejercicio de migrar cada 2 años, es un trabajo mas que razonable.

Bueno, resumiendo y para no hacer un post muy largo

Migrar es indispensable, por lo tanto hacelo rápido

Si queremos mantenernos en el mercado, es indispensable migrar, por lo que conviene hacerlo lo mas a menudo que se pueda. Por supuesto que hay que equilibrar las horas que dedicamos a las migraciones, con las horas de desarrollo de nuevas funcionalidades, que siempre deberian ser la prioridad numero uno.
El proceso de migracion es muy automatizable, por lo que una vez que nos convencemos que es una tarea que hay que voy a tener que realizar varias veces, conviene invertir en automatizar la mayoria de los procesos que involucran.

Hacer migraciones desechables. 

Una vez que se tiene automatizado o al menos estandarizado el proceso de migracion, se hace mucho mas fácil hacer migraciones de prueba a nuevas versiones. Por ejemplo, es muy bueno hacer una copia de mi KB y convertirla a la ultima versión de GeneXus y  ver si aparecen errores o warnings nuevos. También hacer pruebas para ver si todo se genera sin problemas. 

Migrar permite detectar errores

En las migraciones, es un buen momento de detección de errores. 

Durante el proceso de desarrollo muchas veces se realizan determinadas "pisadas" para que las cosas funcionen o se hacen pasos de forma no demasiado ortodoxa. Las migraciones son el momento donde quedan a la vista todas estas "no conformidades" del proceso de desarrollo. 

Esto es un valor agregado importante de las migraciones, aunque algunos la vean como algo malo, para mi es algo muy bueno, pues ayuda a mejorar el proceso de desarrollo. 

Algunos ejemplos :

• Se borro un objeto en la KB, pero se dejo en producción. 
• Se renombró un objeto, pero sigue estando el viejo y el nuevo. 
• Se copio un programa externo y el mismo no esta en la KB. 
• Se modifico un CSS, javascript en producción y no se documentó correctamente
• Se uso un font no standard y no se documento correctamente
• Se instaló en producción una versión mas nueva del  User Control y no se documento

Migrar trae riesgos y hay que minimizarlos 

Conviene detectar diferencias en :

• Navegaciones / Performance
• WSDL/REST
• Lista de programas generados
• Interfaz de la aplicación con el exterior (Planillas, file system, mail, etc)
• Revisar logs de ejecución en busca de errores o lentitudes
• Pruebas funcionales

Una vez detectadas las diferencias, hay que estudiarlas y ver cuanto nos pueden afectar. 

Si el salto de versión no es muy grande, son tareas muy manejables. 

Desarrollar y cobrar por nuevas funcionalidades.

Esta es la parte mas fácil si estamos capacitados en las nuevas funcionalidades que nos brindan la versión.

El resumen es:

• Migrar rapido y a menudo (este paso debería ser casi automático)
• Encontrar diferencias rapido  (este paso debería ser casi automático)
• Iterar hasta estar convencido que todo funciona bien

Si se puede hacer esto, el costo de la migración es fácil de compensar con las nuevas funcionalidades y las mejoras en productividad.