¿Excel y Access son sistemas de producción?

Un libro se convierte en un sistema de producción cuando la empresa espera su resultado. Un archivo de Access se convierte en uno cuando, sin él, nadie puede aceptar un pedido, conciliar el efectivo, programar trabajo o cerrar el mes. La extensión no hace que ninguna de estas herramientas sea insegura. Lo hacen la dependencia, el estado mutable compartido, las reglas ocultas y un modelo operativo improvisado.

He visto a equipos de ingeniería descartar estos sistemas como unas cuantas hojas de cálculo hasta la mañana en que una macro se detuvo a mitad del cierre. El equipo financiero sabía qué pestaña abrir primero, qué advertencia ignorar y por qué había que pegar como valor la cifra de la celda G47 antes de la segunda ejecución. Ingeniería no sabía nada de eso. La empresa tenía software de producción, pero nadie lo había tratado como software.

La respuesta correcta no es prohibir las hojas de cálculo ni sustituir todas las bases de Access. Primero hay que identificar qué mantiene el negocio en marcha. Después hay que capturar sus entradas, comportamiento, salidas, tiempos y excepciones. Solo entonces se puede trasladar sin convertir una limpieza técnica en una interrupción operativa.

La dependencia define un sistema de producción

Excel y Access son sistemas de producción cuando un proceso empresarial depende de que se comporten de forma correcta y puntual, con independencia de quién los creara o dónde estén los archivos. Una hoja usada para análisis privado es un documento. Esa misma hoja se convierte en sistema cuando recibe entradas periódicas, aplica reglas empresariales, guarda estado, produce un resultado autorizado o desencadena trabajo en otro lugar.

La propiedad es una señal más fiable que la complejidad. Pregunte a quién llaman cuando falla el archivo. Si la respuesta es una analista concreta, un exempleado o la única persona que conoce la contraseña, existe una guardia que nadie ha documentado. Pregunte si se puede aplazar la ejecución. Si deben esperar las nóminas, la facturación, los informes regulatorios, la salida del almacén o el cierre mensual, el sistema tiene un plazo de servicio aunque nadie use ese término.

Busque cuatro tipos de dependencia:

• Las personas coordinan ediciones, entregas u orden de ejecución alrededor del archivo.
• Otros archivos, consultas, buzones, exportaciones o tareas programadas lo alimentan o consumen su salida.
• Una fórmula, consulta, macro o corrección manual decide un resultado empresarial.
• El archivo conserva la única copia aceptada de un estado, una correspondencia, una excepción o una aprobación.

No puntúe el riesgo solo por el tamaño del archivo o el número de fórmulas. Un libro de 20 KB que calcula una cláusula financiera puede suponer más riesgo operativo que un modelo de planificación de 200 MB. De igual modo, un pequeño archivo de Access que asigna números de envío puede ser más importante que un gran archivo histórico. El alcance del daño y el tiempo de recuperación importan más que los megabytes.

La prueba incómoda es sencilla: borre mentalmente una copia. Si el equipo puede recrearla desde una fuente gobernada y continuar dentro de su plazo normal, quizá siga siendo un documento. Si las personas buscarían en portátiles, restaurarían la versión de ayer, llamarían a alguien jubilado o aplazarían un evento empresarial, trátela como producción.

El entorno de ejecución supera al archivo

El archivo rara vez es todo el sistema. Su entorno incluye recursos compartidos de red, letras de unidad asignadas, fuentes ODBC, ajustes de escritorio, complementos, adjuntos de correo, tareas programadas y la secuencia exacta que siguen las personas. Inventariar solo fórmulas y tablas omite las dependencias con más probabilidades de romperse durante el traslado.

Empiece con una ejecución real, no con un taller de arquitectura. Siéntese junto a la persona que opera el proceso y registre cada entrada que abre, botón que pulsa, mensaje que responde, archivo que renombra y salida que comprueba. Anote también la hora. Técnicamente, un libro puede ejecutarse en cualquier momento, pero en la práctica depender de que una exportación nocturna llegue antes de las 07:00 o de que un libro mayor anterior quede quieto después del cierre.

