La mayoría de los problemas que una empresa achaca a NetSuite durante sus primeras semanas en producción no son problemas de NetSuite: son errores de migración de datos en NetSuite que nadie detectó a tiempo. Cuando los saldos no cuadran, hay clientes duplicados o faltan facturas históricas, el origen casi siempre está en cómo se cargaron los datos, no en el software. En este artículo recogemos los siete errores que más veces hemos visto reventar un go-live, y cómo evitarlos antes de que lleguen a producción.
En un proyecto de implantación, la parametrización funcional concentra casi toda la atención: procesos, roles, formularios, automatizaciones. La migración de datos se trata como una tarea técnica de última hora, casi de «copiar y pegar». Y es justo al revés. Un sistema bien configurado con datos sucios da resultados sucios desde el primer día, y la confianza del equipo financiero en el ERP se pierde en la primera conciliación que no cuadra.
Quienes hemos sido usuarios internos de NetSuite antes que consultores lo hemos vivido desde el otro lado: el director financiero no recuerda qué workflow se configuró bien, recuerda que el balance de apertura no coincidía con el cierre del ERP anterior. Por eso tratamos la migración como un entregable con su propio plan de validación, no como un volcado. Si estás evaluando el proyecto desde antes, conviene leer también nuestro artículo sobre los errores de implantación de NetSuite que rodean a esta fase.
El error más caro empieza con la frase «mejor lo subimos todo». Migrar diez años de transacciones a NetSuite multiplica el coste, el tiempo de validación y el riesgo de arrastrar basura. La buena práctica es definir un corte: saldos de apertura y maestros activos en NetSuite, y el histórico detallado en un repositorio de consulta de bajo coste para auditoría. No todo lo que existe en el ERP de origen tiene que vivir dentro de NetSuite.
NetSuite asigna un Internal ID propio a cada registro, pero el campo External ID permite conservar el identificador único del sistema de origen. Si no se rellena, enlazar registros relacionados (un pedido con su cliente, una factura con su pedido) se vuelve un infierno y se cargan relaciones cruzadas. Renombrar el identificador del ERP antiguo como External ID y usarlo como clave de cruce es la diferencia entre una migración trazable y un puzzle imposible de reconciliar.
NetSuite tiene una función de Duplicate Detection & Merge que no viene activa por defecto. Hay que habilitarla en Setup > Company > Enable Features y configurar los criterios en Setup > Company > Duplicate Detection para clientes, proveedores y contactos. Si se importa sin esto, NetSuite crea felizmente tres veces el mismo cliente. Limpiar duplicados después, con transacciones ya colgando de cada uno, es mucho más caro que prevenirlos.
Los saldos de apertura no se «importan»: se cargan como asientos contables (journal entries) a la fecha de go-live, y deben aprobarse contra un balance de comprobación firmado. Clientes (AR), proveedores (AP), tesorería, inventario y patrimonio se reconcilian uno a uno antes de abrir el sistema. Saltarse este paso es la causa número uno de que «los números de NetSuite no cuadran» en la primera semana.
Los campos de lista son traicioneros porque el import no siempre falla: a veces asigna el valor por defecto y sigue. Un tax code mal mapeado en la migración contamina después el modelo 303; una subsidiaria incorrecta rompe la consolidación; una moneda mal asignada distorsiona los importes. Hay que mapear estos campos explícitamente y revisar el CSV Response file que NetSuite genera tras cada carga, donde figuran los errores y los registros omitidos.
Probar la carga directamente en la cuenta de producción es jugar a la ruleta rusa con los datos reales. Toda migración debería ensayarse al menos una vez completa en un entorno de Sandbox, midiendo tiempos, volúmenes y errores por lote. NetSuite procesa la importación en bloques de unos pocos miles de registros, así que cargar en tandas y revisar los errores tras cada una evita descubrir un fallo de mapeo cuando ya van 80.000 líneas dentro.
«El import dice 0 errores» no significa que los datos sean correctos. Un import puede completarse sin errores técnicos y aun así haber dejado fuera registros por filtros mal puestos, o haber cargado importes con decimales mal interpretados. La validación real es contable: número de clientes, suma de saldos AR/AP, total de stock y balance de apertura, contrastados contra el sistema de origen. Sin esa reconciliación, no hay migración terminada.
En una migración de cartera de clientes habitual nos encontramos con que el equipo había cargado el maestro de clientes con el Import Assistant sin activar antes la detección de duplicados. El asistente terminó sin errores y todos dieron la carga por buena. Dos semanas después, comercial reportaba que el mismo cliente aparecía tres veces, cada uno con facturas distintas colgando.
La forma de detectarlo en frío es una saved search de tipo Customer agrupada por nombre o NIF con un filtro de count > 1, que saca al momento la lista de duplicados reales. La forma de no llegar ahí es activar Duplicate Detection & Merge, marcar las «Advanced Options» en el segundo paso del Import Assistant y revisar el CSV Response file que devuelve NetSuite. La documentación oficial detalla este flujo en el CSV Import FAQ de Oracle NetSuite. Limpiar después implicó fusionar registros y reasignar transacciones a mano: días de trabajo que la configuración previa habría ahorrado.
El patrón que aplicamos en nuestro equipo es sencillo de enunciar y disciplinado de ejecutar:
Este enfoque es el mismo que seguimos cuando una empresa llega desde otro sistema; lo detallamos para un caso concreto en nuestra guía de migración de SAP Business One a NetSuite. La diferencia entre un go-live tranquilo y tres semanas apagando fuegos casi nunca está en el software: está en el cuidado con el que se trataron los datos.
¿Se puede importar todo el histórico a NetSuite o solo los saldos?
Se puede, pero rara vez conviene. La práctica recomendada es cargar saldos de apertura y maestros activos en NetSuite, y conservar el histórico detallado en un repositorio de consulta para auditoría. Migrar años de transacciones encarece el proyecto y multiplica el riesgo de datos sucios.
¿Cómo se evitan los duplicados al importar datos a NetSuite?
Activando la función Duplicate Detection & Merge en Enable Features, configurando los criterios de detección por tipo de registro y marcando la detección de duplicados en las Advanced Options del Import Assistant. Conviene además usar el External ID como identificador único y revisar el CSV Response file tras cada carga.
¿Qué es el External ID y por qué es clave en una migración?
Es un campo de NetSuite donde se guarda el identificador único del registro en el sistema de origen. Permite enlazar registros relacionados durante la carga y sirve de clave de cruce para reconciliar después. Sin él, relacionar transacciones con sus maestros se vuelve muy difícil.
¿Cómo se cargan los saldos de apertura en NetSuite?
Como asientos contables (journal entries) a la fecha de go-live, no como una importación de transacciones. Deben aprobarse contra un balance de comprobación firmado y reconciliarse junto con clientes, proveedores, tesorería, inventario y patrimonio antes de abrir el sistema.
¿Qué datos hay que reconciliar antes del go-live?
Como mínimo: número y saldo de clientes (AR) y proveedores (AP), saldos de tesorería, valoración de inventario y el balance de apertura completo, contrastados contra el ERP de origen. La validación de una migración es contable, no solo técnica.
¿Estáis planificando una migración a NetSuite o veis que los números no cuadran tras un go-live reciente? En Flying Lemons tratamos la migración de datos como un entregable con su propio plan de validación. Conoce nuestro servicio de implantación y migración a NetSuite.
Gratuito
