Delphi estate: new interfaces without a big-bang rewrite…

Delphi development

The Challenge

Legacy data must sync with CRM

A proprietary data format needed exchange with a SaaS CRM without a risky freeze; a rewrite was not affordable short term.

Existing customers still expected updates from the Delphi suite; CRM projects depended on missing master data.

CRM without Delphi data is useless for us—but freezing the legacy app is too.

Undocumented exports and nightly jobs

Historical batch runs were triggered manually; errors surfaced only when sales reported missing contacts.

Key-person risk was high because export logic lived in only a few developers.

CRM schema updates threatened to break undocumented field mappings.

Target state: adapters instead of big-bang rewrite

REST and batch interfaces should sync bidirectionally, stay auditable and serve pilot customers without production downtime.

Sales must start CRM projects without risking a Delphi freeze.

Long term there is room for deeper modernisation—today reliable data exchange counts.

Audit log must make every sync row traceable for support and audit.

Pilot tenants define minimum round trips before production release of new CRM fields.

Batch jobs should surface failed runs before sales notices.

OpenAPI docs ease follow-on changes when CRM schema updates.

Our Solution

Adapter layer and service module

We encapsulated import/export in a service module with retries and audit logs; REST endpoints were versioned. Tests validated round trips against reference datasets.

Conflict matrix governs bidirectional updates between Delphi and SaaS CRM without data loss.

Delivered under our Delphi development service; legacy strategy in the legacy modernisation blog category.

Phase 1: read-only CRM connectivity

Contacts and opportunities flow from Delphi to CRM first; write paths follow agreed conflict rules.

OpenSSL and token rotation secure transport and authentication.

Reference datasets define round-trip tests before each release.

Field mappings between proprietary format and SaaS schema are versioned and documented.

Phase 2: batch, monitoring and pilot customers

Nightly jobs with monitoring and manual intervention; pilot tenants validate round trips before broad rollout.

Support dashboard shows failed sync runs with retry option without database intervention.

OpenAPI specs and batch schedules are versioned for internal IT and follow-on projects.

Every sync row needs an audit—or sales and support will not trust the interface.

Results

Operations without downtime

The legacy stack stays productive; CRM-led projects receive data on time. Missing master-data exports are eliminated.

Support can trace failed jobs in the dashboard and restart selectively.

Pilot tenants validated round trips before broad rollout.

Manual CSV corrections after nightly runs disappeared in the pilot phase.

Conflict matrix is documented in plain language for sales and support.

Round-trip tests block release on drift between Delphi and CRM.

Nightly batch runs log every sync step for audit and support.

CRM receives master data without risky freeze of the Delphi suite.

Adapter layer buys time for later module modernisation.

Measurable sync quality

Round-trip tests and audit logs sharply reduced manual corrections in the pilot phase.

CRM projects receive master data without risky freeze of Delphi production.

OpenAPI specs allow parallel CRM upgrades without Delphi downtime.

Support runbook covers typical sync errors and manual retry.

Maintenance and follow-on releases by Groenewold IT Solutions in East Frisia—Delphi adapters Made in Germany.

Data model and conflicts

Reference datasets and round trips

Automated tests compare Delphi and CRM states on defined reference accounts; drift blocks release.

Versioned REST endpoints

API versions allow parallel CRM upgrades; deprecation windows are documented.

Operations and support

Batch monitoring

Failed runs escalate via alert; manual retry remains possible without direct database edits.

Roadmap to deeper migration

The adapter layer buys time for later module modernisation without big-bang risk.

API versioning allows parallel CRM upgrades without Delphi downtime.

Pilot customers and rollout

Reference datasets

Pilot tenants define minimum test cases for round trips; drift blocks production release.

Support receives runbook for typical sync errors and manual corrections.

Lessons learned from pilot phase fed conflict matrix and monitoring thresholds.

Documentation for follow-on projects

OpenAPI specs and batch schedules are versioned; knowledge transfer to internal IT is secured.

Lessons learned from pilot phase fed conflict matrix and monitoring thresholds.

Features

Feature overview

REST adapters with authentication and logging
Batch jobs with monitoring and manual intervention
Backward-compatible data models for pilot customers

Frequently asked questions: Delphi maintenance and new interfaces

Is Delphi maintenance worth it when new interfaces are required?

Yes, when domain logic lives in the legacy stack and a big-bang rewrite would be too risky. ERP, CRM, web portals or accounting exports can often be connected via REST adapters and middleware without replacing the core immediately. Delphi development and API and interface development are combined—incrementally, not all at once.

What are the risks of a big-bang Delphi rewrite?

Long feature freezes, data migration, maintaining two systems in parallel and losing implicit domain rules built over years of operation. Incremental interfaces keep the legacy stack productive while you modernise legacy software step by step.

How does an API façade in front of the Delphi core work?

External systems use REST or JSON; the façade maps to existing Delphi logic and the database. Authentication, logging, versioning and error handling sit centrally—the legacy core stays under control. That yields stable contracts for partners and SaaS tools without a monolithic rebuild.

How is parallel operation and stability ensured when connecting new systems?

Contract tests, staging environments, phased rollout and monitoring of latency and error rates. Critical paths are secured first; batch jobs get retry and audit logs. With several systems, thoughtful system integration beats point-to-point wiring.

When is migration to .NET better than Delphi maintenance alone?

When team skills, framework end-of-life, scaling limits or integration load permanently block the estate. Then extract modules step by step—not all or nothing. We plan Delphi to .NET migration with a pilot module and credible sizing—the Delphi cost calculator gives initial budget ranges.

Delphi estate: new interfaces without a big-bang rewrite