Para cada artefacto, capture un registro de ejecución compacto:

• Entrada: ruta, propietario, formato, condición de llegada y muestra
• Acción: macro, consulta, actualización, pegado, edición o aprobación
• Estado: tablas, celdas, archivos e indicadores modificados por la ejecución
• Salida: destino, consumidor, número esperado de filas y plazo
• Excepción: advertencia, reintento, corrección manual y responsable de escalado

Repita la observación con otra persona. Las diferencias son requisitos. Una puede actualizar todas las conexiones antes de ejecutar la macro. Otra puede saber que actualizar una consulta corrompe una tabla temporal. Alguien puede filtrar por costumbre los códigos de cuenta vacíos. Estas acciones no son ruido alrededor del sistema. Son ramas de su comportamiento.

Inspeccione fuera del directorio evidente. Los libros suelen leer archivos a través de una unidad asignada que se resuelve de otra forma en otro equipo. Las interfaces de Access pueden enlazar tablas de un archivo de datos cuya ruta está guardada en la aplicación. VBA puede crear objetos con enlace tardío, invocar programas de línea de comandos o guardar archivos con nombres derivados de fechas. Una tarea programada puede abrir el libro de forma invisible y depender de un perfil de escritorio. Documente el contexto de máquina y usuario junto al código.

Una regla útil para el límite consiste en incluir todo aquello cuya ausencia cambie el resultado o detenga la ejecución. Así el inventario sigue siendo práctico. No necesita un diagrama de todo el entorno financiero, pero sí la exportación CSV, la configuración regional, el libro de referencia y la carpeta compartida que presupone esta ejecución.

Las macros de Excel contienen código operativo

VBA, fórmulas, pasos de Power Query, rangos con nombre y ediciones manuales implementan reglas. Tratar solo las macros como código crea un mapa falso. En libros maduros, la lógica atraviesa estas capas: una consulta carga transacciones, las fórmulas las clasifican, una macro copia filas seleccionadas y una persona sustituye dos excepciones antes de exportar un asiento.

El estado de cálculo de Excel merece atención especial. La documentación de Microsoft sobre el recálculo de Excel describe los modos automático, automático excepto para tablas de datos y manual. Su guía de soporte también explica que todos los libros abiertos comparten el modo de cálculo actual y que el primero que se abre influye en ese estado. Esto significa que un libro correcto puede producir salidas antiguas porque otro libro cambió el modo de toda la aplicación. Al guardar el archivo se puede conservar el modo equivocado para la siguiente persona.

No responda forzando el cálculo automático en todas partes. Los equipos suelen elegir el cálculo manual porque un libro grande queda inutilizable mientras recalcula. La solución popular oculta un requisito de rendimiento y puede alterar el orden de ejecución. Capture qué rangos deben calcularse, cuándo ocurre el cálculo y qué salidas comprueba la persona antes de exportar. Después haga explícita esa secuencia en el sustituto.

Extraiga y clasifique la lógica antes de reescribirla:

1. Identifique puntos de entrada como botones, eventos del libro, aperturas programadas y macros con nombre.
2. Siga lecturas y escrituras por hojas, rangos con nombre, consultas, archivos externos y conexiones de base de datos.
3. Marque entradas variables como la hora, el usuario, la hoja activa, la selección, la configuración regional y la ruta.
4. Separe las reglas deterministas del trabajo de presentación como formato y ancho de columnas.
5. Registre cada modificación manual con su motivo y efecto posterior.

Una pequeña sonda al principio y al final de una macro de cierre puede producir pruebas sin rediseñarla. El siguiente VBA escribe en un registro CSV la marca de tiempo, la etapa, la ruta del libro, el modo de cálculo y la hoja activa. Adapte la ruta y añada contadores empresariales, como filas importadas o total contabilizado.

