"We want to move to Google Workspace, but accounting and production control use Excel macros, and operations will stop if those don't work, so it's difficult"—this is the most common response in migration consultations.
While many companies stall here, when you look closer, most have "not confirmed that they don't work, but simply haven't checked whether they do." Because macros are the internal black boxes people least want to touch, the decision to give up without opening them occurs naturally.
However, whether something can be migrated is not a matter of gut feeling. Google provides tools to measure in advance whether Excel VBA can be converted to Apps Script.
There are tools to measure whether it will work
The Macro Converter add-on provided on the Google Workspace Marketplace is intended for converting Excel files containing VBA into Google Sheets and Apps Script. What is important is not the conversion function itself, but rather the "compatibility report" that can be generated before conversion.
The report classifies whether the APIs used in the file can be replaced with Apps Script.
| Determination | Meaning | Practical handling |
|---|---|---|
| Supported exactly | Equivalent functionality exists in Apps Script | Can be migrated almost as-is |
| Supported with workarounds | Achievable by writing workarounds | Estimate as rewrite person-hours |
| Needs more investigation | Support unknown, or individual investigation required | This determines migration feasibility |
Once this report is generated, the topic of discussion shifts from "can we migrate or not" to "where will take how many days." Moving forward from the state of giving up without opening macros usually starts with this step.
However, there are constraints. Macro Converter is only available on editions equivalent to Google Workspace Enterprise Plus and Education Plus. It cannot be used on Business Standard or Business Plus. Since these are precisely the editions companies considering migration do not have contracted, this becomes a practical barrier.
What to do first when editions fall short
Even if the add-on cannot be used, 80% of the evaluation can be done on your own. Simply categorize the VBA contents into the following three types:
- In-sheet aggregation, transcription, and formatting. Copying values to another sheet, conditional coloring, and row sorting. This layer translates straightforwardly into Apps Script. You will rarely run into trouble migrating it.
- Processing predicated on Excel screen operations. Forms, custom dialogs, and key bindings like
Application.OnKey. This is not a matter of being unable to migrate, but rather requiring a rebuild. Because the UI on the Google Sheets side is fundamentally different, aiming to replicate the exact same look will inevitably hit a wall. - External integrations. Connections to Access or SQL Server, reading/writing local files, Outlook operations, and third-party COM components. This is the core challenge. Because the cloud side cannot directly reach internal file servers or on-premises databases, this becomes a architectural redesign of data routes rather than a migration.
Depending on how much processing falls into the third category, the nature of the migration changes. If it is only 1 and 2, it is a migration task; if it centers on 3, it is a rebuild of business systems. Check this first, as it is the branching point where estimates can vary by dozens of times.
Even if migrated, it will not be identical
Even if conversion succeeds, it does not necessarily mean it can be used as-is. Apps Script has constraints that do not exist in Excel VBA.
The biggest obstacle is the execution time limit. A single run of an Apps Script script is terminated at 6 minutes. Upgrading editions does not extend this. Macros designed to process every record sequentially hit this wall as soon as data volume increases. You need to decide whether to split the processing or abandon batch processing altogether. How to address this constraint is summarized in The Apps Script 6-minute limit.
Another factor is execution speed. Directly porting a coding style that reads and writes cells one by one, like VBA, makes execution extremely slow. In Apps Script, code must be rewritten to read ranges in batches and write them back in batches, which automatic conversion cannot fully handle. This is the primary reason macros run "functional but too slow to use" immediately after conversion.
Furthermore, the handoff problem remains. Converted code becomes Apps Script while dragging along the original structure of the VBA. The situation where no one internally can read it does not change after migration. What happens when Apps Script becomes dependent on specific individuals is summarized in Apps Script maintenance.
Divide migration units by business operation, not by macro
After the evaluation is complete, many companies adopt the approach of "migrating starting with macros that converted successfully." This tends to reverse the proper order.
Macros are embedded in the middle of workflows. If preceding steps remain in Excel while only intermediary macros move to Sheets, new back-and-forth file transfers are created. Complaints that procedures became more tedious than before migration stem from this.
The units to carve out are workflow clusters, such as "monthly closing aggregations" or "order data imports." Determine whether you can migrate the files and macros used by that business operation in their entirety. If they cannot be migrated as a whole, exclude that operation from the current scope and leave it in place. Not trying to migrate everything is the surest way to complete a migration.
Compatibility for standard Excel files that do not contain macros has improved significantly compared to before. For handling tables and pivot tables, refer to Importing Excel tables and pivot tables. The procedure for migrating data itself can be found in Migrating from Microsoft 365.
Revisiting whether to migrate in the first place
As a result of evaluation, you may find that "it will work if rewritten." At that point, it is worth pausing for a moment.
The reason that macro was created in the first place was, in many cases, because "there was no other means at the time." For the same processing, handling it today as a core business system or workflow—rather than in Excel or spreadsheets—is often more straightforward. In particular, macros predicated on multiple people editing the same file sequentially are inherently stretching the limits of spreadsheets.
Determining whether to rebuild upon migration or migrate as-is is discussed in Deciding whether to systematize Excel workflows. If you postpone the decision and choose to "just migrate for now," you will end up having the exact same discussion again after the migration.
What to do next
First, list up to five macros that are bottlenecking your operations. The reason to narrow down the count is that counting everything makes it impossible to start. If you write down five, asking the person who created them or the staff using them daily will generally reveal which of the three categories above they fall into.
On top of that, check first only whether any fall under external integrations (the third category). If macros are concentrated here, it becomes an architecture discussion rather than a migration discussion. Conversely, if there are only 1 and 2, migration is within realistic reach.
GleamHub provides support for Google Workspace migration assessments, Excel macro inventory and migration strategy development, and re-implementation in Apps Script through our free IT and Google Workspace consultations. Because the approach depends on your current edition and macro details, please consult us individually via Contact.
Sources
- Convert VBA macros to Apps Script — Google for Developers
- Determine if VBA macros are compatible — Google for Developers
- Use Macro Converter add-on to convert Microsoft Excel files with macros to Google Sheets — Google Workspace Updates
- Macro Converter — Google Workspace Marketplace
- Apps Script quotas — Google for Developers
