Was ist VBA? - Grenzen, Zukunftsfähigkeit, wann ein Ersatz sinnvoll ist, und realistische Migrationsmuster

In Beratungsgesprächen zu VBA vermischen sich oft folgende Themen.

• Was ist VBA überhaupt?
• Makros gelten als gefährlich – sollte man sie nicht mehr verwenden?
• Wird es künftig nicht mehr nutzbar sein?
• Sollte man alles auf Office Scripts oder Power Automate übertragen?
• Sollten bestehende .xlsm- und Access-Bestände erhalten oder verworfen werden?
• Darf man Excel in einem Nachtjob oder auf einem Server laufen lassen?

Das ist kein Thema, das sich mit einer einzigen Antwort sauber erledigen lässt. Was man zuerst betrachten sollte, ist weniger die Frage neu oder alt, sondern wo es ausgeführt wird, wer es nutzt, ob Excel / Access selbst die Benutzeroberfläche ist, und ob die Ausführung unbeaufsichtigt erfolgt.

Dieser Artikel ordnet die Themen in dieser Reihenfolge: Was VBA ist, wo seine Grenzen liegen, ob es künftig nicht mehr nutzbar sein wird, in welchen Fällen ein Ersatz sinnvoll ist, und wie eine schrittweise Migration realistisch aussieht. Der Inhalt basiert auf Microsofts offiziellen Informationen, die Stand März 2026 verifizierbar sind.¹²³⁴⁵

1. Zunächst das Fazit

Vorab die Kernaussagen im Überblick.

• VBA ist eine ereignisgesteuerte Sprache zur Erweiterung von Office-Desktopanwendungen. Es ist eine Technologie, die von vornherein darauf ausgelegt ist, innerhalb von Excel, Word, PowerPoint, Access und Ähnlichem zu laufen.¹
• Mindestens Stand März 2026 lässt sich aus Microsofts offiziellen Informationen keine klare Ankündigung erkennen, dass „VBA selbst in absehbarer Zeit eingestellt wird“. Was gerade passiert, ist weniger eine „plötzliche vollständige Abschaffung“ als vielmehr eine Veränderung, bei der klarer wird, wo VBA einsetzbar ist und unter welchen Voraussetzungen.¹²³⁴
• Konkret lässt sich in Excel for the web VBA weder erstellen, ausführen noch bearbeiten. Außerdem werden Makros in aus dem Internet stammenden Dateien standardmäßig blockiert.²³
• Die eigentliche Frage lautet daher nicht „Wirft man VBA komplett weg?“, sondern welche Bereiche in VBA verbleiben und welche ausgelagert werden.
• Insbesondere Verarbeitungen, die unbeaufsichtigte Ausführung, serverseitige Ausführung, Mehrbenutzerbetrieb, Browser-Unterstützung, zentrale Verteilung oder eine strenge Auditierung erfordern, sollten nicht allein von VBA getragen werden. Auch Microsoft empfiehlt und unterstützt die serverseitige Automatisierung von Office nicht.⁶
• Es gibt nicht nur ein Migrationsziel. Realistisch ist folgende Aufteilung: Wenn Excel erhalten bleibt, wird die Verarbeitung in eine .NET-DLL oder einen separaten Prozess ausgelagert; für Geschäftsprozesse auf Microsoft 365 eignen sich Office Scripts + Power Automate; für plattformübergreifende Erweiterungen Office Add-ins; und wenn Excel ohnehin nicht mehr die Benutzeroberfläche ist, wird auf eine Windows- oder Webanwendung ausgelagert.⁴⁵⁶

Kurz gesagt: In der Praxis ist es sinnvoll, VBA nicht als „Technologie, die unmittelbar stirbt“, sondern als „Technologie mit klar definiertem Einsatzbereich“ zu betrachten.

2. Was ist VBA?

VBA steht für Visual Basic for Applications und ist eine Variante von Visual Basic, die mit Microsoft Office ausgeliefert wird. Auch in Microsofts offizieller Dokumentation wird es als ereignisgesteuerte Programmiersprache zur Erweiterung von Office-Anwendungen beschrieben.¹⁷

Wichtig ist hier: Es entspricht eher der Realität, VBA nicht als allgemeine Plattform für die Anwendungsentwicklung, sondern als Erweiterungssprache, die innerhalb von Office-Anwendungen eingesetzt wird, zu betrachten.

In Excel etwa arbeitet es nah an Objekten wie diesen.

• Workbook
• Worksheet
• Range
• Schaltflächen und Formulare
• Ereignisse beim Öffnen, Speichern der Arbeitsmappe und bei Zellenänderung

