Combining Delphi Desktop and Web Portals: Architecture, Interfaces and Modernization without Disruption

In many companies the functional “control center” has grown over years as a Delphi desktop application: VCL client, deep process knowledge, fast data entry, print and reporting pipelines, specialist hardware and often direct database access on the LAN. At the same time expectations for self-service and external collaboration are rising: customers want to check order statuses, exchange documents or file complaints — without VPN, without a desktop rollout and without local installations.

Combining Delphi desktop and web portals means in practice bringing those two worlds together so that operation, security and data consistency remain manageable. The decisive factor is not “rebuilding” forms in the browser, but an architecture that cleanly separates processes, permissions and data paths and lets both frontends operate under common rules. The benefit is a modernization path without a Big-Bang: the desktop remains productive while the web portal grows in a controlled way.

This article is aimed at IT leadership, administrators and technical project owners. The focus is on effects for operation, administration, interfaces, security, data storage and migration — not on framework details. You will get practical patterns, decision criteria and typical pitfalls including countermeasures.

Why “portal instead of desktop” is rarely realistic

In B2B environments there are many reasons why a desktop client remains sensible. Administrators often experience this concretely: a portal is ideal for distributed users, but certain tasks remain more efficient or only possible in the desktop.

Desktop strengths that matter in daily use

• Complex data entry with very dense forms, keyboard operation, large table views and fast switching between records.
• Peripherals and local integrations such as label printers, scanners, serial devices or special Windows components.
• LAN-near performance when large data volumes are processed or a process requires extremely low latency.
• Mature workflows with many edge cases where a 1:1 port into a portal initially carries high risks.

Portal strengths that cover new requirements

• External access for customers, suppliers or partners without a client rollout.
• Central control (versions, features, permissions) with a clear outer edge.
• Device independence (browser, mobile use) for field staff and management.
• Targeted process openings such as status checks, uploads, approvals or ticket flows.

The value lies in combination: the desktop remains the power tool for internal roles, the portal becomes the controlled access for external user groups. To prevent the two from diverging into parallel “truths”, you need a connecting core.

When you combine Delphi desktop and web portals: three target architectures

The architectural decision is mainly about responsibilities: where does the business rule reside? Who is allowed to change data? Which layer is the Single Source of Truth (i.e. the authoritative source for rules and states)? For technical decision-makers the important point is: the choice has direct consequences for operation, troubleshooting, release management and security.

Variant A: Portal as an adjunct via REST API, desktop remains leading

The portal serves selected use cases, typically “read and trigger”: status, documents, approvals, simple captures. For this a Delphi REST-API or a separate REST server is introduced. The desktop application can initially continue to access the database directly.

Operational advantage: fast start, limited changes to the desktop, good for an initial portal benefit.

Risk point: two data paths exist (desktop → DB directly, portal → API). If business rules live only in the desktop, inconsistencies arise. As a countermeasure, portal functions should deliberately begin where rules are simple and can be represented server-side (e.g. document provision, status query, defined approval actions).

Variant B: Service core as a shared process layer (recommended for parallel operation)

Here you gradually move business logic out of the desktop into services. Desktop and portal use the same endpoints. The desktop becomes more of a rich client (UI, local integrations); rules and validations live server-side.

Operational advantage: a central place for permissions, audit, status logic and validations; consistent behaviour across all frontends.

Effort: higher at the start because API standards, error formats, versioning, monitoring and deployment must be planned cleanly. For that you substantially reduce effort later because fewer special paths remain.

Variant C: Portal leads, desktop remains as a specialist client

This variant makes sense when the browser is to be the strategic standard access (e.g. in a highly distributed organisation), while the desktop remains for certain roles with specialist hardware or high-performance capture. The service core must be particularly stable and scalable for this.

Layer-3 architecture as a comprehensible guideline

Regardless of the variant, a Layer-3 architecture helps: (1) presentation (desktop/portal), (2) application and domain layer (use cases, rules), (3) infrastructure (database, file storage, messaging, external systems). For administrators this is important because operational boundaries become clear: what is a “frontend problem”, what is a “service problem”, what lies in the database or in storage? This separation shortens troubleshooting and reduces side effects during deployments.

Practical relevance: how desktop and portal share the same process

The biggest challenge is rarely “building the portal”, but the question: how do desktop and portal share responsibilities within the same process without rules being implemented twice? Three patterns are particularly relevant in practice.

1) Use-case APIs instead of table- or CRUD-APIs

A common dead end is an API that merely exposes database tables (“Create/Read/Update/Delete”). Then rules must be reimplemented in the portal and the desktop retains its own rules. Better are use-case APIs: endpoints describe business actions such as “create complaint”, “approve order”, “upload document”, “confirm delivery status”.

The effect in operation is tangible: validations happen server-side, error messages are reproducible, and both clients (desktop and portal) trigger the same flow through the same logic.

2) Make conflicts and retries manageable