Sub TraceStage(stage As String)
    Dim f As Integer
    f = FreeFile
    Open Environ$("TEMP") & "\close-trace.csv" For Append As #f
    Print #f, Format$(Now, "yyyy-mm-dd hh:nn:ss") & "," & stage & "," & _
        ThisWorkbook.FullName & "," & Application.Calculation & "," & ActiveSheet.Name
    Close #f
End Sub

La salida tiene una fila por etapa, por ejemplo 2026-03-31 18:42:07,after-import,X:\Close\Close.xlsm,-4135,Journal. El valor -4135 es xlCalculationManual de Excel. Esa única línea no explica el libro, pero puede refutar suposiciones sobre qué copia se ejecutó, qué hoja estaba activa y si el cálculo era manual. Quite secretos y datos personales antes de conservar los rastros.

La concurrencia de Access falla antes que sus límites

Una base compartida de Access puede alcanzar límites operativos mucho antes del máximo publicado por Microsoft de 255 usuarios simultáneos o 2 GB de tamaño. Esas cifras describen máximos admitidos, no un objetivo sensato de capacidad. Los problemas reales llegan por la contención de escritura, el comportamiento de la red, las transacciones largas, la elección de bloqueos y una interfaz que mantiene tablas o consultas abiertas.

Access admite varios comportamientos de bloqueo. La documentación RecordLocks de Microsoft describe el comportamiento optimista de No Locks: dos usuarios pueden editar el mismo registro y el segundo recibe un conflicto al guardar. Edited Record bloquea mientras alguien edita, pero la documentación indica que puede bloquearse una página de registros. All Records puede bloquear el conjunto subyacente mientras un formulario, informe o consulta está activo. Por tanto, un ajuste de formulario que parece local puede afectar a compañeros que trabajan en otro lugar.

La expresión límite de bloqueo de registros suele ocultar dos fallos distintos. Uno es un conflicto real porque dos personas actualizan el mismo registro empresarial. El otro es una contención incidental causada por la forma en que Access agrupa datos, abre un conjunto de registros o ejecuta una consulta de acción. Sustituir el archivo por una base de servidor puede reducir los problemas de archivos compartidos, pero no decide qué actualización debe ganar. Aún hace falta una regla de concurrencia.

Observe los síntomas en lugar de esperar un número de capacidad:

• Los usuarios mantienen copias locales de la interfaz porque la compartida es lenta o frágil.
• Un archivo de bloqueo permanece tras un fallo, o se pide a todos que salgan antes de reparar.
• Las consultas por lotes solo se ejecutan cuando los compañeros cierran los formularios.
• Las personas reciben conflictos de escritura y los resuelven copiando texto aparte o reabriendo registros.
• Compactar y reparar se ha convertido en mantenimiento habitual en vez de una recuperación excepcional.

Una base dividida, con un archivo de interfaz por usuario y tablas de datos compartidas, suele ser más segura que un único archivo compartido que lo contiene todo. Sigue siendo una base basada en archivos a través de una red. No obtiene transacciones del lado del servidor, control central de conexiones ni despliegue independiente de la lógica empresarial. Considere la división una medida de contención si reduce el conflicto inmediato, no la arquitectura final por defecto.

Las copias no demuestran que pueda recuperarse

Copiar el libro o la base es necesario, pero una copia correcta no demuestra que el proceso pueda continuar. La recuperación exige el conjunto correcto de archivos, un punto coherente de la ejecución, conexiones externas y credenciales válidas, dependencias del escritorio y una persona que sepa qué hacer con los datos restaurados.

Una copia de los datos de Access mientras hay escrituras puede no representar un punto empresarial limpio. Un libro restaurado sin sus archivos de referencia puede abrirse con valores en caché que parecen razonables. Un libro con macros puede depender de una ubicación de confianza, un componente firmado o un complemento ausente. Copie el contexto operativo, no solo el archivo visible.

Pruebe la recuperación en un entorno desechable. Restaure los archivos, desconecte los recursos originales y pida a alguien distinto del propietario habitual que ejecute un ciclo representativo. Debe poder indicar qué entradas usó, cómo reconoció que había terminado y adónde fueron las salidas. Compare totales empresariales, no solo si el archivo se abrió.

