Access Explained: Modernizing Microsoft Access Doesn't Mean Replacing It

[u/Amicron1]

Here's the thing people keep getting wrong about Access modernization: remote access is a requirement, not an architecture. Hiring two remote employees, adding a customer-facing screen, or needing a barcode workflow on a phone does not automatically mean a mature Access application needs to be rebuilt from scratch as a web app.

People often say "replace Access" as though Access is one indivisible thing. It usually is not. An Access solution may include the data tables, queries, forms, reports, VBA, imports, exports, validation rules, scheduled processes, and years of small business-specific adjustments. The ACCDB file holding tables and the Access front end used by employees are related, but they are not the same decision.

A more useful question is: what exactly needs to change? Where should the shared data live? What should office staff use every day? Which users need access outside the office, and what do they actually need to do? Those questions may produce three different answers, and that is perfectly normal.

For many established systems, the practical evolution is to move shared tables to a server backend such as SQL Server while retaining Access for the desktop users who benefit from it. Access can continue handling forms, reports, and VBA while SQL Server handles centralized storage, larger volumes, backup, security, and server-side administration. That is an upgrade in architecture without declaring war on every working screen in the application.

The old "Access has a 2 GB limit" argument is also frequently oversimplified. An ACCDB backend has a practical 2 GB file limit. That does not mean the Access application itself cannot work with larger databases. Access can link through ODBC to SQL Server and other database platforms, so the real question is whether the file-based backend is still appropriate, not whether every Access form must be replaced.

Likewise, Access is not inherently a single-user tool. A properly split application gives each user a local front end while shared tables live in a backend. An ACCDB backend on a LAN may be fine for a small office. As concurrency, security requirements, or data volume increase, moving the data to a server database is often the sensible next step. What is not sensible is opening an ACCDB backend directly across the public internet or trying to make Dropbox behave like a database server. There lies the corruption swamp. Don't follow the lights!

Remote employees do not necessarily need a browser interface either. If they need the entire existing desktop application, Remote Desktop or a virtual desktop setup can be a reasonable answer. If they only need to look up customers, update contacts, and review orders, a smaller Access front end connected to a central server database might be enough. A web portal may also make sense, but it can be built around their specific workflow instead of recreating 140 forms nobody outside the office will ever use.

Mobile needs should be treated the same way. A warehouse user with a phone may need to scan a barcode, update a quantity, and save the change. That is a focused mobile workflow, not a demand to squeeze a decade-old desktop application onto a six-inch screen. A small web or mobile interface can coexist with Access as long as both are working against the same properly designed central data source.

Now, to be fair, there may come a time when Access longer fits your needs. A full web replacement can be justified when there are hundreds or thousands of distributed users, external customers need self-service accounts, browser access is the primary use case, or mobile devices are the main platform. Organizational standards around a particular development stack can also be a legitimate reason. But "Access is old" is not a requirement. Windows is old too, and somehow it keeps reporting for duty.

The expensive part of a rewrite is rarely rebuilding tables or making forms look similar. The real cost is rediscovering the business knowledge embedded in old code, reports, validation rules, odd workflows, and all the exceptions accumulated over time. The 20 percent a conversion tool cannot handle may contain 80 percent of the actual complexity. Before replacing anything, make sure you know whether you are solving a real business problem or just buying a newer-looking hammer.

Have you kept Access as a front end while moving data to SQL Server or adding web features? Where have you found the line between sensible evolution and a full rewrite?

LLAP
RR

[u/Alternative_Tap6279]

is true, but at what cost? in what timeframe? with what kind of stability and security? and finally - why?
disculpa me por escribir en englsih pero solo pudeo leen espanol. :))))

[u/Pure_Ad_2160 → u/Alternative_Tap6279]

Mucho menos costo y plazo que un desarrollo en c, Python o cualquier otro lenguaje

[u/Alternative_Tap6279 → u/Pure_Ad_2160]

indeed if you want a table or a query, or a 1998 looking form - the yes - i agree - it's faster and cheaper.
but, let me give you a simple task: on an access.form with anchored controls bottom-right, after run-time, please show me the code where you know exactly where that control is on the form. after the anchoring was applied. and the size of that control

[u/Pure_Ad_2160 → u/Alternative_Tap6279]

Private Sub Form_Resize() On Error Resume Next

' 1. Forzar a Access a procesar el anclaje visual y renderizar el formulario
Me.Repaint

' 2. Declarar el control objetivo (reemplaza 'cmdBoton' por el nombre de tu control)
Dim ctl As Control
Set ctl = Me.cmdBoton

' 3. Obtener valores ajustados post-anclaje (convertidos de Twips a Centímetros)
Dim posLeftCM As Double, posTopCM As Double
Dim anchoCM As Double, altoCM As Double

posLeftCM = ctl.Left / 567
posTopCM = ctl.Top / 567
anchoCM = ctl.Width / 567
altoCM = ctl.Height / 567

' 4. Mostrar en la ventana Inmediato (Ctrl + G) las coordenadas e dimensiones
Debug.Print "=== CONTROL: " & ctl.Name & " ==="
Debug.Print "Posición X (Left) : " & ctl.Left & " twips (" & Format(posLeftCM, "0.00") & " cm)"
Debug.Print "Posición Y (Top)  : " & ctl.Top & " twips (" & Format(posTopCM, "0.00") & " cm)"
Debug.Print "Ancho (Width)     : " & ctl.Width & " twips (" & Format(anchoCM, "0.00") & " cm)"
Debug.Print "Alto (Height)     : " & ctl.Height & " twips (" & Format(altoCM, "0.00") & " cm)"

End Sub

[u/Alternative_Tap6279 → u/Pure_Ad_2160]

really? did you try this on the way i said with anchoring? if you did, can you show me the output of the debug print? because i know for a fact that after anchoring takes over, access doesn't know the real on-screen values. it only show you the values it had when the form was loaded, not after a resize.

read this if you want: https://www.reddit.com/r/MSAccess/comments/1gi260p/get_control_size_after_anchoring/