Many companies run, day after day, on programs written fifteen or twenty years ago. They handle invoicing, manage the warehouse or control production, and that is exactly why nobody dares to touch them. But those legacy systems that were once a competitive advantage are now often the brake that stops a business from adding a new tool, opening an online sales channel or simply hiring someone who knows how to maintain them.
The good news is that modernizing legacy systems no longer means throwing everything away and starting from scratch. With a proper diagnosis, a phased migration and serious version control, an old application can become a modern platform without losing critical data or stopping operations. In this article we explain how, using a very concrete example: moving a project from Delphi 6 to Delphi 13.
In short: legacy systems do not fix themselves, and every year they become more expensive to maintain and riskier to run. The way out is not rewriting everything, but auditing the code, migrating step by step with tests and version control, and then maintaining the application with a clear plan. That is how you modernize without losing data or slowing the business down. And if your application is still on an old version of Delphi, a free pre-audit tells you how much it would cost to bring it to Delphi 13 before you make any decision.
What legacy systems are and why they hold growth back
A legacy system is any software that still matters to the business but was built with technologies, versions or practices that are no longer supported or that few people still master. It does not have to be "old" in years: an eight-year-old application with no documentation and no tests can be just as problematic as a program from the nineties.
The issue is not age, but what it causes:
- Rising maintenance costs. Every small change takes more hours, because nobody fully understands how it is built.
- Dependence on one or two people. If the person who knows the system leaves, the knowledge leaves with them.
- Security risks. Outdated libraries and components pile up known vulnerabilities that no longer get patches.
- No way to integrate. Connecting the system to a modern API, an online store or an AI tool becomes a project of its own.
This is not only a small business problem. The U.S. Government Accountability Office (GAO) reported in 2025 that federal agencies spend about 80% of their IT budget on operating and maintaining existing systems, and that seven of the eleven most critical legacy systems it reviewed have known cybersecurity vulnerabilities (GAO). If an administration with that budget struggles, a mid-size company cannot afford to ignore it.
Signs your legacy systems need attention
You do not have to wait for an outage to act. These are the most common signs we see in companies that contact us:
- The program can only be compiled on one specific computer, with an old version of the development environment installed.
- Windows or server updates cause errors that nobody knows how to fix.
- The code is not in any repository, or it lives in folders with names like "final_version_2".
- The data sits in an old database (Paradox, dBase, Access or an unsupported engine) that suffers from locking or corruption problems.
- Asking for a new feature always gets the same answer: "that is not possible with this system".
If two or more of these sound familiar, now is a good time to run an audit and plan the modernization before a breakdown makes the decision for you.
The reality of companies that stayed on Delphi 5, 6 or 7
Between the late nineties and the mid-2000s, Delphi was one of the favorite tools for building business software in Spain, Latin America and across Europe: ERP systems, invoicing programs, point-of-sale software, industrial and production control applications. It allowed fast development, produced very efficient native executables and connected to almost any database. Many of those applications are still in production today, more than twenty years later, because they do their job well.
The problem is that a large share of them stayed frozen in the version they were born with. The reasons tend to repeat:
- The Unicode leap in Delphi 2009. It was one of the deepest changes in the history of the language and required reviewing a lot of code. Many companies kept postponing it, and every new version made the leap a little bigger.
- "If it works, don't touch it". As long as the program kept invoicing, upgrading looked like a cost with no return.
- The original developer is gone. In many cases the software was written by a single person or a small company that closed or changed business.
- Abandoned commercial components. Reporting, grid or communication libraries bought years ago that have no version for today's Delphi.
Where those applications stand today
These are the situations we find most often when reviewing Delphi projects from that period:
- They are built on an "untouchable" machine. The executable can only be generated on a computer or virtual machine running Windows XP or Windows 7, because it is the only environment where the old IDE and its components still work. Both operating systems stopped receiving security patches years ago.
- They run with issues on Windows 10 and 11. Blurry or misaligned screens on high-resolution monitors, permission errors when writing to the installation folder, or printers that stop responding after an update.
- The data lives in Paradox or dBase tables through the BDE. With network locking issues, damaged indexes and the regular need to "repair tables" so the program starts again.
- They cannot meet new requirements. Adapting invoicing to regulations such as Spain's VeriFactu, connecting to an online store, offering a mobile app or integrating with a bank's API gets solved with external patches or simply cannot be done.
- Nobody knows whether the source code is complete. In some cases there is not even certainty that the stored code matches the executable running in production.
How far you are from Delphi 13 depending on your version
Not every old Delphi application starts from the same point. As a rough guide:
- Delphi 5, 6 or 7 (1999 to 2002): the full journey. Unicode must be addressed, the BDE replaced if it is used, third-party components upgraded or replaced, and then the move to 64-bit and a modern interface. It is the most common case and the one that needs the most upfront analysis.
- Delphi 2005, 2006 or 2007: a very similar situation. Unicode is still the main hurdle, although the code is usually somewhat better organized.
- Delphi 2009 to XE7: the code is already Unicode. The work focuses on components, data access (the BDE is no longer included in the installation from XE8 onwards) and 64-bit compilation.
- Delphi XE8, 10.x, 11 or 12: usually a simpler upgrade, focused on components, compiler warnings and taking advantage of language and IDE improvements.
The good news is that this code is not lost. The business logic it contains, refined over years to match how the company works, is precisely the most valuable part, and in most cases it can be preserved when migrating to Delphi 13. What you need is to know how much that leap costs before deciding.
Case study: migrating legacy systems from Delphi 6 to Delphi 13
Delphi is a good example of a technology that is still very much alive but carries a huge number of old applications. Delphi 6 was released in 2001, and some companies still invoice today with programs compiled in that version. Meanwhile, Embarcadero launched Delphi 13 Florence in September 2025, with new features such as a ternary operator in the language, improvements to VCL and FireMonkey, and AI features built into the IDE, as Delphi product manager Marco Cantù explains on his official blog.
Almost twenty-five years of changes separate the two versions. These are the points that take the most work and how we handle them:
Unicode and string handling
Since Delphi 2009, the string type is Unicode. A project written in Delphi 6 assumes each character takes one byte, which affects file reading, device communication, DLL calls and pointer arithmetic. Embarcadero itself recommends reviewing this before anything else in its roadmap for migrating legacy Delphi applications. The key here is to find every risky use and cover it with tests before changing it.
From BDE to FireDAC without losing data
Many applications from that period access data through the Borland Database Engine (BDE), which stopped shipping with Delphi from version XE8. The natural replacement is FireDAC. Data migration is the most delicate part: it is done with repeatable scripts, validated record by record against the source and rehearsed several times before the final cutover. No data is considered migrated until the numbers match.
Third-party components
Grids, reports, printing controls or hardware connections often depend on commercial components that may no longer exist. For each one we decide whether there is a current version, an equivalent replacement, or whether that part should be rewritten.
64-bit, styles and high resolution
Once the project is stable, the rewarding part begins: compiling for 64-bit (possible since Delphi XE2), adapting the interface to high-resolution screens and applying modern styles. That is when end users notice the change.
We apply the same approach to other languages and platforms: Visual Basic, older versions of PHP or Java, desktop applications that need to move to the web and databases that need to move to the cloud. If you want to see the general method, we explain it in detail in how to migrate legacy software without stopping your business.
Free pre-audit: how much it costs to evolve your Delphi code
The question companies with applications on old Delphi versions ask us most is always the same: "how much will it cost to upgrade it?". Without seeing the code, any figure would be a guess. That is why we offer a free pre-audit of your Delphi source code, designed to give you a well-founded estimate of the cost of the upgrade before committing any budget.
In the pre-audit we review:
- Project size and structure: number of units, forms and lines of code, and how they are organized.
- Source version and dependencies: which Delphi version it was built with and which third-party components it uses, checking whether versions compatible with Delphi 13 or equivalent alternatives exist.
- Data access: whether it uses BDE, dbExpress, ADO or another technology, and what moving to FireDAC involves.
- Unicode impact: the areas of the code that work with strings, files, pointers or external calls and will need review.
- Risk areas: hardware integrations, external DLLs, printing or communications that need special attention.
When it is done, we hand you a clear report, free of unnecessary jargon, with:
- An estimate of the effort and cost of the upgrade to Delphi 13, in realistic ranges.
- The main risks found and how to mitigate them.
- The possible options: migrate as is, migrate and modernize the interface and architecture, or rewrite only the parts that are not worth keeping.
- A proposed phased plan, so you can decide based on data and with no commitment.
All we need is access to the source code (under a non-disclosure agreement if you prefer) and a short conversation about how the application is used. Your code is never modified: the pre-audit is analysis only.
The five pieces of a successful legacy systems modernization
A single migration is not enough. For technology to stop holding growth back, we work on five fronts that reinforce each other:
- Custom software development. When the legacy system cannot be saved, we build the new solution from scratch, from 0 to 100, aligned with business goals. See how we do it in our custom software development service for companies.
- Migration from old to new technologies. We upgrade obsolete systems for better performance and security, as in the Delphi case, always with a rollback plan. More details on our Delphi development page.
- Application maintenance. After the migration, we ensure stability, continuous optimization and evolution, so the system does not fall behind again.
- Code audit. We analyze repositories to detect vulnerabilities, remove technical debt and improve the architecture. It is the starting point of any serious modernization.
- Control with GitHub. We set up workflows with branches, code reviews, continuous integration and good versioning practices. To understand what gets reviewed in a repository, read the difference between a Git audit and a code audit.
What a modernization project with MiTSoftware looks like
Every system is different, but the journey usually follows these phases:
- Diagnosis and audit. For Delphi projects it starts with the free pre-audit. Then we review in depth the code, dependencies, database and how the system is used day to day. The result is a report with risks, priorities and a realistic estimate.
- Repository and reproducible environment. Before changing a single line, we put the code under control in GitHub and make it build reliably outside "the usual computer".
- Phased migration. We move module by module, with tests at every step and data validated in parallel, without stopping operations.
- Supported go-live. We schedule the cutover at the lowest-impact moment and keep a rollback plan in case something does not go as expected.
- Maintenance and evolution. Once stable, the system enters a cycle of continuous improvements and updates with our software review, maintenance and consulting team.
Frequently asked questions
Is it better to migrate or rewrite from scratch? It depends on the state of the code and the value it holds. If the business logic works and is reasonably well organized, migrating is usually faster and safer. If the system is badly degraded or the technology has no future, a phased rewrite may pay off. The initial audit exists precisely to make this decision based on data.
Can data be lost when migrating from Delphi 6 to Delphi 13? Not if it is done properly. We always work on copies, with repeatable migration scripts and validations that compare source and target before the final cutover.
Can we go straight from Delphi 6 or 7 to Delphi 13, without intermediate versions? Yes. There is no need to go through every version: the migration goes directly to Delphi 13, resolving all the accumulated changes at once (Unicode, data access, components and 64-bit).
Does the free pre-audit commit us to hiring the migration? No. The report is yours, and you can use it to decide, to compare quotes or to plan the project with your own team.
What if we do not have all the source code or the original components? It is more common than it seems. In the pre-audit we identify what is missing and evaluate the alternatives: replacing components, rebuilding specific parts or recovering what is possible from old backups.
How long does it take to modernize legacy systems? An initial audit usually takes one to three weeks. A full migration ranges from a few months to over a year, depending on size, the number of integrations and the quality of the starting code.
Can we keep working while the project runs? Yes. The whole point of a phased migration is that the business never stops.
Request your free pre-audit
If your company has an application built in Delphi 5, 6, 7 or any version earlier than Delphi 13, the first step is knowing what state it is in and how much it would cost to bring it up to date. Request your free Delphi code pre-audit and we will give you an estimate of the cost of the upgrade, with no commitment.
If your legacy systems use another technology, we offer a free 30-minute technical consultation to review your case and tell you what to prioritize.