Defina puntos de recuperación alrededor de transiciones empresariales. En un cierre mensual podrían ser entrada congelada, importación completa, ajustes aprobados, asiento exportado y contabilización confirmada. En cada punto, enumere qué estado puede reconstruirse y cuál debe conservarse. Si una macro falla tras crear medio archivo de salida, la persona debe saber si la repetición duplica filas, las sustituye o continúa. En software, esa propiedad se llama idempotencia, pero la pregunta práctica es más sencilla: ¿qué ocurre si pulsamos dos veces el botón?

El historial de versiones ayuda ante ediciones accidentales, pero no sustituye al historial de transacciones. Un libro restaurado muestra qué contenían las celdas. Puede no mostrar quién aprobó una excepción, qué archivo aportó una cifra o si se contabilizó el asiento exportado. Si el proceso necesita esas pruebas, guárdelas de forma explícita en el nuevo sistema.

El fallo del cierre revela la especificación real

Un cierre fallido suele revelar que el procedimiento escrito describía el camino ideal mientras el sistema de producción vivía en sus excepciones. Recorra una secuencia típica. Finanzas recibe varias exportaciones, les pone nombres fijos, abre un libro con macros, actualiza consultas y pulsa un botón. La macro vacía hojas de preparación, importa filas, calcula correspondencias, crea una pestaña de excepciones y exporta un asiento.

A mitad del proceso, una fuente contiene un centro de coste nuevo. Una búsqueda devuelve #N/A, pero un controlador de errores sigue. El total del asiento es demasiado bajo. La persona lo detecta porque un total de control no coincide, añade la correspondencia a una hoja oculta, recalcula, borra la exportación parcial y vuelve a ejecutar. La segunda ejecución funciona porque sabe qué artefactos dejó la primera.

Una reescritura literal de la macro conservaría la parte peligrosa: continuar después de una correspondencia desconocida. Una entrevista superficial de requisitos podría omitir la tabla oculta y el borrado. La especificación correcta separa las etapas y hace visibles sus contratos. La importación debe conservar la fuente e informar de las filas. La validación debe rechazar centros de coste desconocidos antes de construir el asiento. Los cambios de correspondencias necesitan responsable y fecha de efecto. La exportación debe usar un identificador de ejecución y rechazar duplicados accidentales.

Capture un fallo así como una tabla de observaciones, no como un diagrama pulido. Para cada etapa, registre precondición, huella de entrada, número de filas, total de control, huella de salida y estado. Un hash SHA-256 identifica un archivo exacto sin guardar otra copia suelta en el registro. Conserve el archivo según las normas de retención aplicables a sus datos.

El fallo también revela una distinción importante: reproducir la salida no equivale a reproducir el comportamiento. Dos implementaciones pueden crear el mismo asiento con entradas normales y discrepar ante archivos duplicados, correspondencias ausentes, fechas cerca de medianoche, celdas vacías, redondeo decimal o reintentos tras una interrupción. Las pruebas de migración necesitan estos extremos porque las personas ya dependen de cómo los gestiona el sistema antiguo, aunque ese comportamiento resulte incómodo.

Dibuje el sustituto alrededor de las decisiones

El mejor límite de migración sigue las decisiones empresariales y la propiedad del estado, no las pestañas ni los formularios de Access. Una pestaña es una unidad de presentación. Una consulta es una unidad de implementación. Ninguna tiene por qué corresponder a un servicio, tabla o pantalla. Empiece con decisiones como si una factura es admisible, qué cuenta recibe un importe, si un registro puede avanzar y quién puede modificar una excepción.

Para cada decisión, nombre entradas, regla, salida, propietario y necesidad de historial. Si una regla cambia por fecha de vigencia, guarde versiones en lugar de sustituir una fórmula. Si los usuarios pueden modificarla, capture motivo, actor, fecha, valor anterior y valor nuevo. Si dos personas pueden editar el mismo caso, defina concurrencia optimista con comprobación de versión o serialice la transición. No permita que el comportamiento predeterminado de la base tome una decisión empresarial por accidente.

