Cambiar de software inmobiliario: plan de migración paso a paso

El proveedor del sistema actual anuncia que la versión que usa su cartera dejará de tener soporte dentro de nueve meses. El director financiero pregunta cuánto cuesta renovar, el responsable de leasing responde que lleva dos años exportando a Excel porque el módulo de renovaciones nunca funcionó bien, y el controller admite que las conciliaciones de gastos comunes se hacen fuera del sistema desde que cambió el plan contable. Ese es el momento en que la decisión de cambiar de software inmobiliario deja de ser teórica. Y el problema real no es elegir la herramienta nueva: es sacar quince años de contratos, adendas e históricos de un sistema que nadie documentó y meterlos en otro sin perder una fecha de indexación por el camino.

Cambiar de software inmobiliario no es una implantación desde cero

Quien parte de hojas de cálculo tiene un problema de orden; quien parte de otro sistema tiene un problema de herencia. El sistema saliente lleva años aplicando reglas de cálculo que el equipo actual probablemente no conoce al detalle, codificando superficies con una convención que nadie recuerda haber decidido y guardando campos personalizados que alguien creó para un informe puntual en 2017. Una migración bien planteada trata ese sistema como una fuente de datos que hay que auditar, no como una verdad que hay que copiar. Si lo que necesita es una visión general de funciones y criterios de selección, la guía completa de software de gestión inmobiliaria cubre ese terreno; aquí nos centramos exclusivamente en el traspaso.

Paso 1: auditoría del sistema saliente y mapa de dependencias

Antes de extraer un solo registro, documente qué entra y qué sale del sistema antiguo. Lo habitual es encontrar más dependencias de las que figuran en cualquier esquema: la contabilidad recibe asientos de renta, el banco recibe ficheros de domiciliación, un informe mensual al propietario se alimenta de una consulta directa a la base de datos y el equipo de marketing del centro comercial descarga listados de inquilinos para las campañas. Cada una de esas conexiones tiene que seguir funcionando el día después del corte o tener un sustituto probado.

Haga también una auditoría de confianza por tabla. Pregunte a quien usa cada dato a diario si se fía de él. Es frecuente que las fechas de vencimiento sean fiables porque generan alertas que alguien revisa, mientras que las superficies o las garantías bancarias llevan años sin actualizarse. Esa clasificación en datos fiables, dudosos y abandonados decide qué se migra tal cual, qué se revisa contra el contrato original y qué se vuelve a capturar desde cero.

Paso 2: extracción, diccionario de datos y reglas de transformación

Solicite al proveedor saliente una exportación completa y legible, no un backup propietario. Si el contrato de servicio no garantiza ese derecho, negócielo antes de comunicar la baja. Con la exportación en la mano, construya el diccionario de datos: para cada campo del sistema viejo, el campo equivalente en el nuevo, la regla de transformación y el responsable de validarla. Es aquí donde salen a la luz las diferencias de convención: una fecha de inicio que en el sistema antiguo era la fecha de firma y en el nuevo será la de inicio de renta, una superficie bruta que ahora debe ser ponderada, o códigos de uso que no tienen correspondencia directa.

Decida el alcance temporal con criterio y no por inercia. Migrar contratos vigentes y los vencidos en los últimos 24 meses cubre casi todas las necesidades operativas y de informe; el histórico anterior puede conservarse como archivo documental sin abstraer. Y acepte una realidad que cualquier implementador confirmará: la revisión de contratos complejos contra el documento original consume entre dos y tres veces más horas que la configuración técnica. Dimensionar una persona con criterio jurídico-comercial por cada 150 a 200 contratos comerciales complejos es un punto de partida razonable.

Paso 3: cargas de prueba y validación por muestreo

Ninguna carga debería ir directa a producción. Ejecute al menos dos cargas completas en un entorno de pruebas y, tras cada una, valide por tres vías. Primero, totales de control: número de contratos, suma de renta anual contratada y superficie total por activo deben coincidir con el sistema saliente, y cada diferencia debe explicarse. Segundo, muestreo dirigido: seleccione los contratos que más miedo dan, los que combinan renta mínima garantizada con porcentaje sobre ventas, los que tienen indexación con tope y los que prorratean gastos comunes por coeficientes distintos a la superficie, y compruébelos campo a campo. Tercero, muestreo aleatorio de otros diez o veinte contratos para detectar errores sistemáticos que el muestreo dirigido no vería.