Mit anderen Worten: Die Stärke von VBA liegt darin, den Bildschirmen, Berichten und der Arbeitsmappenstruktur von Excel und Access sehr nahe zu sein. Ein Nutzer öffnet das Desktop-Office, klickt eine Schaltfläche, verarbeitet Daten aus lokalen Dateien oder Freigabeordnern und gibt direkt einen Bericht aus. Für diese Art von „Automatisierung, die direkt am Arbeitsplatz des Nutzers abgeschlossen wird“, besitzt VBA auch heute noch echte Stärken.¹

Der tatsächliche Code kann zum Beispiel so kurz sein. Das ist die kleinste Form, die man einer Schaltfläche auf einem Tabellenblatt zuweist.

' In einem Standardmodul von Excel ablegen. Für den Aufruf über eine Schaltfläche auf dem Tabellenblatt vorgesehen
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Einzelposten")

    If MsgBox("Die Zeilen ab Zeile 2 des Blatts 'Einzelposten' werden gelöscht. Sind Sie sicher?", _
              vbOKCancel + vbQuestion, "Bestätigung") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

Platziert man auf dem Blatt eine Form oder eine Formularsteuerelement-Schaltfläche und wählt per Rechtsklick über „Makro zuweisen“ dieses ClearMeisai aus, läuft dieser Vorgang bei jedem Klick ab. Beachtenswert ist hier, dass Excel-Objekte wie ThisWorkbook, Worksheets und Rows ohne Umwandlung oder API-Aufrufe unverändert erscheinen. Genau diese Nähe ist es, was mit „einer Sprache, die im Inneren von Office läuft“ konkret gemeint ist. Umgekehrt lässt sich in Migrationszielen, in denen diese Nähe verlorengeht, nicht mit demselben Aufwand schreiben.

Umgekehrt lag das eigentliche Einsatzgebiet von VBA von vornherein nicht bei Servern, Browsern, mobilen Geräten oder mandantenfähigen Websystemen.

3. Warum wird es auch heute noch verwendet?

Der Grund, warum VBA in der Praxis weiterhin bestehen bleibt, ist nicht einfach „es ist alt und bleibt aus Trägheit übrig“.

Zunächst neigen Excel und Access dazu, nicht nur Daten, sondern den Geschäftsablauf selbst aufzunehmen.

• Das Erscheinungsbild von Berichten
• Druckeinstellungen
• Eingabeprüfungen
• Die Reihenfolge der monatlichen Verarbeitung
• Abteilungsspezifische Ausnahmeregeln
• Bedienabläufe, an die sich die Praxis über Jahre gewöhnt hat

Das lässt sich beim Umzug in ein anderes System nicht allein mit „Code-Portierung“ erledigen. Weil Erscheinungsbild, Bedienung, Ausnahmen und Betrieb eine Einheit bilden, tragen VBA-Bestände mehr Spezifikation in sich, als es auf den ersten Blick scheint.

Außerdem ist VBA dem Objektmodell von Office so nahe, dass es für Anwendungsfälle, in denen das vor dem Nutzer liegende Excel selbst gesteuert und Ergebnisse zurückgegeben werden, mit wenig Aufwand auskommt. Diese Nähe ist auch bei der Betrachtung von Nachfolgekandidaten wichtig – einfach in eine neue Technologie umzuschreiben, ist damit nicht zwangsläufig erledigt.

In der Praxis ist folgende Betrachtungsweise naheliegend.

• Wenn Excel weiterhin die Benutzeroberfläche bleibt, lohnt es sich, VBA teilweise zu erhalten
• Wenn Excel nur noch für Ein- und Ausgabe gebraucht wird, lässt sich die dahinterliegende Logik leicht auslagern
• Wenn Excel selbst schon keine eigentliche Benutzeroberfläche mehr ist, wird es zum Kandidaten für einen Neuaufbau

4. Die wichtigsten Einschränkungen von VBA

4.1 Es setzt den Desktop voraus

Das ist die größte Einschränkung. VBA ist grundsätzlich eine Technologie, die innerhalb der Desktop-Version von Office läuft.

Auch laut Microsofts offiziellen Informationen gilt: In Excel for the web lässt sich VBA weder erstellen, ausführen noch bearbeiten; eine Arbeitsmappe mit Makros lässt sich zwar öffnen und bearbeiten, VBA jedoch nicht ausführen.²⁸

Damit passt es schon an dieser Stelle schlecht zu folgenden Anforderungen.

• Alles soll im Browser erledigt werden
• Dieselbe Erweiterung soll über Mac / iPad / Web hinweg nutzbar sein
• Administratoren wollen zentral verteilen
• Man will nicht von der lokalen Excel-Desktop-App abhängig sein

Microsoft selbst verweist in der VBA-Dokumentation darauf, dass man sich Office Add-ins ansehen sollte, wenn man Erweiterungen für mehrere Plattformen bauen möchte.⁹⁵

4.2 Erhebliche Reibung bei Sicherheit und Verteilung

Ein großer Teil des Grunds, warum leicht der Irrtum entsteht, VBA sei „nicht mehr nutzbar“, liegt tatsächlich in der Sicherheitsverschärfung.