With a portal the likelihood of parallel changes and repeated requests increases (e.g. due to timeouts, retries or double clicks). Three concepts help here without introducing “permanent locks”:

• Idempotence: critical actions are designed so that a repeat leads to the same effect and nothing is executed twice. Practically this is often implemented via a unique request identifier (idempotency key).
• Optimistic Concurrency: a record carries version information (e.g. “row version”). On change the service checks whether the version still matches and reports conflicts cleanly.
• Short transactions: instead of “locking everything” write operations are kept short. Long-running work (e.g. exports, report bundles) runs asynchronously.

For technical decision-makers it is important: these mechanisms reduce support effort because error patterns (“it happened twice”, “my change is gone”) become much rarer.

3) Model states and handoffs clearly

If the desktop handles complex cases and the portal “only” submits requests or pre-stages data, you need defined status transitions. A practical partition is: the portal creates or augments transactions in clearly limited status ranges (e.g. “submitted”), the desktop handles special cases, and the service core decides and logs status changes. This prevents the portal client from indirectly “misconfiguring” processes.

Data and documents: the often underestimated integration area

Almost every portal brings file operations: uploads, evidence, delivery notes, images, PDF outputs. For administrators this is a core topic because it affects backup, permissions, virus scanning, storage costs and performance.

Where to store files: database, fileshare or object storage?

There are three common storage options, each leading to a different operational reality:

• Database (BLOB): good when transactions must be strictly coupled and backup/restore should remain a single package. Drawbacks are often larger databases and longer backup windows.
• Filesystem/share: typical on-prem, well integrable into existing backup concepts. Clear permissions and an API layer that controls access are important.
• Object storage: sensible for scaling, lifecycle rules or when external access should be technically encapsulated. Requires a conscious key and permission model.

Regardless of storage location: the portal should not load files “directly” from a share. Better is a controlled download via service endpoints with permission checks, logging and optional time-limited download URLs.

PDFs and reports: server-side instead of duplicate implementations

Delphi desktop applications often have grown printing and reporting pipelines. Portals frequently need the same content as PDF. Instead of maintaining two implementations, central document generation in the service core is worthwhile: templates, versioning and output formats live server-side; desktop and portal consume the result. For operation this brings clear advantages: reproducible outputs, unified storage and less dependency on desktop installations.

REST servers and services: Delphi, C# or a hybrid architecture

The decision “Delphi or C#” is less ideological for companies than a question of team capability, operational environment and maintainability. In many environments a hybrid architecture is realistic, provided responsibilities are cleanly cut.

Delphi as a service platform: sensible when business logic exists there

If business logic and data access are already solid in Delphi, a Delphi-based REST server can be efficient. For administrators and decision-makers it is important to note: running a server is not “running the desktop continuously”. A productive service needs clear configuration, sensible timeouts, structured logs, health checks and a reproducible deployment.

Data connectivity should also be modernized if old drivers or the BDE are still in play. A BDE replacement and migration to modern data access reduces operational disruptions and eases deployment because fewer legacy components need to be installed and maintained.

C# services in the portal ecosystem: common due to hosting and identity

If the portal arises in a .NET-dominated landscape, C# services are often a natural choice — not least because of identity integration, existing operational standards and hosting behind Microsoft IIS or in containerised platforms. The decisive point is to avoid duplicate implementations: either the business core logic remains in Delphi services and C# handles edge topics (e.g. portal-specific orchestration), or you plan a controlled migration of logic into .NET with clear business boundaries.

API gateway: an organizing element, but not mandatory

An API gateway can consolidate central functions (routing, rate limits, logging, authentication). For smaller starter architectures a consistent API with uniform standards is often sufficient. As soon as multiple services and user groups exist, however, a gateway helps to stabilise the outer edge and enforce policies centrally.

Authentication and permissions: from the internal desktop to the external portal world

With a portal the user landscape changes: alongside internal users you get external accounts, roles and tenants. This creates requirements for identity, permissions and auditability. For administrators this matters because identity systems and role models are hard to change later.

SSO with SAML 2.0 or OIDC: less admin effort, better control

In B2B setups SAML 2.0 (single sign-on via an identity provider) is common because companies want to reuse existing identities. OIDC (OpenID Connect) is also widespread, particularly on more modern platforms. Classic username/password logins are possible but add overhead for password policy, MFA, resets and support.

Architecturally important: authentication (who are you?) and authorization (what are you allowed to do?) must be checked server-side — not in the portal frontend.

Multi-tenancy and role model: don’t add them “later”

A customer portal practically always requires tenant separation: a customer must only see their data. This must be modelled in the service core, ideally via:

• Claims in the token (e.g. tenant ID, roles, contract reference) so services can make decisions.
• Record-level checks (row-level checks in the business logic), not just “hiding menu items”.
• Audit trails for important actions (who, what, when), plus correlation via a request ID for troubleshooting.

The desktop can — if desired — also work with tokens against the same identity stack. That reduces special paths and simplifies traceability of changes, especially when portal and desktop edit the same record.