En una implantación de software inmobiliario por capas, como la secuencia VemLease para el ciclo contractual, VemTenant para las ventas declaradas por inquilinos y VemCount para la afluencia, este paso tiene una consecuencia práctica: los identificadores de unidad y de inquilino que salgan de la carga de VemLease serán la clave para cruzar ventas y tráfico después. Un identificador duplicado o mal mapeado aquí reaparece meses más tarde como una tasa de esfuerzo imposible o una conversión por zona que nadie puede explicar.

Paso 4: el ciclo en paralelo

Ejecute al menos un ciclo de facturación completo en ambos sistemas y compare el resultado línea por línea. Es la única prueba que detecta errores de regla de cálculo, no solo de dato. Cuando una línea difiere, hay tres explicaciones posibles y las tres hay que documentarlas: el dato migrado estaba mal, la regla se configuró mal en el sistema nuevo, o el sistema antiguo llevaba años calculando incorrectamente. La tercera aparece con más frecuencia de la que resulta cómodo admitir, y conviene decidir de antemano quién comunica al inquilino una corrección de renta si se confirma.

• Fije un umbral de tolerancia, por ejemplo diferencias inferiores a un euro por línea, y exija explicación escrita para todo lo que lo supere.
• Congele altas y modificaciones de contratos durante la ventana del paralelo o registre cada cambio en los dos sistemas con doble firma.
• Guarde la conciliación firmada por finanzas y por leasing como parte del acta de aceptación: es su defensa si un propietario cuestiona una cifra meses después.
• Si el ciclo coincide con una indexación anual masiva, amplíe el paralelo a dos ciclos; un mes normal no prueba las reglas de actualización.

Paso 5: go-live, corte y apagado controlado

El go-live no es el día en que el sistema nuevo se enciende, sino el día en que el informe mensual al propietario sale de él y nadie lo reconstruye a mano. Planifique el corte justo después de un cierre contable, con las alertas de renovación ya configuradas, doce meses de antelación para locales ancla y oficinas grandes, seis para el resto, y verificadas con un contrato real que venza pronto. Mantenga el sistema antiguo en modo solo lectura durante un periodo acordado, con acceso restringido, para resolver consultas sobre el histórico sin tentar a nadie a seguir trabajando en él. Cuando se incorporen las capas de ventas y afluencia, sea realista con el conteo: el mínimo contractual habitual es del 96 % y en la práctica se alcanza entre el 98 y el 99 % cuando la iluminación y la disposición de accesos lo permiten, nunca una cifra garantizada al 100 %.

Preguntas frecuentes

¿Cuánto tiempo hay que mantener el sistema antiguo tras el corte? Lo prudente es conservarlo en modo solo lectura hasta cerrar al menos un ejercicio contable completo con el sistema nuevo. Así se resuelven consultas de auditoría o reclamaciones de inquilinos sobre periodos anteriores sin depender de exportaciones parciales. Acuerde con el proveedor saliente el coste de ese periodo antes de notificar la baja.

¿Se puede migrar por activos en lugar de toda la cartera a la vez? Sí, y suele ser la opción más segura en carteras grandes o con propietarios distintos. El coste es gestionar dos sistemas en producción durante más tiempo y consolidar informes de forma manual en el intervalo. Empiece por un activo con contratos variados pero manejable, y use lo aprendido para ajustar el diccionario de datos antes de la siguiente ola.

¿Qué pasa si el paralelo revela que el sistema antiguo facturaba mal? Primero documente el hallazgo con el cálculo correcto y el contrato que lo sustenta. Después decida con el propietario y asesoría legal si procede regularizar hacia atrás o solo corregir hacia delante, porque la respuesta depende del contrato y de la jurisdicción. Lo que no debe hacer es configurar el sistema nuevo para reproducir el error y evitar la conversación.

Si está preparando el cambio de sistema y quiere revisar el mapa de dependencias, dimensionar la revisión de contratos o definir los criterios de aceptación del ciclo en paralelo, hable con el equipo de Vemco Group. Podemos ayudarle a planificar la migración por capas y fijar un go-live con criterios verificables antes de firmar nada.