Where VBA fits on a long engagement.

VBA solutions exist because they worked when nothing else was available. A macro written by an analyst fifteen years ago, running a monthly process nobody else understands, is a genuine business dependency regardless of what anyone thinks of the technology.

The risks are concentrated rather than diffuse: no version control, no tests, key-person dependency, and code that breaks when Office updates. The realistic first move is understanding and documenting what it does, because that knowledge is usually the thing genuinely at risk.

What an assigned team does with VBA.

Migration decisions should follow the business importance rather than the technology. A macro producing a report one person reads is different from one calculating figures that reach a regulator.

Triaging on that basis rather than replacing everything is the proportionate answer, agreed as part of how the monthly fee is built.

What we use VBA for.

  • Inherited macros documented What the code does captured, because that knowledge is the real exposure.
  • Migration triaged by importance Effort directed at what matters rather than at everything written in VBA.
  • Key-person dependency removed Processes understood by more than one person, whatever the eventual technology.

How VBA capacity is assigned.

Legacy automation work is assigned inside development capacity, starting from documentation of what exists rather than a replacement plan.

Tell us what your roadmap needs VBA for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.