• Cases
  • We improved performance and stability of a Payroll and tax system software, migrated it to the latest  version of Delphi

We improved performance and stability of a Payroll and tax system software, migrated it to the latest  version of Delphi

  • Industry


  • Project type



Our client is an expert in the Payroll, Tax, HCM industry and specializes in the automation of all the Payroll & Tax Filing processes. Their payroll and tax products are flexible, scalable, and reliable. With mobile, cloud-based software, and full-service options, users can manage both simple and complex payroll and tax management needs. Our client had its own custom software that had been built more than 20 years ago.

But everything is changing and evolving, so since the app has been created there are lots of changes in technology stack so each 2-3 years we have new trends in the IT sector, new tendencies in UI/UX design, security, frameworks etc. As our client works in the tax and payroll industry, it is crucial to have up-to-date secured software.

So, our client decided to migrate and modernize their core software application. By updating the version of Delphi and removing it from the technical debt we going to resolve the following issues:

  1. Prevent memory leaks;
  2. Make a more modern 64-bit platform that will allow to take care of AWS/Cloud infrastructure;
  3. Improve performance and stability;
  4. Lastly, moving to the up-to-date Delphi version made it possible to hire staff who work with a more current development stack

The difficulties we met during the implementation were the following:

Cumbersome source code

The client had been working on this software over the last 20 years and the source code was not well-documented, well-structured and well-written. We performed source code research and analysis, tried to understand the sense of some parts of the source code and its logic. Also, we couldn’t leave the code “as is” without source code refactoring. During the project life cycle it is the commonly faced difficulty that the documentation routines are not liked by the development teams. It’s not so obvious that the information about the fixes and changes can be helpful and even crucial for follow-up work.

Irrelevant use cases

As far as the application had some updates, many of the test cases became obsolete. Big part of the test cases relied on specific databases with certain settings that were not described in the test cases but could affect test results. Many of the test cases were not described in detail, which made them difficult to understand for inexperienced users. Our team suggested a testing approach and testing tool that helped reach the testing goals.

Unexpected business logic behaviour

As the sphere of payrolls and taxation is quite complex, in some cases it was quite difficult to “predict” the right application behaviour. Due to the lack of documentation, controversial moments were thoroughly discussed with the client and also compared with the old version.

Completely outdated components

Some of the components were not backward compatible due to the changes of business logic. These components had to be updated.

Code issues:

  • Unicode issues
  • Assembler issues
  • Pointers issues
Client`s pain and concern

We lost several features (desirable but not critical) during the past 2 years but we are expecting to start losing critical features if we do not revise the source code, fix bugs and update it to the up-to-date Delphi version.

Our old clients complain about outdated, convoluted and not user friendly interfaces. It takes us so much time to teach our new clients to use the system because of the same reasons.

We can not upgrade our system effectively because every new feature requires more and more time to be added. Not to mention the time required to fix issues emerging after every new system upgrade.

Project Team size

  • Project manager
  • 4 Delphi developers
  • QA engineer
  • UX/UI designer
Project Team size


Initial analysis

The team conducted the initial source code analysis to determine key project factors in order to select appropriate approach:

  • Project size;
  • Documentation fulfillness;
  • Customer’s team responsibilities areas;
  • Project dependencies;
  • Migration sequence and approach.
Distinguishing core modules with dependencies

It was crucial to determine the dependencies between components and core modules to plan the work consistently and also prevent working in vain, time, and resources wasting.

Migration implementation

We used next migration framework:

Select RAD Studio version (Delphi version)

  • Select Delphi version for the further development;
  • Bought license;
  • Deployed the project.

Create the project migration table

  • Project (.dproj) name;
  • Type of project: No-UI / UI project;
  • Migration objectives;
  • Project description;
  • Dependencies etc.

Highlight main tasks to provide a baseline for further work;

Split the whole project into smaller projects

Prepared components migration table

Divide the projects to No-UI projects and UI projects

No-UI projects migration:

Analyze and describe at least 5 unit tests for the key functions of each project;

Develop unit tests for Delphi 7 version;

Perform migration:

  • Try to compile (iterations) (change deprecated operators and so on);
  • Analyze data types usage;
  • Analyze pointers usage – remove or reduce pointers usage;
  • Migrate strings to Unicode;
  • Perform smoke test;
  • Go through all warnings and hints (usually warning is equal to error);

Check unit tests for the up-to-date Delphi version;

UI projects migration

Analyze and describe at least 5 unit tests for each project for key functions for no-UI parts;

Develop unit tests for Delphi 7 version;

Perform migration:

  • Open .dfm files (forms and data modules) in the text editor and fix/change any properties, class names, etc. according to Components Migration table (form should be prepared before opening in the IDE form editor, because in another case component just will disappear);
  • Chang all components class names in the .pas files where is necessary;
  • Put new components where is necessary;
  • Try to compile (iterations) (change deprecated operators and so on);
  • Analyze data types usage;
  • Analyze pointers usage – remove or reduce pointers usage;
  • Migrate strings to Unicode;
  • Perform smoke test;
  • Went through all warnings and hints (usually warning is equal to error);

Checked unit tests for the up-to-date Delphi version;

Testing (Manual, Automated)

For a common understanding of the functionality we organize all test cases in one list. After checking the tests’ relevance, it was found that many of them were obsolete and did not contain all the functionality parts. So, we expanded the initial list with the missing scenarios.

Some of the test cases that needed to be checked on a regular basis were automated. In the process of migration after finishing every phase a regression testing of the main functionality was made. In controversial cases the behaviour was compared with the unmigrated application.

Also, a special tool to test API was created. To see if the migration improved the software, a performance testing was conducted before and after the migration.


We applied the Agile software development methodology for the project migration. It gave us and to the customer the vision of the project speed, progress, deliverables and ability to test some parts in parallel to speed up the project migration itself. Our team tends to follow continuous delivery principles. Our client was completely informed of our speed, so it allowed them to increase/decrease the workload and the team scale according to each migration phase.

As far as the customer had their own established approach to the development, our team easily adapted to them to work collaboratively and productively.

As required by the agile approach we followed scrum activities such as:

Sprint planning

During that kind of meetings the team was taking the tasks for the upcoming sprint according to the task scale, difficulty and priority and approved it with the customer’s PO

Daily meetings

Day-to-day meetings where the day results, plans, questions were discussed;

Sprint grooming

The meeting where the teams validated current/valid/invalid tasks and cleaned the backlog up

Sprint demo

The session where all the company teams (more than 60 people) conducted the presentation of performed work. Almost all of the company members participated there, including top management leaders, subdivisions, etc. Each participant was able to ask any question or request some clarifications that made the communication transparent and the atmosphere warm

Retrospective session

The session where sprint results were discussed, the obtained knowledge was documented and stored for historical reasons.

On-time Reporting

Every sprint our project manager prepared bi-weekly reports to provide the customer with the project results, allotted time, tasks completion, difficulties, and any other helpful information. That approach prevented both sides from misunderstandings and allowed them to be in sync during the project timeline.


  • used in the project
  • Delphi Delphi
  • Microsoft SQL Server Microsoft SQL Server


After 1.5 years of work, our client’s team started to upgrade the updated application. This upgrade brought significant improvement of the performance and stability.

Our team got a unique experience that allowed us to increase our expertise significantly and found new friends.

Subscribe to our newsletter and get amazing content right in your inbox.

You can unsubscribe from the newsletter at any time

This field is required
This field is required Invalid email address

You're almost there...

A confirmation was sent to your email

confirm your subscription, make sure to check
your promotions/spam folder