1.686 registros y 12 errores intencionales: descubre cómo migrar un libro de cálculo a una base de datos relacional de forma segura.

Un minorista ficticio de cafés especiales: “Roast & Ritual Coffee Co.” - ejecuta todo su operación en un libro de Google Sheets de 10 pestañas: catálogo, variantes, inventario, pedidos, artículos de pedido, clientes, proveedores, órdenes de compra, recuentos de existencias, registro de actividades. el migración completa de ese libro de trabajo a una base de datos SQL normalizada, defectos incluidos, es público y explorable en demo.kamensky.dev.

TL;DR

El problema	Las operaciones minoristas en Google Sheets se pudren de manera predecible: clientes duplicados, recuentos de existencias variables, precios históricos sobrescritos, sin seguimiento de auditoría.
Qué es la demostración	Una migración determinista y 100 % reproducible: 10 pestañas de hoja de cálculo → 12 tablas limpias y vinculadas, con un informe que explica cada decisión de limpieza.
Los números clave	1.686 registros de origen → 1.634 importados · 16 duplicados resueltos · 18 valores normalizados · 3 filas en cuarentena · 8 correcciones de stock · 435 eventos de auditoría.
Las partes difíciles	La fusión del mismo cliente se realizó de dos maneras (se reunió el historial de 12 pedidos); manteniendo un precio promocional de $54 mientras el catálogo dice $59; recalcular el stock a partir de los movimientos cuando la hoja dice 45 pero las matemáticas dicen 35.
El patrón	Analizar → Mapa → Limpiar → Validar → Importar, ejecutado como una importación de todo o nada: se realiza correctamente o se revierte por completo.
Conclusión clave	Una migración de hoja de cálculo no es un trabajo de copiar y pegar; es una auditoría. Si su informe de migración no puede representar cada fila, usted no migró, sino que movió el desorden.

Verás qué es lo que realmente se rompe cuando a una empresa se le quedan pequeñas las Hojas, cómo cada clase de defecto se detecta y resuelve con recuentos exactos, y cuál es la aplicación de operaciones resultante parece. Si estás en una etapa más temprana del viaje, comienza con Cuando Google Sheets deja de escalar; si eres planeando una migración de base de datos de producción, empareje esto con el estudio de caso: AppSheet to SQL.

El problema

El libro de demostración es deliberadamente realista, porque todas las empresas que utilizan hojas de cálculo converge en los mismos cuatro modos de falla:

1. Fragmentación de clientes. El mismo cliente se ingresa en diferentes ortografía en todos los pedidos: Marcus Vance en una pestaña, Marcus V. en otra. El valor de por vida y el historial de pedidos se dividen en dos identidades, y ninguna de las dos es correcta.
2. Desviación del recuento de inventario. Una pestaña estática de “Inventario” es una fotografía, no una libro mayor. Las ventas y los reabastecimientos llegan a pestañas desconectadas; alguien se olvida de actualizar el conteo; la hoja se aleja de la realidad una edición perdida a la vez.
3. Los hechos históricos se sobrescriben. Cuando cambia el precio de un catálogo, un ingenuo sync “arregla” líneas de pedidos antiguas para que coincidan, reescribiendo silenciosamente su contabilidad.
4. Visibilidad de auditoría cero. Sheets no puede responder quién cambió este precio, cuándo ¿Ocurrió el último recuento y por qué?

La Migración, etapa a etapa

El proceso se ejecuta en cinco etapas y, esto es importante, la importación se ejecuta como una paso de todo o nada. No hay ningún estado en el que se migre la mitad del libro:

Etapa	Qué hace
1. Analizar	Inspecciona las formas de las hojas, la capacidad de anulación y detecta anomalías sucias antes de tocar nada.
2. Mapa	Aplica asignaciones explícitas de columna a entidad: las vibraciones no infieren nada.
3. Limpio	Ejecuta las reglas de limpieza con seguimiento de conteo exacto: se cuenta cada duplicado, normalización y cuarentena.
4. Validar	Afirma contratos con recuento récord, integridad de enlaces y seis “hechos destacados” que deben sobrevivir a la migración palabra por palabra.
5. Importar	Carga de transacción única; construye el libro mayor de movimientos de inventario y el registro de actividades.

Métrica	Contar
Registros fuente	1.686
Importado correctamente	1.634
Duplicados resueltos	16 (14 clientes, 1 proveedor, 1 artículo de pedido)
Valores normalizados	18 (7 SKU, 6 variantes, 5 correos electrónicos)
En cuarentena para revisión	3 (órdenes ambiguas, nunca eliminadas silenciosamente)
Correcciones de acciones	8 (hoja manual ≠ libro de movimientos)
Precios históricos preservados	1
Eventos de actividad importados	435

