Timely migration as the way to keep everything under control
Natali Pilko
Natali Pilko
[SHOWTOGROUPS=3,4,5,20]
Timely migration as the way to keep everything under control
Natali Pilko
It’s better to invest in migration now than to lose $200K later
That’s not just a loud headline. That’s the reality. And here is why.
Have you ever thought that migration of legacy Delphi projects to up-to-date Delphi versions conducted before real problems with your software start will help you to prevent the majority of these problems at all?
It is not a secret that when it comes to software development we need to be proactive and to take all the preventive measures beforehand (select right development tool, framework, components list, APIs and SDKs, correct architecture and so on). Of course, prevention may not always be possible. But at least we should be ready to deal with any issues when they appear.
If you still use software built with Delphi at least 5-7 years ago, you should be very attentive and regularly monitor whether it still provides support of all the necessary APIs, libraries and security protocols. Otherwise, you’ll be in trouble. And of course, you should be extremely attentive to all these things if you use apps created with Delphi 5 or Delphi 7. If you think that there are no reasons to worry yes, let’s have a look at the following examples from our practice.
Situation 1
One of our clients that works in the retail industry had a mobile app developed with Delphi 10 Seattle. Yes, it was not a very old version of Delphi but not the latest one at the same time. So, it already lacks some important features. For authorization the mobile app used Facebook API. And this was the point when the problems began. As you may remember, in 2018 the Facebook–Cambridge Analytica scandal took place. Facebook was accused of misusing users’ private data. Due to these problems with privacy and the authorities, Facebook enforced all mobile apps to use the freshest versions of Facebook SDK. It was a crucial requirement. Facebook SDK wasn’t supported by the client’s version of Delphi, though in the latest versions it was already available. Facebook set a deadline for updating apps but this time frame was not enough for our client. Even though the developers were working hard, they didn’t manage to conduct the upgrades before the date that was set by FB as, first of all, they needed to migrate their app to a fresher version - Delphi 10.3 Rio. As a result, users of the app lost the possibility to pass through the procedure of authorization and couldn’t use the app. The business activity for the company was practically paralyzed for 15 days. The estimated losses totaled $100-200k. And this amount is only losses from directs sales if compared with the same periods of the previous years. Here the client didn’t take into account his indirect losses, including lost users, absence of newcomers, marketing issues and related expenses. However, it wouldn’t have happened (or all the losses would have been minimized), if the client had conducted the migration to the fresher Delphi version at least one month before.
Situation 2
Other technical issues may arise due to the problems related to the support of multiple languages when Unicode is not available. Theoretically, such problems can be always solved. For example, we can always offer to change some Windows Registry settings (code page for necessary charset, font size scale for high-dpi screens, OS backward compatibility and so on). But even some small changes may result in incorrect functioning of other programs. Have you heard about the domino effect? Something similar may happen. One portion of changes may require the second one, the second one will result in the necessity of other upgrades and so on. So, in such a way you may create problems on your own. Do you want to get them? We do not think so. And please, do not forget that new upgrades lead to new investments.
Situation 3
Probably, you know about the problems with incompatibility of data type sizes of 32-bit and 64-bit programs that may result in a row of inconveniences for your developers when it comes to inter-program communications? Errors in adding data to the fields of databases and using API are practically inevitable.
Moreover, as we work closely with legacy software we know that it is a common situation these days when clients require 64-bit support and companies start losing important contracts just because their apps do not correspond to the modern standards. In such a case there is the only choice - to migrate your software urgently in order not to lose the market competition.
Last year a German company that manufactures electronic devices turned to our migration services after they had lost a $1.5 million deal. The technical experts from the side of the potential partner had a rather biased approach towards the product. They believed it was not “modern” enough due to the lack of 64-bit support. As a result, the company has not only lost an important client but also got a serious hit in its reputation.
You may say that it is just a single case. But are you ready to take the responsibility for such consequences?
Situation 4
The next example is applicable to those cases when the software requires regular custom-tailored upgrades for your clients. All the upgrades and updates should be introduced quickly and efficiently. And of course, they should satisfy the modern requirements of security, productivity, and architecture. If you recognize your situation in this short description, you definitely know the pain related to the efficiency of these upgrades.
The support of the legacy code is a quite challenging task. Some months ago we got an inquiry from the U.S.-based retail market agency. The company was using the software that had been developed 12 years ago. The functionality was quite satisfactory and within all these years the in-house tech expert was able to introduce the necessary updates. But when this specialist decided to leave the company, the problems began. The agency just couldn’t find a person who had appropriate knowledge and skills to work with that legacy code.
The older your legacy code is, the lower are the chances that you have in your team the same experts who wrote it. For instance: You can use obsolete components without support and source code - you just cannot fix the errors easily. Some component vendors can even not exist and in case of some improvement requests from your customers you won’t be able to add improvements quickly. Also, legacy code usually was written without OOP best practices and principles, programming language could be obsolete and you will spend more time for writing the code because of code duplication, spaghetti-code and so on.
Not all specialists today are good at working with an old code that was written 15 years ago. Why? - Because modern programming languages notices (including modern Object Pascal version) have a lot of improvements. For many developers it will be a big psychological problem to take a step back, especially for young and talented developers. If you turn to third-side experts to work with your legacy code, you should know that the maintenance of old software is more expensive than in the cases when we have a fresher code. Why? - Because legacy code can be not compatible with modern communication standards and we will need to search alternative solutions, search components for legacy versions, which maybe don’t exist at all or rewrite everything from scratch.
This list can be much longer. But we believe that you already can imagine what technical issues may become an obstacle for your own project if the migration is not conducted in time.
However, let us remind you that your software, your applications (especially if we are talking about those ones that you provide to your clients) is the face of your company. Though we all know that we shouldn’t judge a book by its cover, we always do it when it comes to software products: we pay special attention to how an app looks and feels. And of course, you know that an app that was built 15 years ago can’t look up-to-date. Many new features that users today are accustomed to are unavailable for those who use old versions of Delphi. And to meet their expectations you have nothing to do but to conduct the migration sooner or later.
The quality and state of your software is an important part of the reputation of your company. And of course, it is clear that you do not want to spoil it (as it takes only a couple of minutes and 0 dollars to destroy it and you may need long years and significant investments for its recovery).
To cut the long story short, we offer you take a look at this checklist of factors that you need to bear in mind when you are considering a necessity of migration.Here’s a short questionnaire for you.
If you have answered “yes” to all the questions above, the necessity to think about migration is obvious.
[/SHOWTOGROUPS]
Timely migration as the way to keep everything under control
Natali Pilko
It’s better to invest in migration now than to lose $200K later
That’s not just a loud headline. That’s the reality. And here is why.
Have you ever thought that migration of legacy Delphi projects to up-to-date Delphi versions conducted before real problems with your software start will help you to prevent the majority of these problems at all?
It is not a secret that when it comes to software development we need to be proactive and to take all the preventive measures beforehand (select right development tool, framework, components list, APIs and SDKs, correct architecture and so on). Of course, prevention may not always be possible. But at least we should be ready to deal with any issues when they appear.
If you still use software built with Delphi at least 5-7 years ago, you should be very attentive and regularly monitor whether it still provides support of all the necessary APIs, libraries and security protocols. Otherwise, you’ll be in trouble. And of course, you should be extremely attentive to all these things if you use apps created with Delphi 5 or Delphi 7. If you think that there are no reasons to worry yes, let’s have a look at the following examples from our practice.
Situation 1
One of our clients that works in the retail industry had a mobile app developed with Delphi 10 Seattle. Yes, it was not a very old version of Delphi but not the latest one at the same time. So, it already lacks some important features. For authorization the mobile app used Facebook API. And this was the point when the problems began. As you may remember, in 2018 the Facebook–Cambridge Analytica scandal took place. Facebook was accused of misusing users’ private data. Due to these problems with privacy and the authorities, Facebook enforced all mobile apps to use the freshest versions of Facebook SDK. It was a crucial requirement. Facebook SDK wasn’t supported by the client’s version of Delphi, though in the latest versions it was already available. Facebook set a deadline for updating apps but this time frame was not enough for our client. Even though the developers were working hard, they didn’t manage to conduct the upgrades before the date that was set by FB as, first of all, they needed to migrate their app to a fresher version - Delphi 10.3 Rio. As a result, users of the app lost the possibility to pass through the procedure of authorization and couldn’t use the app. The business activity for the company was practically paralyzed for 15 days. The estimated losses totaled $100-200k. And this amount is only losses from directs sales if compared with the same periods of the previous years. Here the client didn’t take into account his indirect losses, including lost users, absence of newcomers, marketing issues and related expenses. However, it wouldn’t have happened (or all the losses would have been minimized), if the client had conducted the migration to the fresher Delphi version at least one month before.
Situation 2
Other technical issues may arise due to the problems related to the support of multiple languages when Unicode is not available. Theoretically, such problems can be always solved. For example, we can always offer to change some Windows Registry settings (code page for necessary charset, font size scale for high-dpi screens, OS backward compatibility and so on). But even some small changes may result in incorrect functioning of other programs. Have you heard about the domino effect? Something similar may happen. One portion of changes may require the second one, the second one will result in the necessity of other upgrades and so on. So, in such a way you may create problems on your own. Do you want to get them? We do not think so. And please, do not forget that new upgrades lead to new investments.
Situation 3
Probably, you know about the problems with incompatibility of data type sizes of 32-bit and 64-bit programs that may result in a row of inconveniences for your developers when it comes to inter-program communications? Errors in adding data to the fields of databases and using API are practically inevitable.
Moreover, as we work closely with legacy software we know that it is a common situation these days when clients require 64-bit support and companies start losing important contracts just because their apps do not correspond to the modern standards. In such a case there is the only choice - to migrate your software urgently in order not to lose the market competition.
Last year a German company that manufactures electronic devices turned to our migration services after they had lost a $1.5 million deal. The technical experts from the side of the potential partner had a rather biased approach towards the product. They believed it was not “modern” enough due to the lack of 64-bit support. As a result, the company has not only lost an important client but also got a serious hit in its reputation.
You may say that it is just a single case. But are you ready to take the responsibility for such consequences?
Situation 4
The next example is applicable to those cases when the software requires regular custom-tailored upgrades for your clients. All the upgrades and updates should be introduced quickly and efficiently. And of course, they should satisfy the modern requirements of security, productivity, and architecture. If you recognize your situation in this short description, you definitely know the pain related to the efficiency of these upgrades.
The support of the legacy code is a quite challenging task. Some months ago we got an inquiry from the U.S.-based retail market agency. The company was using the software that had been developed 12 years ago. The functionality was quite satisfactory and within all these years the in-house tech expert was able to introduce the necessary updates. But when this specialist decided to leave the company, the problems began. The agency just couldn’t find a person who had appropriate knowledge and skills to work with that legacy code.
The older your legacy code is, the lower are the chances that you have in your team the same experts who wrote it. For instance: You can use obsolete components without support and source code - you just cannot fix the errors easily. Some component vendors can even not exist and in case of some improvement requests from your customers you won’t be able to add improvements quickly. Also, legacy code usually was written without OOP best practices and principles, programming language could be obsolete and you will spend more time for writing the code because of code duplication, spaghetti-code and so on.
Not all specialists today are good at working with an old code that was written 15 years ago. Why? - Because modern programming languages notices (including modern Object Pascal version) have a lot of improvements. For many developers it will be a big psychological problem to take a step back, especially for young and talented developers. If you turn to third-side experts to work with your legacy code, you should know that the maintenance of old software is more expensive than in the cases when we have a fresher code. Why? - Because legacy code can be not compatible with modern communication standards and we will need to search alternative solutions, search components for legacy versions, which maybe don’t exist at all or rewrite everything from scratch.
This list can be much longer. But we believe that you already can imagine what technical issues may become an obstacle for your own project if the migration is not conducted in time.
However, let us remind you that your software, your applications (especially if we are talking about those ones that you provide to your clients) is the face of your company. Though we all know that we shouldn’t judge a book by its cover, we always do it when it comes to software products: we pay special attention to how an app looks and feels. And of course, you know that an app that was built 15 years ago can’t look up-to-date. Many new features that users today are accustomed to are unavailable for those who use old versions of Delphi. And to meet their expectations you have nothing to do but to conduct the migration sooner or later.
The quality and state of your software is an important part of the reputation of your company. And of course, it is clear that you do not want to spoil it (as it takes only a couple of minutes and 0 dollars to destroy it and you may need long years and significant investments for its recovery).
To cut the long story short, we offer you take a look at this checklist of factors that you need to bear in mind when you are considering a necessity of migration.Here’s a short questionnaire for you.
- Do you want to be able to fully plan your time and manage it?
- Do you want to be sure that your business processes will be going on without interruptions? .
- Do you want to have experts who are able to work with your software in your team?
- Do you care about your corporate reputation?
If you have answered “yes” to all the questions above, the necessity to think about migration is obvious.
[/SHOWTOGROUPS]