Mantenga Excel donde sea realmente útil. Los analistas quizá sigan necesitando una exportación para una revisión puntual, modelar escenarios o usar una hoja conocida de aprobación. El límite de producción cambia cuando el estado autorizado y las reglas pasan a una aplicación y una base controladas. Un libro exportado puede seguir siendo una vista sin seguir siendo la única copia de trabajo.

Tampoco reconstruya cada formulario de Access píxel a píxel. Pregunte qué tarea completa, qué validación aplica, qué registros relacionados muestra y qué flujo de teclado necesitan los usuarios expertos. Conserve el trabajo eficiente, no una geometría arbitraria. Un cliente web puede ser peor que Access si convierte una captura rápida en constantes viajes del ratón y cuadros modales.

Un destino práctico para esta clase de sistema es una aplicación de servidor propietaria de reglas y transacciones, una base relacional propietaria del estado, un cliente diseñado para las tareas y trabajos explícitos de importación y exportación. Go o TypeScript pueden llevar los servicios, TypeScript el cliente y Postgres las restricciones y la concurrencia. Los lenguajes importan menos que hacer visibles la propiedad y el comportamiento ante fallos.

Migre las responsabilidades arriesgadas por separado

Una migración controlada elimina una responsabilidad cada vez mientras el sistema antiguo sigue disponible para comparar. Una reescritura con cambio total obliga a concentrar descubrimiento, implementación, conversión de datos, formación y corte en un solo evento. Así se acumula la incertidumbre cuando más difícil resulta volver atrás.

Empiece por la responsabilidad que genera pruebas o reduce un riesgo irreversible. Puede poner un servicio de entrada inmutable delante de las importaciones, mover tablas de Access a Postgres conservando temporalmente la interfaz o sustituir una macro de exportación mientras deja el cálculo. La elección depende de dónde duelen los fallos y dónde puede comparar resultados.

No confunda mover los datos de Access con completar la migración. Enlazar formularios de Access con tablas de servidor puede estabilizar el almacenamiento y exponer problemas de concurrencia, un estado intermedio que quizá sea útil. Las reglas empresariales aún pueden quedar en eventos de formularios, módulos VBA, consultas guardadas y hábitos. Siga cada responsabilidad de forma consciente para que el puente temporal no se convierta en el sistema final sin documentar.

La migración de datos necesita reglas de conciliación antes de la primera carga. Decida cómo tratar identificadores duplicados, vacío frente a null, fechas sin zona horaria, valores de coma flotante, adjuntos, campos de búsqueda, registros borrados y filas que incumplen nuevas restricciones. Ponga las excepciones en cuarentena con un motivo. Limpiarlas en silencio hace que la base nueva parezca ordenada mientras rompe su relación con el registro empresarial.

Ejecute las rutas antigua y nueva contra entradas congeladas siempre que sea posible. No pida que se capture dos veces la misma transacción real, porque eso crea dos fuentes de verdad rivales. Duplique entradas, reproduzca acciones registradas o compare salidas generadas en una ventana controlada. Concrete la vuelta atrás: nombre la autoridad del cambio, el último punto reversible, los datos que habría que reproducir y las condiciones que activan el retorno.

CodeHero acepta fuentes de Excel y Access y las reescribe en Go, Rust, TypeScript y Postgres, con entrega en menos de 30 días. Esa promesa solo sirve si el trabajo incluye archivos cercanos, reglas ocultas y secuencia de operación. Convertir únicamente el VBA visible dejaría atrás el sistema de producción.

La paridad debe probar significado, no capturas

Un banco de paridad debe alimentar ambos sistemas con las mismas entradas registradas y comparar resultados empresariales normalizados. Comparar capturas demuestra poco cuando cambian el ancho de columnas, el orden o el formato. Contar filas también omite cuentas intercambiadas, redondeos distintos y excepciones ausentes.

