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 the 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 for 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.
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.
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 always be 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.
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?
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 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 (at Softacom, we offer such services as well), 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 the necessity of migration.Here’s a short questionnaire for you.
- Do you want to be able to fully plan your time and manage it?
When that’s you (not external factors) who is an initiator of the migration you can plan your time and conduct all the necessary processes without any hurry.
- Do you want to be sure that your business processes will be going on without interruptions? .
If the migration is carefully planned and integrated into your business plan, it won’t stop your business activities. Can you imagine that unless some important updates are performed timely your ongoing processes can be fully paralyzed for an indefinite period of time?
- Do you want to have experts who are able to work with your software in your team?
Of course, working with code written by somebody else can be a rather challenging task, especially when we talk about legacy software. And it is not a secret, that the longer you postpone migration, the less chances you will have in the future to find experts to work with your apps.
- Do you care about your corporate reputation?
Do you agree that it’s better to conduct all the migrations on a pre-planned basis than urgently when your business is at risk? If urgent migration or some issues related to old software stop your business, be ready that you will need to work hard to restore your reputation.
If you have answered “yes” to all the questions above, the necessity to think about migration is obvious.
In case you are not sure that you are ready to proceed to the legacy software migration right now, you may start with the business analysis to estimate potential risks and possible investments. You can delegate this task to us or fulfill it on your own. In case you decide to conduct this analysis without our help, let us recommend you a few points to pay your special attention:
- technical issues that you have;
- third-party components that are applied to your software (you need to find appropriate components for a new Delphi version if the used ones are not supported any more);
- possible plan of migration and its cost.
Do you have doubts or need more arguments? Or maybe you are still not sure that migration is the right solution for you? Do not hesitate to contact and get answers to all your questions.