Microsoft blockiert VBA-Makros in aus dem Internet stammenden Dateien standardmäßig. Öffnet man eine per E-Mail angehängte oder heruntergeladene .xlsm-Datei, läuft das Makro nicht mehr so ohne weiteres wie früher.³

Aus Sicherheitssicht ist das die richtige Richtung. Aus Sicht des Betriebs jedoch

• Bei Verteilung per Anhang funktioniert es nicht
• Eine von einer externen Website heruntergeladene Vorlage funktioniert nicht
• Die Handhabung über OneDrive / SharePoint / das Netzwerk ist schwer nachzuvollziehen
• Der Hinweis „Bitte aktivieren“ wird zur Schwachstelle im Betrieb

nimmt die Reibung zu.

Damit ist die Sache aber nicht erledigt, nur weil „es nicht läuft“. Microsoft stellt in demselben Dokument auch Mittel zusammen, um Makros vertrauenswürdiger Dateien auszuführen. Im Betrieb werden vor allem die folgenden vier genutzt.³

Gleichzeitig sind auch die Vorbehalte klar benannt.³

• Vertrauenswürdige Speicherorte und vertrauenswürdige Sites vertrauen allem, was dort abgelegt wird, vollständig. Sie müssen auf Orte beschränkt bleiben, bei denen sich steuern lässt, wer dort schreiben darf.
• Vertrauenswürdige Herausgeber sind eine Windows-weite Einstellung, keine reine Office-Angelegenheit.
• Bei Excel-Add-ins (.xla / .xlam) funktioniert es auch mit Signatur und vertrauenswürdigem Herausgeber nicht, wenn Mark of the Web gesetzt ist. In diesem Fall bleibt nur, Mark of the Web zu entfernen oder die Datei an einem vertrauenswürdigen Speicherort abzulegen.
• Wird eine Netzwerkfreigabe per IP-Adresse geöffnet, zählt das allein schon weder als vertrauenswürdige Site noch als lokales Intranet, sodass es blockiert werden kann.

Mit anderen Worten: Wer sich für den Erhalt von VBA entscheidet, muss unabhängig vom Code auch festlegen, wo die Datei liegt und wie Vertrauen hergestellt wird – als Teil des Verteilungsdesigns. Ein Betrieb, der .xlsm-Dateien weiterhin per E-Mail-Anhang verteilt, ohne dies festzulegen, erzeugt die größte Reibung.

Das Problem von VBA liegt also nicht nur in „Sprachfunktionen“, sondern ebenso im Design von Verteilung und Vertrauen.

4.3 Die 32-Bit-/64-Bit-Hürde

Office gibt es in einer 32-Bit- und einer 64-Bit-Version, und bei Office 2019 sowie Microsoft 365 ist 64-Bit die Standardeinstellung.⁷

Deshalb kann alter VBA-Code, insbesondere solcher, der Windows-APIs über Declare aufruft, in einer 64-Bit-Umgebung nicht unverändert funktionieren. Auch Microsoft weist darauf hin, dass die Unterschiede zwischen 32-Bit und 64-Bit mithilfe von PtrSafe, LongPtr, LongLong und Ähnlichem ausgeglichen werden müssen.⁷

Schwierig ist hier, dass nicht nur der Code selbst, sondern auch diese Abhängigkeiten leicht gemeinsam zum Problem werden.

• Alte COM-/ActiveX-/OCX-Komponenten
• Externe DLLs, die 32-Bit voraussetzen
• Komponenten, die eine Registrierungseintragung voraussetzen
• Abweichende Verweise (Referenzen) in Office

Eine VBA-Migration wird also sehr häufig weniger zu einem Umschreiben der Sprache als vielmehr zu einer Bereinigung der Office-Bitness und externer Abhängigkeiten.

4.4 Ungeeignet für unbeaufsichtigte und serverseitige Ausführung

Das ist ein ziemlich wichtiger Punkt. Microsoft erklärt ausdrücklich, dass die serverseitige Automatisierung von Office-Anwendungen weder empfohlen noch unterstützt wird. Office ist für einen interaktiven Desktop mit Benutzerprofil ausgelegt, und in unbeaufsichtigten Umgebungen kann es zu Instabilität oder Deadlocks kommen.⁶

Deshalb tendieren folgende Konfigurationen zum Risiko.

• Excel aus einem Windows-Dienst heraus starten
• Office aus ASP.NET oder DCOM heraus automatisieren
• Ein unsichtbares Excel dauerhaft über die Aufgabenplanung laufen lassen
• Die Berichtserzeugung vollständig einem Excel auf dem Server überlassen

Es kommt vor, dass es „gelegentlich funktioniert“. Aber dass etwas funktioniert und dass es eine tragfähige Konfiguration ist, sind zwei verschiedene Dinge.