Modernise data access: FireDAC, PostgreSQL and controlled data paths

Many Delphi desktop solutions historically grew with direct DB access. As soon as a portal is added this becomes an architectural topic: data paths must be controllable, validations must apply centrally, and performance must remain stable under parallel load.

FireDAC as a basis for maintainable data access

BDE replacement with native connectivity is a common standard in Delphi environments for accessing modern databases. What matters less is the component itself than the unification: parameterised queries, clean transaction boundaries, consistent error handling and measurable execution times. For operation it is important that timeouts and resource consumption become predictable and that problems can be reproduced in logs and monitoring.

PostgreSQL with Delphi: well manageable with a clean type- and migration concept

PostgreSQL with Delphi is robust if type mapping (e.g. UUID, timestamps, JSON fields), indexes and schema migrations are handled cleanly. Portals in particular generate many filtered list queries. Filters, paging and sorting should be implemented server-side so that large data volumes are not transferred unnecessarily. That reduces load and improves user experience without slowing down the desktop.

Operation, deployment and monitoring: bring portal maturity to Delphi backends

A portal is usually permanently reachable and therefore operationally more demanding than a pure desktop. For administrators this is where a good architecture immediately pays off: through reproducible deployments, clear observability (logs/metrics) and defined maintenance windows.

Windows service or Linux service: the operational model matters

A Delphi service can be run as Windows- and Linux services or as a Linux daemon. More important than the operating system are standards that make operation stable:

• Health checks for monitoring and load balancers (e.g. “service alive” and “database reachable”).
• Structured logging (including request ID, user/tenant, execution time, status codes) so support cases are reproducible.
• Configuration without rebuild (e.g. environment variables, central configuration files) so deployments can be automated cleanly.
• Rollback capability through clear versions and migration-safe database changes.

Load profiles: portal is “many short requests” instead of “few long sessions”

Desktop usage often produces longer work phases per user, while portals generate many short, parallel requests. Typical technical measures are:

• consistent paging, server-side filtering and limited response sizes
• caching for master data and infrequent queries
• asynchronous jobs for long-running tasks (exports, report bundles)
• rate limits and protection mechanisms against abusive use

For decision-makers the central point is: performance is not a “final tuning” task, but part of the API definition (response sizes, timeouts, background processing).

Modernization without Big-Bang: a resilient path in five steps

A complete rebuild is rarely necessary and often risky because process knowledge resides in the Delphi client. A proven approach is to ensure each stage is productively usable and does not jeopardise operation.

1) Assessment: processes, data ownership, integrations

Start not with forms, but with use cases: which flows should move into the portal? Which data may an external user see or change? Which interfaces exist to ERP, DMS or CRM? From this you derive a prioritized API list that delivers real value.

2) Define service basics: auth, error format, logging, versioning

This foundation determines future maintainability. Agree early on standards for authentication/authorization, a consistent error format, request correlation, API versioning and telemetry. This reduces friction between the portal team, backend team and operations.

3) Deliver a first portal path end-to-end

Choose a process with clear boundaries (e.g. document area or status query). It is important that the entire chain is in place: login, permission check, API, UI, logging, monitoring, operation. This lets the organisation learn early which standards work in daily use.

4) Integrate the desktop selectively: critical write paths via services

Once services are stable, migrate selected desktop functions: in particular status changes, approvals or central validations. The desktop remains performant, but rules become more consistent and direct DB write access is gradually reduced.

5) Consolidate: remove duplicate rules and special paths

Otherwise you end up with “two systems” over time. Plan regular consolidation: which rules exist twice? Where can the portal use desktop services? Which reports should be generated centrally? The goal is a manageable platform, not a dogma.

Typical operational pitfalls — and how to avoid them

Rules are reimplemented in the portal

This leads to deviations and support cases. Countermeasure: use-case APIs with server-side validations, clear error returns, and if possible shared business test scenarios.

Unclear data ownership between desktop and portal

If both clients are allowed to change “everything”, conflicts arise. Countermeasure: status model, defined responsibilities and optimistic concurrency for competing changes.

Security treated as an afterthought

Especially for a customer portal SSO, tenant checks, secure file downloads and auditing are required from the start. Adding them later is more expensive and increases the risk of security gaps.

Lack of operational transparency

Without request IDs, structured logs and health checks troubleshooting becomes detective work. Countermeasure: observability as a mandatory part of the first service releases.

Conclusion: a service core connects desktop strength with portal reach

The combination of Delphi desktop and web portal is in many companies the most realistic way to preserve core processes while enabling external collaboration. The decisive factor is not operating two separate worlds, but creating a connecting service core: use-case APIs, clean permissions, traceable states, controlled data paths and an operational model with logging, monitoring and predictable deployments.

This yields modernization with intermediate goals: the desktop stays productive, the portal delivers early value, and the architecture becomes progressively more consistent and maintainable.

In the business context Delphi modernization also plays an important role when integrations, data flows and further development must work together cleanly.

Discuss a project or modernization initiative with Net-Base.