This is the question that stops more migrations than any other. You have thousands of lines of VBA code. It runs your business logic, generates reports, sends emails, validates data, and automates workflows. The thought of rewriting all of it is paralyzing.

The answer depends entirely on which migration path you choose. Here is what happens to your VBA in each scenario.

Scenario 1: Keep Access Front-End, Move Data to a Server

This is the least disruptive option. Your VBA code stays exactly where it is — in the Access .accdb front-end file. It continues to run in the Access VBA environment.

What works without changes: - Form event code (OnOpen, OnCurrent, BeforeUpdate, AfterUpdate) - Navigation code (DoCmd.OpenForm, DoCmd.OpenReport) - UI logic (enabling/disabling controls, showing/hiding sections) - MsgBox prompts and InputBox calls - File operations (reading/writing text files, copying files) - Email automation through Outlook - Most DAO recordset operations

What needs changes: - SQL strings with Access-specific syntax. If your VBA builds SQL strings using IIf(), Nz(), * wildcards, or # date delimiters, these need to be translated to the target database’s dialect when used in pass-through queries. - Recordset operations on identity columns. Code that reads an AutoNumber immediately after AddNew needs to use the server’s mechanism instead (SCOPE_IDENTITY() for SQL Server). - DLookup, DCount, DSum on linked tables. These still work but execute as separate ODBC round trips. They become noticeably slower. Replace with queries that retrieve all needed values at once. - DoCmd.RunSQL with action queries. If the SQL contains Access-specific functions, it may fail. Consider converting to pass-through queries.

Estimated effort: 5-15% of VBA code needs modification, mostly search-and-replace style changes.

Scenario 2: Rebuild as a Python Desktop Application

If you rebuild using Python with a GUI framework like PySide6 or tkinter, your VBA code does not transfer. Python is a completely different language. However, the logic translates well because both languages are procedural and the concepts are similar.

What translates conceptually: - Business logic (calculations, validations, conditional processing) - Database operations (VBA DAO/ADO becomes Python’s SQLAlchemy or pyodbc) - File operations (VBA FileSystemObject becomes Python’s os and pathlib) - String manipulation (similar built-in functions)

What does not translate: - Form event handlers — you write new ones in the Python GUI framework - DoCmd operations — replaced by the GUI framework’s navigation methods - Access-specific objects (CurrentDb, DoCmd, Screen, Application) - Outlook automation through COM — replaced by Python’s smtplib or win32com

Common VBA to Python translations:

VBA Python
Dim x As String x = "" or x: str = ""
If...Then...Else...End If if...elif...else:
For Each item In collection for item in collection:
Do While...Loop while condition:
MsgBox "Hello" QMessageBox.information(...)
CurrentDb.OpenRecordset(sql) cursor.execute(sql)
rs.MoveNext row = cursor.fetchone()
IsNull(x) x is None
Nz(x, "") x or "" or x if x else ""

Estimated effort: 100% rewrite, but the logic maps closely. A function that took 50 lines in VBA typically takes 20-30 lines in Python.

Scenario 3: Rebuild as a Web Application

This is the most significant departure from VBA. In a web application, your code splits into two pieces:

Your VBA code maps primarily to the server-side component. The form interaction code maps to the client-side component.

What maps to server-side code: - Database queries and updates - Business logic and calculations - Data validation rules - Report generation - Email sending

What maps to client-side code: - Field validation on forms - Show/hide controls based on field values - Dynamic form behavior - User interface navigation

What has no direct equivalent: - Direct file system access (web apps cannot access the user’s file system directly) - Outlook automation (web apps send email through server-side code) - Direct printer access (web apps generate PDFs or use the browser’s print function) - Shell commands and external application launching

Estimated effort: 100% rewrite, and the architecture is fundamentally different. This is not a translation exercise — it is a redesign.

Scenario 4: Move to Power Platform

Microsoft positions Power Apps, Power Automate, and Dataverse as the successor to Access. Your VBA code is replaced by:

Power Apps uses a formula language that is closer to Excel formulas than to VBA. It is less powerful for complex logic but handles common scenarios with less code.

What translates well: - Simple field validations - Conditional visibility (showing/hiding fields) - Basic calculations - Simple data filtering

What does not translate well: - Complex business logic with multiple conditions and loops - String manipulation and parsing - File processing - Custom report generation - Anything requiring fine-grained control

Estimated effort: Varies widely. Simple applications translate quickly. Complex applications with heavy VBA may require custom code using Azure Functions or other back-end services, which defeats much of the simplicity argument.

How to Inventory Your VBA Code

Before choosing a migration path, understand what you have. Open the VBA editor (Alt+F11 in Access) and catalog:

  1. Count the modules. How many code modules, form modules, and report modules contain code?
  2. Count the lines. A rough line count tells you the scale. Under 500 lines is small. 500-2000 is moderate. Over 2000 is significant.
  3. Identify external dependencies. Does your code interact with Outlook? Excel? The file system? External APIs? Each dependency needs a replacement strategy.
  4. Find the business logic. Which functions implement business rules (pricing calculations, commission formulas, approval workflows)? These are the most critical to preserve.
  5. Identify the throw-away code. Navigation code, form formatting, and simple event handlers are rewritten in any migration. Do not count these as complexity — they are boilerplate.

The Practical Answer

For most organizations, the right answer is Scenario 1 — keep the Access front-end and move the data. Your VBA code stays, the modifications are minimal, and you eliminate the database problems that drove the migration.

If and when you decide to rebuild the application (Scenarios 2, 3, or 4), you can do it at your own pace, with the data already safely in a server database. The VBA rewrite happens as part of a deliberate application modernization, not as an emergency forced by a failing database.

The worst approach is letting VBA anxiety prevent you from migrating the data. Your code is not trapped in Access. Your data is.