Wird unbeaufsichtigte Ausführung benötigt, sollte zuerst nicht VBA in Frage gestellt werden, sondern die Konfiguration, die die Excel-Anwendung selbst betreibt.

4.5 Nachteile bei Wartbarkeit, Testbarkeit und Diff-Verwaltung

Bei VBA neigt der Code dazu, in der Arbeitsmappe oder der Access-Datei eingeschlossen zu bleiben. Dadurch treten leicht folgende Probleme auf.

• Es wird unklar, welche Datei die maßgebliche Version ist
• Zuständigkeiten verteilen sich über Formulare, Tabellenblätter und Standardmodule
• Verweise und ActiveX-Abhängigkeiten weichen je nach Umgebung voneinander ab
• Codeüberprüfung und Diff-Vergleiche sind schwer durchführbar
• Unit-Tests lassen sich nur schwer erstellen
• Die Zelladressen von Excel selbst werden faktisch zur Spezifikation

Das ist nicht allein ein Problem der Sprache VBA, sondern ein strukturelles Problem, das darin liegt, Fachlogik innerhalb einer Office-Datei zu halten. Bei kleiner Automatisierung mag das kein großes Problem sein, aber sobald daraus ein Geschäftssystem wird, macht es sich plötzlich bemerkbar.

4.6 Bei VBScript-Abhängigkeiten ist gesonderte Vorsicht geboten

2025 wurde im Microsoft 365 Developer Blog angekündigt, dass die schrittweise Abschaffung von VBScript unter Windows sich auch auf VBA-Projekte auswirken kann. Insbesondere Fälle, die eine externe .vbs-Datei ausführen, und Fälle, die von der Referenz VBScript.RegExp abhängen, sind davon betroffen.¹⁰

Gleichzeitig reagiert Microsoft auch, indem es ab Microsoft 365 Version 2508 (Build 19127.20154) in Office für Windows die RegExp-Klasse standardmäßig in VBA einschließt.¹⁰

Ob die eigenen Bestände betroffen sind, lässt sich anhand der folgenden drei Punkte feststellen. Dazu eignet sich sowohl die Suche im „Bearbeiten“-Menü des VBE als auch ein Grep über als .bas / .cls exportierten Text.

Die Liste der Verweise lässt sich im VBE über das Menü „Extras“ unter „Verweise“ einsehen.

Was RegExp betrifft, ist wie erwähnt bereits eine Abhilfe im Gange, indem ab Microsoft 365 Version 2508 (Build 19127.20154) in Office für Windows die RegExp-Klasse standardmäßig auf der VBA-Seite enthalten ist.¹⁰ Schwerer wiegt das Muster in Zeile drei, „eine externe .vbs-Datei wird ausgeführt“ – hier muss erwogen werden, die Verarbeitung selbst auf die VBA-Seite oder eine andere Ausführungsplattform zu verlagern. Wer beim Erstellen des Bestandsverzeichnisses (8.1) diese drei Punkte gleich mit erfasst, erspart sich doppelte Arbeit.

Wichtig ist hier: Die Abschaffung von VBScript und die Abschaffung von VBA sind nicht dasselbe Thema. Es geht nicht darum, dass VBA selbst verschwindet, sondern richtiger verstanden darum, dass einige an VBA hängende externe Abhängigkeiten überprüft werden müssen.

5. Wird VBA künftig nicht mehr nutzbar sein?

Zunächst: Es geht nicht darum, dass ab morgen alles nicht mehr funktioniert. Es ist aber auch nicht mehr die Ära, in der „überall für alles“ einsetzbar ist.

Liest man Microsofts offizielle Informationen, zeichnet sich mindestens folgende Richtung deutlich ab.

• VBA als Erweiterung des Desktop-Office besteht weiterhin¹
• Auf der Web-/plattformübergreifenden Seite werden Office Scripts und Office Add-ins je nach Bedarf eingesetzt⁴⁵⁹
• Die Sicherheit der Makroverteilung wird strenger gehandhabt als früher³
• Randkomponenten wie VBScript-Abhängigkeiten können künftig betroffen sein¹⁰

Darüber hinaus stellt Microsoft zu Office Scripts ausdrücklich klar, dass VBA desktopzentriert ist, während Office Scripts für sichere, plattformübergreifende, cloudbasierte Lösungen gedacht ist. Gleichzeitig erklärt Microsoft, dass die Abdeckung der in der Desktop-Anwendung nutzbaren Excel-Funktionen derzeit bei VBA breiter ist.⁴

Stellt man diese beiden Aussagen nebeneinander, ergibt sich ein durchaus praxisnahes Bild.

• Für tiefgehende Eingriffe im Desktop-Excel ist die Reichweite von VBA nach wie vor größer
• Für Browser / M365 / gemeinsam genutzte Workflows sind Office Scripts oder Add-ins die natürlichere Wahl
• Daher gilt weder „alles auf Office Scripts umstellen“ noch „VBA für immer ins Zentrum stellen“

