Existing database application planning
An existing database can save months of data modeling and migration work, but it also creates an important decision: should the new application write directly to the tables, use a separate query layer, or leave all writes to the system that already owns the data?
This guide gives you a practical readiness test, helps you choose the safest starting point, and explains how a tool such as PHPRunner can turn an existing database into a working web application.
Quick answer: Do not begin by generating a page for every table. First identify who owns the data, whether every editable record has a reliable key, where the business rules live, and whether other software writes to the same tables. Those answers determine whether a direct connection is safe or whether you need views, an API, or database repairs first.
Score each area from 0 to 2. This is a planning aid, not a technical certification.
| Readiness check | 2 points | 1 point | 0 points |
|---|---|---|---|
| Record identity | Every editable table has a stable primary key. | Keys exist, but some are composite or poorly documented. | Records have no reliable unique identifier. |
| Relationships | Foreign keys and important relationships are known. | Relationships work but are enforced only by convention. | Related records cannot be matched reliably. |
| Data ownership | It is clear which system may create and change each record. | Several systems write data, but responsibilities are documented. | Multiple systems can overwrite the same data unpredictably. |
| Business rules | Rules in the database and existing application are documented. | Some triggers, procedures, calculations, or legacy rules remain unclear. | Important rules are unknown or exist only in an old interface. |
| Access model | Users, roles, operations, and record ownership can be defined. | Page access is known, but record-level rules need work. | There is no safe way to separate users or sensitive records. |
| Safe testing | You have a current test copy, backups, and a rollback plan. | A test environment exists but does not reproduce every integration. | The only way to test is against live production data. |
10–12 points: the database is usually a good candidate for a direct application connection. 6–9 points: plan a controlled layer of views, queries, permissions, or database cleanup. 0–5 points: repair the data model or integration approach before allowing a new application to write.
One rule overrides the score: if the database belongs to a third-party product, confirm that direct access is supported. A vendor API or documented integration may be safer than writing to its tables.
The useful unit of design is a user task, not an individual table.
| Existing data | Useful application experience | What to verify first |
|---|---|---|
| Customers | A searchable customer list and a profile showing contacts, orders, invoices, and notes. | Customer ID, duplicate records, and which fields are sensitive. |
| Orders and order lines | One order page where users edit the header and its line items together. | Master-detail keys, transaction rules, totals, tax, and status changes. |
| Products and prices | Product lookups that show only valid choices and use the correct current price. | Which table owns price and availability, and whether historical orders retain old prices. |
| Employees or sales representatives | Permissions that limit users to their customers, region, department, or assigned work. | How application accounts map to existing records. |
| Reporting views | Dashboards for overdue orders, sales totals, and operational exceptions. | Whether views are current, performant, and intended to be read-only. |
The simplest technical connection is not always the safest application design.
This is the shortest path when your organization owns the database, primary keys and relationships are reliable, and the new application is allowed to update the data. Use a dedicated database account with only the permissions the application needs.
A mature database may contain cryptic names, normalized structures, or many tables that should not be exposed directly. Views and application queries can combine and rename data for searches, profiles, reports, and dashboards while leaving the underlying schema intact. Keep writes tied to clearly owned tables and rules.
If the database belongs to an ERP, CRM, accounting package, or other vendor application, direct writes may bypass validation, licensing rules, caches, or upgrade assumptions. Use the supported API or integration layer when the vendor requires it.
A new interface cannot compensate for records that cannot be identified or related consistently. Add reliable keys, document relationships, remove critical ambiguity, and establish backups before expanding access. If you are moving from a file database such as Microsoft Access, see our guide to replacing Microsoft Access with a web application.
You do not need to know PHPRunner before arriving at this page.
PHPRunner is a low-code application builder for creating PHP web applications around your data. You connect it to an existing database, choose the tables and queries the application needs, and generate working pages for viewing, searching, adding, and editing records. You can then customize the layout, security, workflow, reports, dashboards, and business logic before deploying the application to your own web server.
PHPRunner does not remove the need to understand the database. It reduces the repetitive work after you have decided which data may be exposed and how users should work with it.
| Project task | How PHPRunner helps |
|---|---|
| Connect and select data | Connect to SQL Server, MySQL/MariaDB, PostgreSQL, Oracle, Access, SQLite, and other supported databases, then select the required data sources. See Connecting to the database. |
| Represent relationships | Use joins, queries, lookups, and master-detail relationships to turn related tables into useful pages. See Master-detail relationships. |
| Create the first application | Generate List, View, Add, Edit, and Search pages, then adjust them in Page Designer instead of building every screen from scratch. |
| Control access | Add authentication, user groups, page permissions, and record-level security based on the application's real users. |
| Add business behavior | Use validation, events, custom code, reports, charts, dashboards, and integrations where the generated starting point is not enough. |
Prove one complete workflow before expanding the application.
Choose one useful task—such as finding a customer and reviewing their orders—and build it against a safe test copy of the database. Verify the keys, joins, permissions, and business rules, then let real users test the workflow. This exposes database and usability problems early without committing the whole project to the wrong structure.
Once that workflow is correct, the same approach can be extended to data entry, approvals, reports, dashboards, and other parts of the application.