Construya un corpus con formas reales de producción después de eliminar o proteger datos sensibles. Incluya ejecuciones normales, fechas límite, entradas vacías, archivos duplicados, correspondencias ausentes, ediciones en conflicto, repeticiones y ejecuciones interrumpidas. Para cada caso, defina qué diferencias importan. Un informe sin orden puede permitir filas reordenadas. Un asiento no puede permitir una cuenta o importe diferente. Una marca de tiempo puede aceptar tolerancia, mientras que la identidad de aprobación debe coincidir exactamente.

Una consulta útil agrupa los resultados al nivel que aprueba Finanzas. Las columnas concretas variarán, pero la forma debe resultar familiar:

select account_code, currency,
       count(*) as line_count,
       round(sum(amount), 2) as total_amount
from journal_lines
where run_id = :run_id
group by account_code, currency
order by account_code, currency;

Ejecute la extracción equivalente sobre la salida antigua y compare valores tipados. Conserve los ceros iniciales de los códigos, distinga vacío de cero, normalice las fechas de forma deliberada e indique la regla de redondeo. Cuando haya diferencias, clasifique la causa como defecto de extracción, peculiaridad heredada entendida, defecto de la nueva implementación o cambio aprobado. No cambie en silencio los resultados esperados para que pase la prueba.

El tráfico de producción registrado aporta pruebas mejores que los ejemplos elegidos a mano porque contiene combinaciones que nadie recordó especificar. Aun así necesita revisión. El tráfico histórico puede omitir eventos anuales raros, ejecuciones fallidas o acciones que los usuarios evitaban por las limitaciones antiguas. Añada casos de notas de incidencias, entrevistas con operadores y procesos de calendario.

La paridad no obliga a conservar todos los defectos. Crea una elección controlada. Si el libro antiguo redondea cada línea y el servicio nuevo solo el total, muestre la diferencia, cuantifique los registros afectados en el corpus y deje decidir al propietario empresarial. Una diferencia sin explicar bloquea el corte. Un cambio aprobado se convierte en requisito versionado.

El corte funciona si los usuarios pueden impugnarlo

Las personas que ejecutan el archivo deben poder demostrar que el sustituto se equivoca antes de que sea autorizado. Ofrézcales salidas que puedan conciliar, excepciones que puedan inspeccionar y una vía para detener el cambio. La formación que solo enseña el camino ideal convierte a usuarios expertos en receptores pasivos y desperdicia el conocimiento que mantenía vivo el sistema antiguo.

Use criterios de aceptación operativos. El sistema nuevo está listo cuando una persona designada puede completar el proceso desde la llegada de la fuente hasta la salida aceptada, recuperarse de una etapa fallida, explicar cada rechazo y conciliar totales sin consultar la memoria del autor anterior. Soporte necesita identificadores de ejecución, estado de etapas, huellas de entrada, detalles del error y una acción segura de reintento. La dirección necesita un propietario claro para los cambios de reglas y accesos.

Planifique el cambio final según el reloj empresarial. Congele modificaciones de macros, consultas, formularios y correspondencias antes de la ventana de comparación. Registre las versiones antiguas exactas. Decida qué ocurre con las transacciones que lleguen durante el corte y cómo se reproducirán. Conserve el entorno antiguo en modo de solo lectura durante el periodo de evidencia acordado, pero quite su capacidad de crear nuevas salidas autorizadas. Dos sistemas con escritura producen disputas, no redundancia.

No juzgue la adopción por la ausencia de quejas. Observe si los usuarios crean libros paralelos para recuperar filtros, exportaciones o vistas de excepciones que faltan. Una hoja nueva en el borde puede ser una herramienta de análisis razonable o la primera señal de que vuelve a escaparse lógica autorizada. Revise por qué existe antes de prohibirla.

Excel y Access pueden ejecutar trabajo de producción durante años porque personas capaces aportan los controles que faltan a las herramientas. Una migración segura convierte esos controles en algo ejecutable, revisable y recuperable. El artefacto decisivo no es un código más limpio. Es un cierre, contabilización, envío o aprobación que termina a tiempo mientras sus responsables ven exactamente qué ocurrió y pueden detenerlo cuando algo está mal.