Microsoft Access modernization
An Access application is several things combined in one file: data, relationships, queries, forms, reports, macros, VBA, and years of business decisions. Modernization succeeds when those components are evaluated separately instead of treating the file as one object that must be converted or discarded.
PHPRunner can use migrated tables and conversion tools to accelerate the new web application. The most valuable planning step is identifying which parts are reusable structure and which parts express behavior that must be reviewed.
Quick answer: Inventory the Access application by component. Tables, keys, relationships, straightforward queries, and familiar form layouts can often provide a strong starting point. VBA, macros, unusual controls, complex reports, local-file operations, and implicit security assumptions require deliberate redesign or testing. Preserve the business rules, not every desktop implementation detail.
Moving tables does not recreate the behavior that surrounded them.
The data may remain in Access for a limited internal application or move to MySQL, SQL Server, PostgreSQL, or another server database. That decision affects concurrency, administration, backups, and deployment, but it is distinct from deciding how users will search, edit, approve, print, and report on the data.
Make the data move repeatable. Preserve primary keys, foreign keys, required fields, defaults, indexes, and data types. Reconcile row counts and important totals before relying on the new application.
The most important rule may be hidden in an event, expression, query, or report.
| Access component | What may be reusable | What requires review |
|---|---|---|
| Tables and relationships | Entities, keys, links, and much of the stored data. | Access-specific types, missing constraints, attachment fields, and inconsistent values. |
| Queries | Joins, filters, calculations, and reporting intent. | Access SQL syntax, parameters, functions, action queries, and dependencies on forms. |
| Forms | Field grouping, terminology, navigation, and common tasks. | VBA events, subforms, local automation, and desktop-only interaction. |
| Reports | Grouping, totals, business labels, and expected output. | Exact pagination, printer assumptions, custom expressions, and special formatting. |
| Macros and VBA | The underlying trigger, decision, and outcome. | The implementation normally needs to be recreated with web application events or services. |
A browser application has different users, sessions, permissions, and deployment boundaries.
An Access form may rely on a trusted network folder, installed Office software, a shared drive letter, Windows authentication, or a single user completing several steps in sequence. Those assumptions may not exist for remote users or on a web server.
Translate each behavior into a requirement: “create a PDF invoice,” “prevent approval below a margin,” or “show orders for the selected customer.” This keeps the useful business outcome while allowing a more appropriate web implementation.
Use conversion to establish a starting point, then review the application as a web system.
Connect PHPRunner to the migrated database and generate the standard List, View, Add, Edit, Search, report, chart, and dashboard pages that match the real user tasks. Imported or converted form layouts can preserve useful familiarity without requiring the final page to imitate Access exactly.
Recreate custom rules through security settings, validation, events, queries, buttons, and integrations. Test with real users module by module so omissions are found while the corresponding Access behavior is still available for comparison.
Modernize in slices that produce a complete business outcome.
Select one useful workflow, inventory its data and behavior, migrate it, and run it alongside the existing application long enough to compare results. This reduces risk and makes “what can be reused?” a concrete decision instead of a guessed conversion percentage.