If you already work with Google Cloud, or are thinking of moving an application, your data, or your database there, this page explains the usual destinations and how to proceed without betting everything on a single step. We start with a diagnosis of your data and processes before choosing a destination.
If you already work with Google Cloud, or are thinking of moving an application, your data, or your database there, this page explains the usual destinations and how to proceed without betting everything on a single step. We start with a diagnosis of your data and processes before choosing a destination. Google Cloud is an option, not an obligation.
To start, simply describe what you want to move and what it is used for today. Do not send credentials or databases.
Request your Proportione Legacy diagnosis
Each query has its section, with its own questions:
“Migrating to Google Cloud” brings together disparate elements: moving an application, transferring data for analysis, changing databases, or eliminating manual configuration. Each has its own service and risks. Therefore, the first question isn't “Which service should I use?”, but rather “What does this do today and who depends on it?”.
We operate our own internal systems on Google Cloud (Cloud Run and Firestore). In one anonymized case, a management system reliant on outdated third-party software was migrated to a proprietary platform deployed on Google Cloud Run. With this foundation, we address the sections below; for each scenario, the diagnosis confirms if the destination is suitable.
If you are looking for the general framework for moving your own servers to the cloud, read migration of own servers to the cloud. And if you want to move email, calendar, and documents, that's a different migration: migration to Google Workspace.
What it means for you: knows exactly which piece to move and to which service, before anyone starts configuring anything. Next step: choose the section below that best matches your case.
Cloud Run is the Google Cloud service for running container-packaged applications. According to Google's documentation on Cloud Run, code written in any language can be deployed if a container image can be built with it, without creating a cluster or managing infrastructure, and the service scales to handle incoming requests.
Migrating an application to Cloud Run is, therefore, preparing that application to run as a service in a container: separating configuration from code, removing everything from the application that is stored on the server's disk, and leaving the data in a separate database. In the case of a desktop application, such as one made in Access, what is deployed there is the new application that replaces it; the specific case is in updating Access to Google Cloud Run.
What it means for you: the application ceases to depend on a specific server and how it runs is put in writing. Next step: request the diagnosis and indicate which application you want to migrate.
Any application that can be packaged into a container image and run as a service. An application that depends on a desktop computer, files on a local disk, or a component that cannot be installed in a container needs changes beforehand. The diagnosis lists them piece by piece.
Not always. Sometimes it is enough to package it and sort out where it stores its data; other times, to rebuild the parts that do not fit. This is determined in the diagnostic, with the inventory in front of us, rather than by the name of the service.
This is defined in the phased proposal: either your team operates it, using the delivered documentation, or we operate it. In both cases, the code belongs to you, and that is stipulated in the contract.
BigQuery is Google Cloud's service for analyzing data. In its documentation, Google indicates that data can be batch loaded from local files or from Cloud Storage, in formats such as CSV, JSON, Parquet, or Avro, and also received continuously.
Moving data to BigQuery is not about uploading files: it's about defining which data answers which business question. The most common sources are three: spreadsheets that someone updates manually, the database of an old application, and periodic exports from other programs. Each requires its own order before loading, because data that is duplicated or lacks criteria at the source remains so at the destination.
What it means for you: analysis starts with organized data with an owner, not with a collection of files. Next step: describe in the form where your data comes from today. If what you need is for systems to talk to each other before analyzing, start by integrating old software with APIs and connectors.
Request your Proportione Legacy diagnosis
Yes, spreadsheets can be exported and uploaded. The important thing is not the upload itself, but that the format is stable: if each person uses different columns, they must first be unified.
That is not its function. BigQuery is used for analysis; an application's database is used to keep the application running. The standard approach is to maintain both and send an organized copy of what needs to be analyzed to BigQuery.
It depends on what is agreed upon. If, due to policy or contract, the data must not leave, there are alternatives for on-premises facilities, which are evaluated in the diagnosis alongside the cloud option.
They are two services with different purposes. Cloud SQL is, depending on your documentation, a managed relational database service for MySQL, PostgreSQL, and SQL Server. Firestore is a document database with no fixed table schema; it is the one we use in our own internal systems.
The choice is not about fashion, but about the shape of the data. If your information consists of tables with clear relationships between them (customers, orders, invoices) and your application queries them with SQL, the natural fit is a relational database. If they are documents with a changing structure that are read by their identifier, a document database fits better. Changing from one to the other is not just moving files: it is rethinking how the application requests the data.
What it means for you: knows which database fits your data and how much of the application needs to be touched to change it. Next step: request the diagnosis and indicate what database you have.
It is one of the options considered when the current database uses the same engine offered by the service. Then the change focuses on the connection and data transfer. If the engine is different, you need to review which queries still work and which need to be rewritten.
Firestore fits data in the form of documents that are read by their identifier; a relational database fits data in related tables and cross-queries. The diagnosis contrasts this with your actual queries, not with a general rule.
What is compared (counts, totals, samples) and what acceptable difference is defined beforehand. It is verified at the end of each phase, with acceptance criteria set before starting, and a rollback plan is ready in case they are not met.
The Google Cloud command-line tool, `gcloud`, is, according to its documentation, a set of tools to create and manage Google Cloud resources, which can be used from a terminal or from scripts.
What matters to you is not the tool, but what it enables: having application, database, and permission configurations written in re-runnable commands, rather than depending on what someone once did in the console. Such an environment can be replicated in another project, reviewed before modification, and delivered fully documented.
What it means for you: the system does not depend on one person's memory, nor on ours. Next step: request the diagnosis and tell us who will operate the system afterwards.
Not necessarily. The provided documentation explains how each step is executed. Whoever operates it will need permissions and basic training, which are agreed upon in the phased proposal.
A deployment described in files, with the code and data export in your possession, allows you to do this without starting from scratch. It is part of the design: verifiable documentation, export, and custody.
Whatever the destination, the method is the same. The general details are in how we work.
1. Diagnosis: inventory of processes and data, options (build, buy, or connect), and phased scope proposal. 2. Bounded pilot, with acceptance criteria set in advance, before proceeding, when the case requires it. 3. Phased delivery, with acceptance criteria and rollback plan. 4. Handover: verifiable documentation, export, and custody. The code belongs to you, and that is stated in the contract.
If what you need is to build the system that will go to Google Cloud, see custom software development; and if Google Cloud is just one of several legacy pieces that need to be organized, view the whole picture in legacy systems migration service.
What it means for you: at all times you know what has been delivered, what is missing, and how to roll back. Next step: request the diagnosis.
The order is always the same: first, the process is digitized and understood; then, legacy software is opened up with APIs and connectors to link it with the rest, and only then is AI considered on top.
AI can run on your own server and, if necessary, offline. This is the same option we described in artificial intelligence in business. Google's cloud is just one more option, not the only one nor a mandatory one.
What it means for you: your data does not have to leave your premises. Next step: if you want to see the full scope of what we do, consult Business Management Consulting and our services.
For a diagnosis of your data and processes, before choosing a destination. It delivers a process and data inventory, the options (build, buy, or connect), and a phased scope proposal.
No. The cloud is not mandatory. Extraction, migration, and any subsequent AI can run on your servers or dedicated hardware, even on an offline network. What goes to the cloud and what stays on-premise is agreed upon piece by piece in the proposal.
It depends on the scope: what is being moved, how many pieces there are, and what each one needs to do afterwards. That is why we do not give a figure or a timeframe without knowing your case. The phased scope proposal is where these details are finalized.
It is delivered in phases, with acceptance criteria and a rollback plan, so that each step can be verified and, if necessary, undone. The rollback plan is part of the design: it is defined before touching anything.
The code belongs to the client, and this is explicitly stated in the contract. Documentation, exportability, and custody are verifiable and form part of the design.
We operate our own internal systems on Google Cloud (Cloud Run and Firestore) and, in an anonymous case, a management system that relied on third-party software with no evolution was moved to a proprietary platform deployed on Google Cloud Run. For the rest of the services on this page, the diagnosis confirms whether they fit your case.
Tell us what you want to move to Google Cloud and what destination you have in mind. We will reply within a maximum of two business days. [Short form: see specification in notes] If you prefer to write to us directly: contact.
Request your Proportione Legacy diagnosisDo not send credentials or databases. We will use your data only to respond to you; more information in the Privacy Policy.
