VBA to Office Scripts Migration
Moving Excel automation to the cloud is not a simple rewrite. Office Scripts have real limitations that catch organisations out — especially in SharePoint environments. We navigate the nuances so your automations actually work.
Talk to an automation specialistWhy organisations are moving away from VBA
VBA served organisations well for decades. But Microsoft 365 environments have fundamentally changed the context it operates in.
VBA breaks in Excel for the web and mobile
VBA macros only run in the desktop application. As organisations move to Microsoft 365 and web-based Excel, VBA becomes a blocker — users on non-Windows devices or shared workbooks hit silent failures.
Macros flagged as security risks
Enterprise IT teams increasingly block or restrict macro-enabled workbooks. Trust Centre policies, Protected View, and Intune device management settings mean VBA-enabled files are quarantined or stripped before they reach end users.
No integration with modern automation platforms
VBA cannot be triggered by Power Automate, logic apps, or REST APIs. This means automation workflows that touch Excel must work around VBA rather than through it.
Version control and collaboration conflicts
VBA is embedded in workbook files. When multiple users share a file via SharePoint or OneDrive, VBA code cannot be version-controlled cleanly, and co-authoring is not supported in macro-enabled workbooks.
Real limitations you need to know
Office Scripts is a capable platform — but it is not VBA with a cloud label. These constraints need to be understood before any migration is planned.
No access to the local file system
Office Scripts run in a sandboxed cloud environment. They cannot read from or write to local drives, network paths, or UNC paths. Any automation that currently pulls from a mapped drive must be rearchitected to use SharePoint document libraries or OneDrive.
No external HTTP calls from scripts directly
Unlike VBA with WinHTTP or XMLHTTP, Office Scripts cannot make arbitrary HTTP requests to external APIs. External data calls must be handled by Power Automate flows that pass data into scripts as parameters.
Single-threaded, time-limited execution
Office Scripts run synchronously with a hard execution limit. Scripts that process large datasets or perform many sequential operations can hit timeout thresholds. Logic that loops over thousands of rows needs to be restructured using batch API patterns.
No UI/dialog interaction
VBA can show userforms, MsgBox dialogs, and custom UI elements. Office Scripts have no equivalent — all user interaction must happen through the Excel interface, task panes (Office Add-ins), or Power Automate approval flows.
Limited inter-workbook operations
VBA can open, read, and write to other workbooks with full object model access. Office Scripts can only operate on the workbook passed to them by Power Automate — cross-workbook orchestration requires a flow that runs multiple scripts in sequence.
TypeScript only — no legacy VBA libraries
Office Scripts are written in TypeScript, not VBA. Any code that relies on third-party VBA libraries, COM references, or Windows API calls must be fully rewritten. The Office Scripts API surface is also more limited than the full Excel VBA object model.
SharePoint deployment — what no one tells you
Most Office Scripts documentation focuses on individual use. Deploying in a SharePoint team context introduces a different set of constraints.
Scripts are stored per-user, not per-file
By default, Office Scripts are saved to the author's OneDrive, not inside the workbook or the SharePoint site. This means another user cannot run your script unless it has been shared explicitly or deployed via an organisational scripts library through admin policy.
Shared scripts require specific tenant admin configuration
For scripts to be shared across a team or organisation, IT must enable the "Share scripts across the organisation" setting in the Microsoft 365 Admin Centre. Without this, each user sees only their own scripts — a significant operational gap in a SharePoint team context.
Power Automate is the deployment mechanism
The practical deployment pattern for Office Scripts in SharePoint is Power Automate. Flows trigger scripts against specific SharePoint-hosted workbooks, handle scheduling, pass in parameters, and manage outputs. This coupling means changes to scripts also require flow maintenance.
Licensing gates automation at scale
Running Office Scripts via Power Automate requires a Power Automate per-user or per-flow licence in addition to a Microsoft 365 Business Standard or above licence. The "Run script" action is not available on the free Power Automate tier. This is consistently missed in initial planning.
Co-authoring is supported but concurrency is not
Multiple users can view a workbook simultaneously in SharePoint, but Office Scripts cannot be run on a workbook that another user is actively editing. Automations that run unattended must account for file lock states.
VBA vs Office Scripts — when to use which
| Scenario | VBA | Office Scripts |
|---|---|---|
| Runs on Windows desktop only | ||
| Runs in Excel for the web / SharePoint | ||
| Triggered by Power Automate on a schedule | ||
| Complex userforms and custom UI | ||
| Full Excel object model access | ||
| Co-authoring compatible workbooks | ||
| Access to local file system / network drives | ||
| No IT macro policy restrictions | ||
| Calls external APIs directly | ||
| Integrates with Teams and SharePoint natively |
How we approach migration
Structured, practical, no surprises
Automation Audit
We review your existing VBA codebase, identify what is a direct port, what needs redesign, and what is better left in VBA or moved to a different technology entirely. Not everything should migrate.
Architecture Design
We design the target state — which automations become Office Scripts, which become Power Automate flows, which require Power Query or Power Apps. We map SharePoint library structures, licensing requirements, and deployment approach before writing a line of code.
Migration & Testing
Scripts are written in TypeScript against the Office Scripts API, tested against real SharePoint-hosted workbooks, and validated for edge cases. Power Automate flows are built and documented. We test under actual M365 tenant conditions, not just local.
Deployment & Handover
We configure organisational script sharing, document the deployment model, and train your team on managing flows and scripts. You receive working automations and the knowledge to maintain them.
Frequently asked questions
Should we migrate all our VBA to Office Scripts?
Not necessarily. VBA remains the right choice for desktop-only automations, complex UI-driven tools, workbooks that do not need to run in the cloud, and scenarios requiring full Excel object model access. We assess each automation individually and recommend migration only where it adds genuine value.
Can Office Scripts replace VBA userforms?
No. Office Scripts have no UI capability. If your VBA relies on userforms or dialogs, the replacement is either an Office Add-in task pane (a web-based interface), a Power Apps canvas app, or a redesigned workflow that eliminates the need for user input at runtime.
Do all Microsoft 365 licences include Office Scripts?
No. Office Scripts are included in Microsoft 365 Business Standard, Business Premium, E3, and E5. They are not available in Microsoft 365 Business Basic or Microsoft 365 Apps for Business. Running scripts via Power Automate also requires a qualifying Power Automate licence.
How does Office Scripts perform with large Excel files?
Performance depends on how the script is written. Reading and writing large ranges in bulk (using getValues/setValues on whole ranges rather than cell-by-cell loops) is significantly faster. Scripts that iterate row-by-row on thousands of records will time out. We design scripts with the batch API pattern from the outset.
Can Office Scripts trigger automatically on a schedule?
Yes, but only via Power Automate. A scheduled flow in Power Automate calls the "Run script" action against a specific workbook in SharePoint or OneDrive. The script itself cannot self-schedule — it always needs a flow trigger.
We use SharePoint on-premises, not SharePoint Online. Does this work?
No. Office Scripts require Microsoft 365 cloud services and Excel for the web. They do not function against SharePoint Server (on-premises). If your organisation has not migrated to SharePoint Online, VBA or alternative automation approaches remain the path forward.
XLS Experts provides VBA to Office Scripts migration services to organisations across New Zealand, including Auckland, Wellington, Christchurch, Hamilton, and Tauranga. Most migration work is delivered remotely via Microsoft 365.
Not sure whether to migrate?
We will assess your existing VBA and give you an honest view of what should move to Office Scripts, what should stay, and what needs a different approach.
Book a free discovery callLet's talk about what you need
Big or small, we are happy to discuss it. Send us a message or book a free discovery call — we typically respond same business day.
What happens next
- 1
We review your enquiry and reach out to discuss your requirements — no commitment needed.
- 2
We provide a no-obligation quote and estimated delivery timeframe.
- 3
Once agreed, we build in stages and keep you updated throughout.