Si ya trabaja con Google Cloud, o está pensando en llevar allí una aplicación, sus datos o su base de datos, esta página explica los destinos habituales y cómo se avanza sin apostarlo todo a un solo paso. Empezamos por un diagnóstico de sus datos y procesos antes de elegir destino.
Si ya trabaja con Google Cloud, o está pensando en llevar allí una aplicación, sus datos o su base de datos, esta página explica los destinos habituales y cómo se avanza sin apostarlo todo a un solo paso. Empezamos por un diagnóstico de sus datos y procesos antes de elegir destino. La nube de Google es una opción, no una obligación.
Para empezar basta con describir qué quiere mover y para qué se usa hoy. No envíe credenciales ni bases de datos.
Solicite su diagnóstico Proportione Legacy
Cada consulta tiene su sección, con sus propias preguntas:
«Migrar a Google Cloud» junta cosas que no se parecen: mover una aplicación, llevar datos a un sitio donde se puedan analizar, cambiar de base de datos o dejar de configurar a mano. Cada una tiene su servicio y sus riesgos. Por eso la primera pregunta no es «¿a qué servicio lo llevo?», sino «¿qué hace esto hoy y quién depende de ello?».
Operamos nuestros propios sistemas internos sobre Google Cloud (Cloud Run y Firestore). Y, en un caso anónimo, un sistema de gestión que dependía de software de un tercero sin evolución se llevó a una plataforma propia desplegada en Google Cloud Run. Con esa base trabajamos las secciones de abajo; para cada caso, el diagnóstico confirma si el destino encaja.
Si lo que busca es el marco general de mover servidores propios a la nube, lea migración a la nube de servidores propios. Y si lo que quiere mover es el correo, el calendario y los documentos, es otra migración: migración a Google Workspace.
Qué significa para usted: sabe qué pieza concreta va a mover y a qué servicio, antes de que nadie empiece a configurar nada. Siguiente paso: elegir la sección de abajo que se parece a su caso.
Cloud Run es el servicio de Google Cloud para ejecutar aplicaciones empaquetadas en contenedores. Según la documentación de Google sobre Cloud Run, se puede desplegar código escrito en cualquier lenguaje si se puede construir una imagen de contenedor con él, sin crear un clúster ni gestionar infraestructura, y el servicio escala para atender las peticiones que llegan.
Migrar una aplicación a Cloud Run es, por tanto, preparar esa aplicación para que se ejecute como un servicio en un contenedor: separar la configuración del código, sacar de la aplicación todo lo que guarda en el disco del servidor y dejar los datos en una base de datos aparte. En el caso de una aplicación de escritorio, como una hecha en Access, lo que se despliega allí es la aplicación nueva que la sustituye; el caso concreto está en actualizar Access a Google Cloud Run.
Qué significa para usted: la aplicación deja de depender de un servidor concreto y queda por escrito cómo se ejecuta. Siguiente paso: pedir el diagnóstico e indicar qué aplicación quiere llevar.
Cualquiera que pueda empaquetarse en una imagen de contenedor y que se ejecute como servicio. Una aplicación que depende de un equipo de escritorio, de ficheros en un disco local o de un componente que no se puede instalar en un contenedor necesita cambios antes. El diagnóstico los lista pieza a pieza.
No siempre. A veces basta con empaquetarla y ordenar dónde guarda sus datos; otras, con rehacer las partes que no encajan. Se concreta en el diagnóstico, con el inventario delante, y no por el nombre del servicio.
Se define en la propuesta por fases: o la opera su equipo, con la documentación entregada, o la operamos nosotros. En ambos casos el código es suyo, y así queda en el contrato.
BigQuery es el servicio de Google Cloud para analizar datos. En su documentación, Google indica que se pueden cargar por lotes datos desde ficheros locales o desde Cloud Storage, en formatos como CSV, JSON, Parquet o Avro, y también recibirlos de forma continua.
Llevar datos a BigQuery no consiste en subir ficheros: consiste en fijar qué datos responden a qué pregunta del negocio. Las fuentes más habituales son tres: hojas de cálculo que alguien actualiza a mano, la base de datos de una aplicación antigua y exportaciones periódicas de otros programas. Cada una exige su propio orden antes de cargarla, porque un dato que en origen está duplicado o sin criterio sigue estándolo en el destino.
Qué significa para usted: el análisis parte de datos ordenados y con responsable, no de una suma de ficheros. Siguiente paso: describirnos en el formulario de dónde salen hoy sus datos. Si lo que necesita es que los sistemas se hablen entre sí antes de analizar, empiece por integrar software antiguo con APIs y conectores.
Solicite su diagnóstico Proportione Legacy
Sí, las hojas pueden exportarse y cargarse. Lo importante no es la carga, sino que el formato sea estable: si cada persona usa columnas distintas, primero hay que unificarlas.
No es su función. BigQuery sirve para analizar; la base de datos de una aplicación sirve para que la aplicación funcione. Lo habitual es mantener ambas y llevar a BigQuery una copia ordenada de lo que hay que analizar.
Depende de lo que se acuerde. Si por política o por contrato el dato no debe salir, hay alternativas en instalaciones propias, que se valoran en el diagnóstico junto con la opción de la nube.
Son dos servicios con propósitos distintos. Cloud SQL es, según su documentación, un servicio gestionado de bases de datos relacionales para MySQL, PostgreSQL y SQL Server. Firestore es una base de datos de documentos, sin esquema fijo de tablas; es la que usamos en nuestros propios sistemas internos.
La elección no es de moda, sino de forma del dato. Si su información son tablas con relaciones claras entre sí (clientes, pedidos, facturas) y su aplicación consulta con SQL, el encaje natural es una base relacional. Si son documentos con estructura cambiante que se leen por su identificador, encaja mejor una base de documentos. Cambiar de una a otra no es mover ficheros: es repensar cómo la aplicación pide los datos.
Qué significa para usted: sabe qué base de datos encaja con su dato y cuánto de la aplicación hay que tocar para cambiarla. Siguiente paso: pedir el diagnóstico e indicar qué base de datos tiene.
Es una de las opciones que se valoran cuando la base de datos actual es del mismo motor que ofrece el servicio. Entonces el cambio se concentra en la conexión y en el traslado de los datos. Si el motor es otro, hay que revisar qué consultas siguen funcionando y cuáles se reescriben.
Firestore encaja con datos en forma de documentos que se leen por su identificador; una base relacional, con datos en tablas relacionadas y consultas cruzadas. El diagnóstico lo contrasta con sus consultas reales, no con una regla general.
Se define de antemano qué se compara (recuentos, totales, muestras) y qué diferencia se acepta. Se comprueba al terminar cada fase, con criterios de aceptación fijados antes de empezar, y la vuelta atrás está preparada por si no se cumplen.
La herramienta de línea de comandos de Google Cloud, `gcloud`, es, según su documentación, un conjunto de herramientas para crear y gestionar recursos de Google Cloud, que se puede usar desde un terminal o desde scripts.
Para usted lo que importa no es la herramienta, sino lo que permite: que la configuración de la aplicación, de la base de datos y de los permisos esté escrita en comandos que se pueden volver a ejecutar, en lugar de depender de lo que alguien hizo un día en la consola. Un entorno así se puede repetir en otro proyecto, se puede revisar antes de cambiarlo y se puede entregar documentado.
Qué significa para usted: el sistema no depende de la memoria de una persona, ni de la nuestra. Siguiente paso: pedir el diagnóstico y decirnos quién operará el sistema después.
No necesariamente. La documentación entregada explica cómo se ejecuta cada paso. Quien lo opere sí necesita permisos y una formación básica, que se acuerdan en la propuesta por fases.
Un despliegue descrito en ficheros, con el código y la exportación de datos en su poder, permite hacerlo sin partir de cero. Es parte del diseño: documentación, exportación y custodia comprobables.
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.
Si lo que necesita es construir el sistema que irá a Google Cloud, vea desarrollo de software a medida; y si Google Cloud es solo una de varias piezas antiguas que hay que ordenar, vea el conjunto en migración de sistemas legacy.
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.
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 inteligencia artificial en la empresa. La nube de Google es una opción más, no la única ni la obligada.
Qué significa para usted: sus datos no tienen por qué salir de sus instalaciones. Siguiente paso: si quiere ver el conjunto de lo que hacemos, consulte 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.
No. La nube no es obligatoria. 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. Lo que se lleva y lo que se queda se acuerda pieza a pieza en la propuesta.
Depende del alcance: qué se mueve, cuántas piezas hay y qué tiene que hacer cada una después. Por eso no damos una cifra ni un plazo sin conocer su caso. La propuesta de alcance por fases es el punto donde se concretan.
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. La vuelta atrás forma parte del diseño: se define antes de tocar nada.
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.
Operamos nuestros propios sistemas internos sobre Google Cloud (Cloud Run y Firestore) y, en un caso anónimo, un sistema de gestión que dependía de software de un tercero sin evolución se llevó a una plataforma propia desplegada en Google Cloud Run. Para el resto de servicios de esta página, el diagnóstico confirma si encajan con su caso.
Cuéntenos qué quiere llevar a Google Cloud 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.