Es liegt nahe, die Zukunft von VBA eher als Klärung von Grenzen denn als Verschwinden zu betrachten.

6. Fälle, in denen ein Ersatz sinnvoll ist / Fälle, in denen kein Ersatz nötig ist

Zunächst eine grobe, aber nützliche Entscheidungstabelle.

Der in der zweiten Tabellenzeile genannte Hybrid-Ansatz ist in diesem Artikel im Sinne von „Excel / Access bleibt als Einstiegspunkt für Benutzeroberfläche und Berichte erhalten, während nur Fachlogik und I/O in eine externe Ausführungseinheit ausgelagert werden“ gemeint. Der Unterschied zu einer vollständigen Ablösung liegt darin, dass sich der für den Nutzer sichtbare Bildschirm und die Bedienung nicht ändern. Die konkrete Form wird in 7.1 behandelt.

Wichtig an dieser Tabelle ist, dass die Entscheidungsachse für einen Ersatz nicht „VBA ist alt“ lautet. Worauf es wirklich ankommt, sind Ausführungsumgebung, Betrieb, Verteilung, Abhängigkeiten, Auditierung und Erweiterbarkeit.

7. Realistische Migrationsziele

Bevor wir ins Detail gehen, stellen wir die Kandidaten zunächst in einer Übersicht zusammen. Nutzen Sie sie in dieser Reihenfolge: Erst mit der Entscheidungstabelle aus Kapitel 6 festlegen, „wohin es tendiert“, dann mit dieser Tabelle prüfen, „was das Ziel im Anschluss voraussetzt“.

Am leichtesten übersehen wird die Spalte „Voraussetzungen / Lizenzierung“. Da die Bedingungen besonders bei Office Scripts klar definiert sind, ordnen wir sie in 7.3 gesondert ein.

7.1 Excel beibehalten und nur den Inhalt nach .NET oder in einen separaten Prozess auslagern

Das ist die realistischste und am wenigsten fehleranfällige Option.

• Bildschirm und Berichte bleiben weiterhin über Excel / Access zugänglich
• Schaltflächen und Eingabeformulare bleiben vorerst ebenfalls unverändert
• Fachlogik, HTTP, Kryptografie, CSV / JSON, aufwendige Berechnungen und Dateiverarbeitung werden jedoch ausgelagert
• VBA wird auf „Vermittlung“ und „UI-Bedienung“ reduziert

Der Vorteil dieser Konfiguration liegt darin, dass sie das Erscheinungsbild und die Bedienung für den Nutzer kaum beeinträchtigt. Statt einer vollständigen Ablösung kann man zunächst in Richtung Verschlankung der Zuständigkeiten vorgehen.

Verwandter Artikel:

• .NET 8-DLL typisiert aus VBA verwenden - COM-Freigabe und dscom-TLB

„Bevor man alles neu schreibt, zunächst nur die schweren Teile auslagern“ ist ein sehr praxisnaher Ansatz.

7.2 Für unbeaufsichtigte Ausführung und Berichtserzeugung auf direkte Dateierzeugung statt Office-App-Automatisierung setzen

Wer Excel-Berichte in einem Nachtjob oder Dienst in großer Zahl erzeugen möchte, sollte zunächst nicht in Frage stellen, „ob VBA veraltet ist“, sondern die Tatsache, dass überhaupt die Excel-Anwendung gestartet wird.

Microsoft empfiehlt keine serverseitige Office Automation. Stattdessen wird empfohlen, Office-Dateien direkt zu bearbeiten, etwa im Open-XML-Format.⁶

Lauten die Anforderungen also

• Eine .xlsx-Datei soll erzeugt werden
• Standardisierte Berichte sollen in großer Zahl ausgegeben werden
• Es soll in PDF umgewandelt werden
• Es soll in einem Nachtjob laufen

so ist die zu wählende Achse nicht „Excel steuern“, sondern „Excel-Dateien zusammensetzen“.

Verwandter Artikel:

• Excel-Berichtsausgabe erstellen - COM/Open XML/Vorlagen

7.3 Für Geschäftsprozesse auf Microsoft 365: Office Scripts + Power Automate

Wenn das Geschäft bereits stark auf OneDrive / SharePoint / Teams / Outlook / Forms setzt, ist Office Scripts ein ernstzunehmender Kandidat.

Microsoft beschreibt Office Scripts als für sichere, plattformübergreifende, cloudbasierte Lösungen gedacht. In Kombination mit Power Automate lässt sich die Excel-Verarbeitung zudem durch E-Mails, Formulare oder Zeitpläne als Auslöser automatisieren.⁴¹¹

Vorher müssen jedoch die Nutzungsbedingungen geprüft werden. Da es sich hierbei um Kosten und Umgebungsvoraussetzungen selbst handelt, wirkt sich das später zwangsläufig aus.¹²¹³

