Application Migration - Myths and Reality
It is not a secret for any experienced IT professionals that at most large enterprises both in our vast country and in all other parts of the world where there are IT professionals and large enterprises, quite a lot of different software systems developed for the enterprise have accumulated, and often - at the enterprise itself.
The oldest systems that are still in operation may already be 15-20-25 years old - many of them are still written in FoxBASE for DOS and have been expanding ever since. Some, of course, migrated, gradually, to FoxPro for DOS, and the luckiest - even to FoxPro for Windows and beyond - Visual FoxPro.
Systems of 15-20 years ago are often written in Delphi, some were translated from version to version, but most Delphi systems remained on the latest Borland versions, that is, Delphi 6/7.
At the moment, there are a huge number of similar systems developed on old or not old, but not the most convenient software platforms / programming languages (the above languages are just examples).
The main headache for the IT departments of such enterprises is “what to do with this ?!” After all, the old platforms / development tools cease to be supported (the same FoxPro), the programs themselves begin to work poorly on modern OSs (if this is FoxPro for DOS, there are no comments at all), installing old OSs on new hardware is also problematic. But the main problem is that in the labor market there are fewer and fewer ones that know old languages well and can qualitatively support the system.
Sooner or later, an understanding arises that it is necessary to switch to modern platforms, and here a new problem arises - cost, both in money and in time.
For those who are interested in this problem - under the cat a more detailed description of why rewriting systems is expensive and what to do with old systems.
At first glance, it seems that rewriting the finished system is not a problem, because there is all the code. “And let's quickly“ rewrite it to Java “- and that’s it!” The first time I heard such a statement was that year in 2001. It was a “small” system that a team of 10 VERY advanced programmers had been developing for 13 years. The amount of code, according to approximate estimates, was more than 10 million lines.
And now a little math: on average, a good programmer can manually rewrite 30 (yes, thirty) lines of code in a day. And by no means any programmer. Here it is necessary:
- Good knowledge of the platform on which the code is ported;
- At a minimum, good knowledge of the platform from which the code is ported.
In principle, I met people who could work more productively under the condition of a 16-hour working day, excellent knowledge of both platforms and personal interest in the project (the person was at the same time the ideologist of the old system, the owner of the enterprise and the ideologist of the new system - I met only one such “alloy” once in a lifetime).
For the rest, the above figure of 30 lines of code / 8 hours is the average value.
So, using the example of a system from 2001, we calculate: 10,000,000 / 30 * 8 = 2,666,666, 6 (6) man-hours, which is approximately equal to
Suppose the enterprise does not have such a huge system and it contains “only” 1 million lines of code. In addition, suppose that the company finds 5-6 really super programmers who will rewrite the project with an average speed of 300 lines of code per day (the figure is absolutely unrealistic - 40 lines per hour can only be written when you write the algorithm “from the head”, who thought it over for a long time, but then it’s the time to think it over, and there are not too many of these algorithms, but average speed is important to us) Then the costs of the project will fall by about 30-40 times (such supermen need to be paid more), but still there will be 100 man-years, which, with a team of 5 people, will stretch for
The result of the calculations can be expressed simply: a really large system can be rewritten by hand, of course, but the cost and terms are absolutely unrealistic.
Dates, in theory, can be shortened, but we must not forget that the larger the team of developers working on the same code (and older systems often have very poor modularity), the lower the effectiveness of each particular developer. A lot of time is lost on coordination. And here the growth of team productivity from the number of developers is not linear, but rather logarithmic.
What to do?
What to do? There are, of course, several solutions to the situation.
For some companies, the transition to ready-made solutions is suitable, since there are enough of them - here are Axapt, and 1C: Enterprise, and the Galaxy, and much more.
For some, the correct configuration of SharePoint + Office 365, for example, is enough.
But what to do for those whose systems go beyond the standard?
Below are some solutions.
Deep customization of turnkey solutions with the transfer of code sections
In principle, there are enough integrator companies on the market that can customize the finished box system to customer needs. We leave behind the scenes that some boxed solutions live very poorly with a large amount of data / number of transactions. Consider only the fact that if the old system has a large volume, there are a lot of non-standard “chips” in it, or there are no people who orient themselves in it and can clearly identify small sections of code that are responsible for these features - we slide into almost the case rewriting "pens". In the same way, you need to look for the code, transfer it and integrate with the finished system.
Setting up ready-made solutions for TK
There is still a certain number of enterprises that will be able to compose competent TOR for additional functions, to choose a suitable platform. Then they will be able, with relatively little blood and with their (or integrator / outsourcing) forces, to finalize a suitable “boxed” platform for their needs, but the number of such companies is small - not always there are really competent task managers and TK writers.
And the rest?
Consider the most common option:
- The enterprise has a large system that has been operating in the enterprise for many years, there are source codes for the system;
- Of the original developers of the system, there is no one left, or those remaining sabotage the process of transferring the system, since they will cease to be "indispensable";
- The system does not fall "easily and quickly" on the functions of ready-made box solutions;
- The system has a huge set of data that must be stored;
- The system has a large number of users who are used to the old appearance of the system and the layout of Gui elements;
- The company does not have the crowds of mega-super-developers who could write the code of
1000at least 100 lines per day in the process of porting code from one platform to another for a mealfor a reasonablefunny for money lubogo programmer.
It looks very sad. There are many such enterprises and systems, but there seem to be no solutions - all of the above does not apply:
- Handwriting is long and very expensive;
- A ready-made solution is fast, affordable, but you can lose old data (or part) and part of the functionality, the interface will most likely be unusual for users;
- Adapted ready-made solution - either we get all the problems of the first option when adapting / configuring / adding, or we slide into the second solution.
In fact, as I was surprised to learn in 2009, there is a solution, it was invented in the distant (now) 2000 year and it consists in the automatic migration of data and application source texts. And yes, contrary to the majority opinion, this decision is quite working and brings a HUGE benefit to the enterprise that goes to it.
Automatic migration is quite complicated in terms of initial development, but very fast and high-quality service for the end user.
Let's consider in more detail.
Here, more or less forgive and does not cause big complaints - almost always the data intended for old systems can be transferred to modern platforms (Oracle, MS SQL, in exotic cases - to post-SQL database).
For many bundles, there are ready-made solutions (for example, MS SQL Data Transformation Wizard, Borland DataPump, etc.) in the case when the solution is more complicated than usual. You can adapt what is, or write a small pump application that will transfer data. I think that it’s not necessary to dwell on this point.
This point just causes the main skepticism in the IT community. True, most often objections are:
- “If it were possible, I would know about it and would know how to do it myself” - here you can only recall the story about Columbus and the egg;
- “Yes, I’ll quickly rewrite it myself with my hands” - re-read the item on rewriting, and especially - the cost and terms of work.
In fact, almost all the objections boil down to the above.
So how does it work?
Everything is very simple - the source text, on the old platform, is translated into text on the new platform. In some cases, a migration library is added.
Does it look simple? Yes.
Then take a deeper look.
In fact, the development of such a translator is often more complicated than the development of a classical translator from PL to machine code. The first part of the work is code parsing and analysis. In fact, it is exactly the same as with a normal broadcast, but then everything is more complicated. Programming languages are different, the designs of one do not always fit easily on the designs of the other, and this task is also difficult to solve.
The first converters simply modified the source code through RegExp, which left a lot of room for manual work. The current generation of converters performs a full translation of the source code into the new source code.
Since this publication does not carry direct advertising information - there will be no links and other things. This is precisely the information for reflection for those who have the task of porting a large system to a modern platform.
The comments reasonably pointed out errors in the calculations - they are now marked as
In response to many comments (special thanks to gentlemen vladsharikov , lair , berez for constructive questions and clarifications), this week a second article will be written - there will be examples of converted code.
Here is the second article , with code conversion and GUI examples