Serge Pilko

How upgrading from Delphi 7 to Delphi 12 eliminated 15 monthly support tickets and unlocked Linux deployment In May 2024, we were contacted by a European leader in natural gas measurement systems. Their software was partly built in Delphi 7 and partly in C#. It had become difficult to maintain. The company wanted to migrate to Delphi 12, modernize the UI, and enable Linux deployment, without breaking existing functionality. Our team faced and handled the following challenges: The project relied on Delphi 7. That version lacked full Unicode support. The framework used ANSI strings by default, and this created critical limitations for modern global applications. The legacy app only ran on 32-bit Windows, using outdated Win32 APIs and hardcoded paths (C:\Data\). This prevented deployment on Linux cloud servers (AWS/Ubuntu). The app was built on obsolete BDE components and unsupported libraries. Here's what we did: ✅ Migrated from Delphi 7 to Delphi 12 ✅ Replaced BDE and Indy 9 with FireDAC and Indy 10 ✅ Refactored code for cross-platform compatibility ✅ Delivered a modernized UI with preserved workflow familiarity We achieved: - 15 support tickets per month were reduced to zero - Windows-only application is now cross-platform - Overall, the application is more prepared for future challenges A few months later, the client returned for an estimate to migrate other Delphi projects to a web-based platform. If you want to see the full story, with the challenges and solutions broken down, follow the link https://www.softacom.com/cases/modernizing-industrial-software-with-delphi-12/

Turning a legacy database into a modern, high-performance platform might seem intimidating. Old routines, custom PL/SQL, proprietary extensions. There is a lot that can break. But with careful planning, the right tools, and a methodical approach, you can make the move safely. Migration can take 3 phases: Assessment phase. The first step is identifying the schema's complexity, custom code, and potential pitfalls. Pilot phase. The second step is about testing the migration path with low-risk components first. Full migration phase. The third step is to minimize downtime and ensure that your data is consistent. You should prepare a rollback plan, backup your data, and carefully cut over with extensive testing afterwards. Some of the most common pitfalls you may face include: Fully trusting automation to do everything. ORM differences. Transaction isolation and locking mechanisms. It is not the same in Oracle and PostgreSQL. Extension dependencies. Missing libraries can break your migration if you are not careful. Our team at Softacom recently successfully performed a complex migration for a financial institution. It required a phased approach. We migrated over 800 tables and 300 routines from Oracle to PostgreSQL, retaining data integrity and functionality, all while avoiding significant outages and preserving business operations. If you want more detailed information about what we did, you can find it here: https://www.softacom.com/wiki/how-to-migrate-a-legacy-system-to-postgresql-real-world-example/