Una aplicación hecha en Access suele empezar como una solución rápida y acaba siendo el sistema del que depende una parte de la operación. Si hoy la usa una persona o un equipo y no sabe qué pasaría si dejara de funcionar, esta página es para usted: explica las opciones de destino y cómo se avanza sin apostarlo todo a un solo paso.
Una aplicación hecha en Access suele empezar como una solución rápida y acaba siendo el sistema del que depende una parte de la operación. Si hoy la usa una persona o un equipo y no sabe qué pasaría si dejara de funcionar, esta página es para usted: explica las opciones de destino y cómo se avanza sin apostarlo todo a un solo paso.
Para empezar basta con describir qué hace la aplicación. No envíe credenciales ni bases de datos.
Cada consulta tiene su sección, con sus propias preguntas:
Una aplicación Access mezcla en un solo fichero cuatro cosas distintas: las tablas con los datos, los formularios con los que se trabaja, los informes que se imprimen o exportan y el código (consultas y macros) que une todo. Migrarla es decidir qué hacer con cada pieza, no cambiar un fichero por otro. Si además hay aplicaciones en otros lenguajes heredados, como Visual Basic 6, vea migrar aplicaciones en lenguajes heredados.
Por eso la primera pregunta no es «¿a qué lo llevo?», sino «¿qué hace realmente?». Empezamos por un diagnóstico de sus datos y procesos antes de elegir destino. Entrega un inventario de procesos y datos, las opciones (construir, comprar o conectar) y una propuesta de alcance por fases.
Qué significa para usted: sabe qué contiene la aplicación y qué papel juega antes de decidir. Siguiente paso: elegir la sección de abajo que se parece a su caso.
Migrar Access a SQL Server es llevar las tablas a una base de datos de servidor. Los datos dejan de estar en un fichero que cada usuario abre y pasan a vivir en un sitio único, con control de accesos y copias gestionadas aparte.
Lo que no se resuelve solo con mover las tablas son las pantallas, los informes y las macros: siguen siendo de Access y tienen que seguir funcionando contra la nueva base de datos, o rehacerse. Se decide en el diagnóstico, pieza a pieza.
Qué significa para usted: los datos quedan ordenados y en un sitio controlado, y se sabe qué parte de la aplicación sigue pendiente. Siguiente paso: pedir el diagnóstico y revisar la propuesta por fases.
Es una de las opciones que se valoran: los datos pasan al servidor y las pantallas siguen en Access, conectadas a esa base de datos. Sirve como primer paso por fases. Que sea el destino final o no depende de lo que el diagnóstico encuentre en sus formularios, informes y macros.
Se inventarían como parte del diagnóstico. Unas se conservan, otras se reescriben en la base de datos o en una aplicación nueva, y las que ya no se usan se retiran. Cada decisión queda por escrito en la propuesta por fases.
Se entrega por fases, con criterios de aceptación y plan de vuelta atrás. La vuelta atrás forma parte del diseño: se define antes de tocar nada.
Pasar una aplicación Access a una aplicación web es rehacer las pantallas y la lógica para que se usen desde el navegador, con una base de datos de servidor detrás. Es un cambio mayor que mover las tablas, y por eso conviene entender primero qué procesos soporta.
Hay dos razones habituales para plantearlo: que más gente tenga que usarla (también desde fuera de la oficina) y que la aplicación tenga que hablar con otros sistemas. En el segundo caso, a veces no hace falta rehacerla entera: basta con conectarla mediante APIs y conectores.
Qué significa para usted: no tiene que decidir entre «rehacerlo todo» y «dejarlo como está»: hay una tercera vía. Siguiente paso: si quiere ver cómo trabajamos el desarrollo, consulte desarrollo de software a medida.
Solicite su diagnóstico Proportione Legacy
Casi siempre hay que rehacer las pantallas, porque un formulario de Access no se ejecuta en el navegador. La lógica y los datos se aprovechan en la medida en que el diagnóstico los encuentre ordenados. Por eso el alcance sale del inventario, no de una estimación a ojo.
Con entrega por fases, la antigua puede seguir en uso hasta que la fase correspondiente de la nueva cumple sus criterios de aceptación. El plan de vuelta atrás cubre el momento del cambio.
Si un producto cubre su necesidad sin forzar su forma de trabajar, es normalmente la mejor opción. El diagnóstico compara construir, comprar y conectar con datos de su caso.
Quien busca «actualizar Access a Google Cloud Run» suele querer que su aplicación deje de depender de un ordenador de oficina y pase a la nube de Google. Conviene aclarar un punto: Access es una herramienta de escritorio y no se ejecuta como tal en Cloud Run. Lo que se despliega allí es una aplicación web nueva, empaquetada en un contenedor, con su base de datos gestionada aparte.
Es un destino válido cuando la empresa ya trabaja en Google Cloud o quiere un servicio que escale sin gestionar servidores. No es el destino obligado: si su empresa no usa esa nube, otras opciones encajan igual o mejor. Lo decide el diagnóstico, no el nombre de la plataforma.
Qué significa para usted: la aplicación deja de estar ligada a un equipo concreto y queda por escrito cómo se sale. Siguiente paso: pedir el diagnóstico e indicar en el formulario que su destino previsto es Google Cloud.
No. Cloud Run ejecuta contenedores con aplicaciones de servidor. La aplicación Access se sustituye por una aplicación web que hace lo mismo, y los datos se llevan a una base de datos gestionada.
No. Es una opción entre varias. La elección depende de dónde trabaja ya su empresa, de dónde deben estar los datos y de qué equipo va a operar la aplicación después.
El código es del cliente, y así queda en el contrato. La documentación, la exportación y la custodia son comprobables y forman parte del diseño.
A menudo el «sistema» no es una base de datos Access, sino un libro de Excel con macros que alguien montó hace años y que solo entiende una persona. Funciona hasta el día que esa persona no está, o que Excel cambia de versión, o que dos usuarios necesitan editarlo a la vez.
Migrar macros y hojas de Excel a una aplicación empieza por lo mismo que cualquier otra migración: entender qué proceso sostiene el libro, qué datos lleva y quién depende de él. Después se decide si hay que construir una aplicación, si basta con ordenar los datos en una base de datos o si es mejor conectar el libro con otra herramienta. Si el libro hace de CRM, vea de hojas de cálculo a CRM.
Qué significa para usted: conocer qué proceso hay detrás le permite decidir con criterio y no por prisa. Siguiente paso: describirnos el caso en el formulario.
Las macros se inventarían y se decide, una por una, si se conservan, se reescriben o se retiran. Una macro que automatiza un proceso confuso no se traslada: primero se ordena el proceso.
Depende de quién use los datos y para qué. Si solo hace falta ordenarlos y consultarlos, puede bastar una base de datos; si hay un proceso con pasos y responsables, normalmente hace falta una aplicación. El diagnóstico lo aclara.
Sea cual sea el destino, el método es el mismo. Los detalles generales están en cómo trabajamos.
1. Diagnóstico: inventario de procesos y datos, opciones (construir, comprar o conectar) y propuesta de alcance por fases. 2. Piloto acotado, con criterios de aceptación fijados de antemano, antes de seguir, cuando el caso lo pide. 3. Entrega por fases, con criterios de aceptación y plan de vuelta atrás. 4. Traspaso: documentación, exportación y custodia comprobables. El código es suyo, y así queda en el contrato.
Qué significa para usted: en cada momento sabe qué se ha entregado, qué falta y cómo se vuelve atrás. Siguiente paso: pedir el diagnóstico.
El orden es siempre el mismo: primero se digitaliza y se entiende el proceso; después se abre el software antiguo con APIs y conectores para unirlo con el resto, y solo entonces se plantea la IA encima. Planteamos la IA después, cuando el proceso está entendido y los datos ordenados.
La IA puede ejecutarse en su propio servidor y, si hace falta, sin conexión a Internet. Es la misma opción que describimos en migración de sistemas legacy y en inteligencia artificial en la empresa.
Qué significa para usted: sus datos no tienen por qué salir de sus instalaciones. Siguiente paso: si su aplicación Access es solo una de varias piezas antiguas, vea el conjunto en consultoría de gestión de negocio y nuestros servicios.
Por un diagnóstico de sus datos y procesos, antes de elegir destino. Entrega un inventario de procesos y datos, las opciones (construir, comprar o conectar) y una propuesta de alcance por fases.
Depende del alcance: cuántas tablas, formularios, informes y macros hay, y qué tienen que hacer después. Por eso no damos una cifra sin conocer su caso. La propuesta de alcance por fases es el punto donde se concreta.
Depende del alcance. Trabajamos por fases, cada una con sus criterios de aceptación, y el calendario sale de la propuesta de alcance por fases. No damos un plazo único sin conocer su caso.
Se entrega por fases, con criterios de aceptación y plan de vuelta atrás, para que cada paso se pueda comprobar y, si hace falta, deshacer. Cómo se organiza el cambio de cada fase se define en la propuesta.
Sí. La extracción, la migración y la IA que se use después pueden ejecutarse en sus servidores o en hardware dedicado, incluso en una red sin conexión a Internet.
El código es del cliente, y así queda en el contrato. La documentación, la exportación y la custodia son comprobables y forman parte del diseño.
Cuéntenos qué hace su aplicación y con qué destino está pensando. Le respondemos en un máximo de dos días laborables. [Formulario corto: ver especificación en notas] Si prefiere escribirnos directamente: contacto.
Solicite su diagnóstico Proportione LegacyNo envíe credenciales ni bases de datos. Usaremos sus datos solo para responderle; más información en la política de privacidad.
