30 de julio de 2026
Migración de datos de NetSuite: una lista de verificación práctica
La migración de datos es donde la mayoría de los proyectos de NetSuite fallan silenciosamente, no porque los datos sean difíciles de transferir, sino porque nadie comprobó qué significa realmente "terminado" antes de que llegara la fecha límite.
Antes de tocar un solo disco
Empiece con un inventario, no con un plan. Enumere todos los tipos de registros que deben migrarse: clientes, artículos, transacciones, registros personalizados, archivos adjuntos. Para cada uno, anote dónde se encuentra actualmente y quién en la empresa lo utiliza. Omitir este paso es la razón más común por la que las migraciones se prolongan: alguien recuerda un tipo de registro personalizado en la tercera semana que nadie había considerado en la primera.
La lista de verificación que realmente ejecutamos
- Mapeo de campos aprobado por escrito.
No se trata de un simple "sí, parece correcto" verbal, sino de una hoja de cálculo que alguien con conocimientos del dominio ha revisado campo por campo. - Una prueba en seco en un entorno de pruebas, con datos que simulan un entorno de producción.
Los datos de prueba limpios ocultan problemas que solo se hacen evidentes con el caos que realmente tienen las empresas reales: clientes duplicados, direcciones incompletas, monedas que nadie recuerda haber habilitado. - Recuentos de conciliación antes y después.
Recuentos de filas, sumas totales en campos financieros clave y una verificación aleatoria de una muestra de registros con respecto al sistema de origen. - Un plan de reversión que haya sido probado, no solo escrito.
Si la migración falla al 80%, necesitas saber exactamente cómo se ve la opción "deshacer" antes de comenzar, no mientras está sucediendo. - Aprobación de alguien que no forme parte del equipo del proyecto.
Una segunda opinión permite detectar suposiciones que las personas más cercanas al trabajo dejaron de cuestionar.
Aspectos que observamos específicamente en NetSuite
Las búsquedas guardadas y los flujos de trabajo que hacen referencia a identificadores internos antiguos son la causa más común de fallos silenciosos: la migración se realiza correctamente, pero tres semanas después el informe aparece vacío porque sigue apuntando a identificadores de registro que ya no se resuelven. Volvemos a ejecutar todas las búsquedas guardadas y los flujos de trabajo sobre los datos migrados antes de dar por finalizado un proyecto, no solo sobre los registros transaccionales.
Si estás en pleno proceso de migración y falta algo en esta lista, merece la pena hacer una pausa para añadirlo antes de la puesta en marcha, en lugar de descubrirlo por las malas después.