Office Scripts ist also nicht „ein kostenloser Ersatz für VBA“. Im Vergleich zu einem Betrieb, bei dem lokale .xlsm-Dateien verteilt wurden, kommen die Voraussetzungen OneDrive / SharePoint und eine M365-Lizenz zusätzlich hinzu. Wird das übersehen und einfach „Migration auf Office Scripts“ beschlossen, landet man mitten in der Migration wieder bei der Frage der Lizenzbeschaffung.

Darüber hinaus ist es auch funktional nicht allmächtig.

• Office Scripts unterstützt keine Excel-Ereignisse
• Die Ausführung erfolgt im Grundsatz manuell oder durch Aufruf aus Power Automate⁴
• Die Power-Automate-Integration erfordert eine Microsoft 365 Business-Lizenz¹¹
• Die Aktion Run script unterliegt Einschränkungen wie 1.600 Aufrufen pro Nutzer und Tag und 120 Sekunden für synchrone Verarbeitung¹²

Office Scripts lässt sich also treffender als Automatisierungsbaustein innerhalb von M365 verstehen denn als „Ersatz für VBA“.

7.4 Für plattformübergreifende Erweiterungen: Office Add-ins

Wer Word, Excel, Outlook und Ähnliches über Windows / Mac / iPad / Browser hinweg erweitern möchte, für den sind Office Add-ins der erste Kandidat.

Auch in Microsofts offizieller Dokumentation wird erklärt, dass sich Office Add-ins mit HTML / CSS / JavaScript erstellen lassen, auf mehreren Plattformen laufen und sich auch für die zentrale Verteilung eignen.⁵

Das eignet sich zum Beispiel für folgende Anforderungen.

• Office soll mit dem internen Portal oder dem Kernsystem verbunden werden
• Dieselbe Benutzeroberfläche und dieselben Befehle sollen in Outlook / Excel / Word erscheinen
• Statt einer Makroverteilung pro Nutzer-PC soll administratorseitig verteilt werden
• Man möchte sich vom lokalen .xlsm-Verteilungsmodell lösen

Da sich das Spielfeld von VBA unterscheidet, fühlt es sich deutlich anders an als Code innerhalb von Excel zu schreiben. Im Gegenzug lassen sich Betrieb und Verteilung leichter ordnen.

7.5 Wenn Excel / Access selbst keine eigentliche Benutzeroberfläche mehr ist: Auslagerung auf eine Windows- oder Webanwendung

Ist dieser Zustand erst einmal erreicht, ist es naheliegender, als Anwendung neu zu bauen, statt VBA künstlich am Leben zu erhalten.

• Bildschirmübergänge und Berechtigungssteuerung sind zu umfangreich geworden
• Datenbank, Audit-Protokolle, Genehmigungsabläufe und Benutzerverwaltung stehen im Mittelpunkt
• Es gibt eine Anbindung an externe Geräte oder lang laufende Verarbeitungen
• Excel-Zellen und -Formulare sind faktisch zum Fachspezifikationsdokument geworden
• Schon die Tatsache, dass die Zustandsverwaltung beim Schließen der Arbeitsmappe verschwindet, wird zur Belastung

In diesem Fall lässt sich die Struktur bei einem auf Windows ausgelegten Fachwerkzeug eher mit einer C#-/.NET-Desktopanwendung sauber gestalten, und bei einem breiten Nutzer- oder Gerätekreis eher mit einer Webanwendung.

8. Vorgehen bei der schrittweisen Migration

Das Gefährlichste beim Ersatz von VBA ist der Versuch, von Anfang an alles auf eine einzige neue Technologie zu bündeln. In der Praxis ist es meist sicherer, die im Folgenden beschriebenen Stufen der Reihe nach zu durchlaufen.

8.1 Zunächst ein Bestandsverzeichnis erstellen

Was zuerst erfasst werden sollte, ist weniger der Codeumfang selbst als vielmehr die Abhängigkeiten.

• Welche .xlsm-/.xlam-/.accdb-/.mdb-Dateien existieren
• Welche davon der Einstiegspunkt für den tatsächlichen Betrieb sind
• Was in den Verweisen enthalten ist
• Welche Declare-Anweisungen, externen DLLs, COM-/ActiveX-/OCX-Komponenten es gibt
• Wie es um die 32-Bit-/64-Bit-Voraussetzungen steht
• Welches Makro von wem in welchem Ablauf genutzt wird
• Was die Ausgaben sind (Excel, CSV, PDF, Druck, E-Mail-Versand usw.)

Wird hier unklar geblieben und trotzdem ersetzt, entstehen später Vorfälle wie „ein Makro, von dem alle dachten, es rühre niemand mehr an, war nur am Monatsende noch aktiv“.

8.2 Den Code nach Zuständigkeiten aufteilen

