Modernize Delphi without losing domain logic

Delphi applications have been running stably in many companies for years — and precisely encapsulate the domain logic that secures revenue, service quality and compliance. Modernization therefore rarely concerns a „new UI“, but a controlled evolution that preserves rules, edge cases and historical process knowledge.

In this article we present a practical, proven approach to modernize Delphi step by step: from inventory and the decoupling of UI/data access to technical modernization (Unicode/64‑bit, BDE replacement, API/services) — including safeguards through tests, monitoring and parallel operation. The goal is an architecture that can be modernized without a Big-Bang rewrite and without loss of logic.

In practice, modernizations rarely fail because of the compiler or a framework, but due to incorrect assumptions about system behaviour. Delphi applications that have evolved over years typically contain domain rules in GUI events, SQL embedded in form logic, per-customer/tenant variants, historically caused special cases, and integrations that are documented only „in operation“.

A Big-Bang rewrite forces the reconstruction of this knowledge — including the bugs the legacy system no longer exhibits. A better approach is to treat the domain logic as an asset: isolate it, secure it, then modernize it step by step.

A viable target for process-critical B2B systems is not „everything new“ but an architecture that enables change — without endangering ongoing operations:

• clear separation of UI, domain logic, data access and integrations
• testability and measurability (regression, logging, monitoring, reproducible builds)
• gradual replaceability (modernize the UI without an immediate DB migration — or vice versa)
• API capability (e.g. REST), to connect portals, mobile or system integrations
• operational deployments with rollback options

Delphi is well suited for this because existing units and domain classes can be reused while the surrounding layers are modernized.

Before code is modified, a reliable decision basis is required — not full documentation. These three outcomes have proven effective:

• Domain logic map: critical use cases, rules/calculations, variants (tenants/countries/customers), interfaces, jobs/batch runs.
• Risk profile: particularly error-critical areas, data quality, regulatory requirements, operational bottlenecks (performance, stability, maintainability).
• Modernization backlog: prioritized packages by business value and risk (what must remain stable, what may change, what can wait).

This makes modernization plannable: with clear increments instead of a single „all-or-nothing“ project.

To prevent domain logic from being „accidentally“ changed, safeguards are needed that operate independently of UI refactoring. Typical building blocks:

• Characterization/Golden Master tests: existing behavior is frozen via representative inputs/outputs (reports, calculations, process steps).
• Regression tests at the use-case level: business-critical workflows are reproduced automatically or semi-automatically.
• Telemetry: logging, metrics and error patterns are made comparable before and after a change.
• Parallel operation & controlled cutover: new modules run alongside the legacy system (feature toggles, pilot groups), with a clear rollback strategy.

Only once these safety nets are in place does the actual technical modernization make sense — because risk and rework drop drastically.

The most common cause of logic loss is the mixing of UI, data access and domain rules. Modernization therefore begins with decoupling — not with replacing the UI framework.

A pragmatic target is a 3-layer structure:

• Presentation: VCL/FMX, Presenter/ViewModel, only UI-level validation (format, required fields)
• Business: domain models, services, rules, state logic, calculations
• Data/Integration: repositories, DB access, adapters to ERP/DMS/CRM, REST-clients, messaging

Rule of practice: domain rules move from OnClick/OnExit into domain services. SQL moves from Forms into repositories. This makes logic testable and later reusable across UI, services and jobs.

With the Strangulation Pattern, new components are deliberately created “beside” the legacy: new functions are implemented in the decoupled structure while the legacy system continues to run. Step by step the new layer takes on more responsibility until old parts are retired.

Example (typical B2B):

• You extract the order logic into a domain service.
• The existing VCL UI initially uses the same service (no process break).
• In parallel a REST endpoint is created for a customer portal or an integration.
• After stabilization individual old Forms are replaced — without the core logic having to be rebuilt.

This reduces project risk, preserves operational capability and quickly yields measurable benefits (e.g. API, performance, maintainability).

Depending on the starting point, these building blocks are often relevant — prioritization by risk and business value is decisive:

• BDE/legacy DB access replacement: modern drivers/providers, clean transaction boundaries, reproducible deployments.
• Unicode: string handling, database/interfaces, third-party components.
• 64‑Bit: dependencies, memory/performance, external libraries.
• API and service layer: REST, Windows-/Linux-services, integrations.
• Build & Release: CI/CD, artifact management, signed installers, rollback.

Important: These items are ideally implemented after decoupling and securing — then changes can be verified safely.

A complete rewrite can be sensible in some cases — but it is often the most expensive way to obtain “modern technology”. These questions help with assessment:

• Is the domain logic fully understood and testable — or is a lot of knowledge implicit in operations?
• Are there hard deadlines (e.g. platform end-of-life, compliance) that exclude parallel operation?
• How large is the variety of variants (customer/tenant-specific logic)?
• How critical is availability, and how high is the tolerance for process changes?
• Which parts are really to blame (UI, data access, integrations, deployment) — and which are stable?

In many B2B scenarios, an incremental approach leads faster to measurable results because it controls risks and protects the domain logic.

Delphi-Modernization Audit (for process-critical applications): We analyze architecture, dependencies, risk areas and deliver a prioritized roadmap for how to modernize without losing domain logic.

• Input: codebase (read-only), build setup, 2–3 core use cases, system environment (DB, integrations).
• Outcome: business-logic/module map, risk and dependency analysis, recommended target architecture, implementation plan in increments including safeguards (tests/parallel operation).
• Optional: proof of concept for decoupling + first Golden-Master test.

This provides a reliable basis for decision-making before budget and time are committed to a risky rewrite.

Can Delphi be modernized without rewriting the application?
Yes. In many cases business logic and data access are decoupled first, then technically modernized. That reduces risk and keeps operations stable.

How do you prevent business logic from being changed “silently”?
Through Golden-Master/regression tests, telemetry, and a controlled parallel operation with a clear rollback strategy.

Which steps often deliver the quickest benefit?
Transparency (assessment), decoupling of UI/SQL, replacement of BDE and an API/service layer for integrations — each secured by tests.

How long does a modernization take?
It depends on critical use cases, variant diversity and dependencies. An audit typically provides a reliable roadmap and prioritized increments in a short time.