Los 12 defectos que toda migración afecta

El libro de trabajo se entrega con doce defectos plantados (E1–E12), cada uno extraído de un modelo real. migración. Una muestra de lo que tiene que coger el oleoducto:

identificación	Estado heredado	Regla aplicada	Resultado
E1	Marcus Vance (C-023) y Marcus V. (C-071), mismo correo electrónico	Fusionar por correo electrónico normalizado; conservar el nombre legal más largo; volver a vincular pedidos	Un cliente con un historial de 12 pedidos
E3	La línea ORD-1042 dice $54, el catálogo dice $59	Preservar order_items.unit_price como un hecho histórico	Se mantiene el precio promocional; catálogo intacto: dos números, ambos verdaderos
E4	La hoja de inventario dice 45 unidades del SKU insignia	Recalcular el stock a partir de movimientos: +120 comprados, −85 vendidos	El ganado es 35; la sábana se había movido +10
E9	Proveedor escrito como “Importadores de café Horzion”	Alias/resolución difusa al proveedor canónico	Reabastecimiento vinculado a la entidad correcta
E12	Teléfonos en blanco, celdas reservadas vacías	Los valores vacíos permanecen verdaderamente vacíos, nunca ceros ficticios	Datos honestos, sin marcadores de posición falsos

Los siete restantes cubren errores tipográficos de SKU (ETH-yir-wb-1000), nombres de productos reescritos donde debe haber una referencia de SKU, faltan correos electrónicos de clientes sin cita previa, caos en las carcasas (WHOLE BEAN / 1KG vs ground / 250g), una línea de pedido pegada dos veces y una SKU descontinuado pedido años después: importado y marcado, porque eliminar La historia es peor que conservarla.

El caso del E4 merece una mención, porque es el que sorprende a la gente: el La hoja de cálculo no estaba incorrecta el día en que se escribió. Se fue a la deriva. tres compra pedidos entrantes (+120 bolsas) y quince pedidos salientes (-85), el stock real es 35: el La hoja 45 es el residuo de actualizaciones manuales perdidas. Por eso la estructura objetivo almacena movimientos, no recuentos: el stock siempre se calcula, nunca se escribe a mano.

Explora la demostración en vivo

Todo lo anterior se puede consultar en demo.kamensky.dev — una aplicación de operaciones con todas las funciones que se ejecuta en la base de datos migrada (no de solo lectura):

• Panel de control y análisis: KPI calculados a partir de tablas limpias y vinculadas, no pegados desde una hoja.
• Ingreso de datos y permisos: roles de usuario autenticados con límites de permisos granulares e ingreso de datos en vivo.
• Libro mayor de inventario — stock calculado a partir del libro mayor de movimientos, con el Matemáticas compradas/vendidas/calculadas visibles por SKU.
• Cliente 360 — abierto Marcus Vance: 12 pedidos en ambas identidades heredadas, fusionados en una línea de tiempo.
• Pedidos, productos, proveedores, compras — directorios completos con páginas de detalles por pedido, SKU y proveedor.
• Notificaciones e integraciones: alertas operativas automatizadas y listas para integraciones externas.
• Informe de migración: la tabla de auditoría exacta anterior, representada a partir de la ejecución.

Los datos son ficticios (es una demostración), pero deterministas: cada regeneración comienza de los mismos datos de fuente fija: los mismos 12 defectos, los mismos 1.686 registros, cada vez. Eso es lo que hace que la migración sea demostrable en lugar de “probablemente bien”.

¿Está en riesgo su libro de trabajo?

Los defectos de demostración están plantados; el tuyo acumulado orgánicamente. Esta calculadora puntúa qué tan cerca está su libro de trabajo de los modos de falla anteriores: ingrese sus propios números:

MANTENERXYZ10XYZMANTENER

¿Tienes tu tienda sin una hoja de cálculo?La demostración utiliza SQLite (una base de datos integrada) para mantenerse autónoma; el mismo patrón de canalización es como yo

Migrar negocios de producción a bases de datos relacionales estructuradas, con ejecuciones paralelas y tiempo de inactividad cero. transición. Si su libro de trabajo muestra las señales, esa es la conversación que debe tener.

Reservar una llamada de descubrimiento →

Más sobre esto: consulta los artículos relacionados de Google Sheets y el Estudio de caso de migración de AppSheet a SQL, y Cuando Google Sheets deja de escalar.