Der nächste Schritt ist die Aufteilung nicht nach Datei, sondern nach Zuständigkeit.

• Bedienung der Excel-/Access-Benutzeroberfläche
• Ein-/Ausgabe der Tabellenblätter
• Berichtslayout
• Geschäftsregeln
• Externe API-/Datei-/Datenbank-I/O
• Batchverarbeitung
• Druck / Verteilung

Mit dieser Aufteilung wird leichter erkennbar, was erhalten bleibt, was verschlankt und was ausgelagert wird.

8.3 Migrationsziele je Zuständigkeit festlegen

Eine leicht zu empfehlende Aufteilung sieht so aus.

• UI und Tabellenblattbedienung: vorerst in VBA belassen
• Fachlogik: nach .NET-DLL, einen separaten Prozess oder einen Dienst auslagern
• Unbeaufsichtigte Berichtserzeugung: auf Open XML oder direkte Erzeugung setzen
• M365-Workflows: Office Scripts + Power Automate
• Plattformübergreifende UI: Office Add-ins
• Zu Geschäftssystemen gewordene Bereiche: in Windows-/Webanwendungen trennen

Wichtig ist, das Migrationsziel nicht auf eines zu vereinheitlichen. Der Inhalt von VBA-Beständen besteht meist aus einer Mischung mehrerer Zuständigkeiten.

8.4 Zuerst die Schnittstellen festlegen

Bevor die Migration beginnt, sollte mindestens Folgendes festgelegt werden.

• Was die Eingaben sind
• Was die Ausgaben sind
• Wie im Fehlerfall reagiert wird
• Welche Tabellenblätter, benannten Bereiche und Dateipfade als Vertrag gelten
• Ab welchem Zeitpunkt das Ergebnis als endgültig gilt

Wird hier ohne Festlegung fortgefahren, wird die Zelladresse selbst zur API, und das System wird anfällig.

8.5 Im Parallelbetrieb vergleichen

Besonders bei Berichten und Auswertungen ist es sicherer, nicht abrupt umzuschalten.

• Die alte VBA-Version und die neue Implementierung parallel ausgeben lassen
• Die erzeugten .xlsx-/CSV-/PDF-Dateien vergleichen
• Unterschiede bei Datum, Rundung, Formatierung und Druckbereich prüfen
• Auch Ausnahmefälle und leere Datensätze testen

Vorfälle beim VBA-Ersatz entstehen meist nicht dadurch, „ob es läuft“, sondern dadurch, dass Zahlen oder Formatierungen sich still verschieben.

9. Häufige Fehler

9.1 Mit „VBA ist alt, also alles auf Office Scripts“ beginnen

Office Scripts ist eine starke Option, doch Microsoft selbst erklärt, dass VBA eine breitere Abdeckung der Desktop-Excel-Funktionen bietet. Zudem unterstützt Office Scripts keine Excel-Ereignisse.⁴

Der Gedanke, Makros mit tiefer Abhängigkeit vom Desktop-Excel unverändert eins zu eins zu übertragen, ist daher riskant.

9.2 Trotz unbeaufsichtigter Ausführung weiterhin Excel selbst starten

Das kommt ziemlich häufig vor. Solange es funktioniert, wirkt es praktisch, doch Microsoft empfiehlt die serverseitige Automatisierung von Office nicht.⁶

Bei einem Nachtjob oder einem Dienst ist es sicherer, sich nicht auf das Steuern von Excel, sondern auf das Zusammensetzen von Excel-Dateien zu verlegen.

9.3 Bildschirm, Berichte und Geschäftsregeln gleichzeitig komplett ändern

Was beim VBA-Ersatz wirklich gefährlich ist, ist nicht die Codeumwandlung selbst, sondern das Verlieren von Fachvorgaben. In Excel-Tabellenblättern und Access-Formularen stecken erhebliche Betriebsregeln, die nirgendwo im Code stehen.

Ändert man alles auf einmal, entstehen leicht Vorfälle wie „sieht ähnlich aus, weicht aber nur am Monatsende ab“.

9.4 32-Bit/64-Bit und externe Verweise aufschieben

Bei Migrationsprojekten explodieren häufig eher folgende Punkte als der VBA-Code selbst:

• Declare
• Externe DLLs
• COM / ActiveX / OCX
• Office-Bitness
• Verweise

Werden diese Punkte nach hinten geschoben, wird es gegen Ende der Implementierung auf einen Schlag mühsam.⁷

9.5 Die VBScript-Geschichte mit der VBA-Geschichte verwechseln

Aus Sicht von VBA ist die schrittweise Abschaffung von VBScript eine Angelegenheit der Überprüfung einiger Abhängigkeiten. Das bedeutet nicht dasselbe wie das Ende von VBA insgesamt.¹⁰

Vermischt man das, verselbstständigt sich leicht nur das ungenaue interne Gerücht „VBA soll wohl enden“.

10. Zusammenfassung

Kurz gesagt ist VBA eine Erweiterungssprache, die eng an Office-Desktopanwendungen gebunden ist. Um Arbeit direkt am Arbeitsplatz des Nutzers, nah an Excel und Access, zu automatisieren, ist es auch heute noch durchaus praxistauglich.¹

Wichtig für die Praxis der Zukunft ist jedoch, VBA nicht als allmächtige Zentraltechnologie zu behandeln.

• Wer Browser / Plattformübergreifendes möchte, schaut sich Office Scripts und Office Add-ins an⁴⁵
• Bei unbeaufsichtigter Ausführung / serverseitiger Verarbeitung wird Office Automation vermieden⁶
• Schwere Logik und externe Anbindungen werden nach .NET oder in einen separaten Prozess ausgelagert
• Wenn Excel / Access als Benutzeroberfläche schon an seine Grenzen stößt, wird auf eine Windows- oder Webanwendung ausgelagert

Die Antwort lautet weder „alles ersetzen“ noch „nichts ändern“, sondern „nach Zuständigkeit aufteilen und schrittweise verschlanken“.

Oberflächlich betrachtet wirken VBA-Bestände alt. In der Praxis stecken darin jedoch reichlich Fachvorgaben, Betriebsabläufe, Berichtsdesign und die Routine der Praxis.

Genau deshalb ist es am sichersten, den Ersatz nicht als Übersetzung, sondern als Neuordnung anzugehen.

11. Verwandte Artikel

• Was sind COM / ActiveX / OCX? – Unterschiede und Zusammenhänge im Überblick
• .NET 8-DLL typisiert aus VBA verwenden - COM-Freigabe und dscom-TLB
• Excel-Berichtsausgabe erstellen - COM/Open XML/Vorlagen

12. Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wird VBA künftig nicht mehr nutzbar sein?

Mindestens Stand März 2026 lässt sich aus Microsofts offiziellen Informationen keine klare Ankündigung erkennen, dass VBA selbst in absehbarer Zeit eingestellt wird. Was gerade passiert, ist kein plötzliches vollständiges Ende, sondern eine Klärung darüber, wo VBA einsetzbar ist und unter welchen Voraussetzungen. Konkret lässt sich VBA in Excel for the web weder erstellen, ausführen noch bearbeiten, und Makros in aus dem Internet stammenden Dateien werden standardmäßig blockiert. Die Zukunft von VBA ist eher als Klärung von Grenzen zu verstehen denn als Verschwinden.

Sollte man alles auf Office Scripts migrieren?

Das ist nicht zu empfehlen. Microsoft selbst erklärt, dass die Abdeckung der in der Desktop-Anwendung nutzbaren Excel-Funktionen derzeit bei VBA breiter ist, und Office Scripts unterstützt keine Excel-Ereignisse. Office Scripts ist weniger ein Ersatz für VBA als vielmehr ein Automatisierungsbaustein innerhalb von M365, der Arbeitsmappen auf OneDrive oder SharePoint zusammen mit Power Automate steuert. Das Migrationsziel sollte realistischerweise je nach Zuständigkeit unterschiedlich gewählt werden.

Darf man Excel-Makros unbeaufsichtigt auf einem Server oder in einem Nachtjob ausführen?

Das ist riskant. Microsoft erklärt ausdrücklich, dass serverseitige Automatisierung von Office-Anwendungen nicht empfohlen und nicht unterstützt wird. Office ist für einen interaktiven Desktop mit Benutzerprofil ausgelegt, und in unbeaufsichtigten Umgebungen kann es zu Instabilität oder Deadlocks kommen. Wenn die Anforderung die massenhafte Erzeugung von Berichten ist, wird empfohlen, Excel-Dateien direkt zu erstellen, etwa im Open-XML-Format, statt die Excel-Anwendung zu starten.

Wie sollten bestehende VBA-Bestände migriert werden?

Es ist sicherer, nicht von Anfang an alles auf eine einzige neue Technologie zu bündeln, sondern schrittweise zu migrieren. Zunächst wird ein Bestandsverzeichnis erstellt (`.xlsm`, Verweise, externe DLLs, 32-Bit-/64-Bit-Voraussetzungen), und der Code wird nach Zuständigkeiten wie UI-Bedienung, Fachlogik, Berichte und I/O aufgeteilt. Anschließend bleiben UI und Tabellenblattbedienung vorerst in VBA, die Fachlogik wandert in eine .NET-DLL oder einen separaten Prozess, die unbeaufsichtigte Berichtserzeugung nach Open XML, und M365-Workflows nach Office Scripts – je nach Zuständigkeit wird das Migrationsziel festgelegt. Bei Berichten und Auswertungen sollten alter und neuer Stand parallel betrieben und die Ausgaben verglichen werden, bevor umgeschaltet wird.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.