Application Migration - Myths and Reality

Prehistory

It is not a secret for any experienced IT professional that most large enterprises, both of our vast Motherland and in all other parts of the world where there are IT professionals and large enterprises, have accumulated quite a large baggage of various software systems developed for the enterprise, and often - at the enterprise itself.

The oldest systems that are still in use may already be 15-20-25 years old - many of them have been written on FoxBASE for DOS and have been constantly expanding since then. Some, of course, migrated, gradually, in FoxPro for DOS, and the luckiest - even in FoxPro for Windows and beyond - Visual FoxPro.

Systems 15-20 years ago are often written in Delphi, some were transferred from version to version, but most of the Delphi systems remained on the last Borland versions, that is, Delphi 6/7.

Currently 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 about it ?!”. After all, the old platforms / development tools are no longer supported (the same FoxPro), the programs themselves start to work poorly on modern operating systems (if this is FoxPro for DOS, then there are no comments at all), the old operating systems should be installed on new hardware too. Well, the main problem is that there are fewer and fewer in the labor market that know the old languages ​​well and can maintain the system qualitatively.

Sooner or later, there is an understanding that it is necessary to switch to modern platforms, and here a new problem arises - cost, both in terms of 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.

Cost of

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 this year in 2001. It was about a “small” system that a team of 10 VERY advanced programmers have been developing for 13 years. The code, in approximate estimates, was more than 10 million lines.

And now a little math: on average, a good programmer can rewrite manually 30 (yes, thirty) lines of code in a day. And not any programmer. Here it is necessary:

1. Good knowledge of the platform to which the code is being transferred;
2. At a minimum, a good knowledge of the platform from which the code is transferred.

In principle, I met people who could work more productively on 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 once in a lifetime).

For the rest, the above figure in 30 lines of code / 8 hours is an average.

So, using the example of the system from 2001, we calculate: 10 000 000/30 * 8 = 2 666 666, 6 (6) man-hours, which is approximately equal to 11 000 1388.8 (8) man-years. Even if we consider that such a programmer has to pay 40,000 rubles per month (480,000 per year + taxes = about 700,000 rubles per year), we multiply by 11,000 1,400 (rounded) . Ummm It turns out 14 * 7 * 1 000 000, that is, 7.7 billion 980 million rubles only salaries and taxes!

Suppose the enterprise does not have such a huge system and it contains “only” 1 million lines of code. In addition, let us assume that an enterprise will find 5-6 really super programmers who will rewrite a project with an average speed of 300 lines of code per day (the figure is absolutely unreal — 40 lines per hour is possible only when writing an algorithm “from the head” who thought over for a long time, but then this time is superimposed on thinking, and there are not too many such algorithms, and the average speed is important for us). Then the project costs will fall about 30-40 times (such supers need to pay more), but there will still be 100 person-years, which will stretch for a period of 20 calendar years to 2.8 calendar years at a cost of, for example, 200 000 000 (two hundred million) 20 000 000 (twenty million) on, again, salary + taxes.

The result of the calculations can be expressed simply: a really large system can be rewritten by hand, of course, possible, but the cost and terms are absolutely unreal.

Timing, 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 bad modularity), the lower the efficiency of each particular developer. Lost a lot of time for coordination. And here the collective productivity growth from the number of developers is not linear, but rather logarithmic.

What to do?

What to do? There are several ways out of the situation.

For some companies, the transition to ready-made solutions will do, since they are enough - here is Axapta, and 1C: Enterprise, and Galaxy, and much more.

Someone generally enough to properly configure SharePoint + Office 365, for example.

But what about those who have systems that go beyond the standard ones?

Below are a few solutions.

Deep customization of ready-made solutions with code portions transfer

In principle, there are enough integrator companies on the market that can customize the finished boxed system to the client’s needs. Leaving behind the scenes is that some of the 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 amount, there are many non-standard "chips" in it, or people who are oriented in it and will be able to clearly identify small parts of the code that are responsible for these very features are not - we are almost slipping into the case rewriting "pens". Similarly, you need to look for the code, transfer it and integrate it with the finished system.

Setting up ready solutions for TK

There is still a certain number of enterprises that can make up competent TK for additional functions, choose a suitable platform. Then they will be able, with relatively little blood and with their (or integrator / outsourcing) forces, to refine the appropriate “boxed” platform to suit their needs, but the number of such companies is not enough - there are not really competent task designers and TOR writers everywhere.

And the rest?

Consider the most frequent option:

1. The enterprise has a large system that has been working in the enterprise for many years, there are source codes for the system;
2. Of the original developers of the system, no one is left, or the rest are sabotaging the process of transferring the system, since they will cease to be "irreplaceable";
3. The system does not fall "easily and quickly" on the function of ready-made boxed solutions;
4. The system has a huge data set that needs to be saved;
5. The system has a large number of users who are used to the old look of the system and the layout of the Gui elements;
6. There are no crowds of mega-super-developers in the company who could write 1000 code at least 100 lines per day in the process of transferring code from platform to platform for food at reasonable, ridiculous money for a popular programmer.

It looks very sad. There are many such enterprises and systems, but there seems to be no solutions, all of the above does not work:

1. To rewrite with hands is long and very expensive
2. Ready solution - quickly, affordable, but you can lose the old data (or part) and part of the functionality, the interface is likely to be unusual for users;
3. Adapted ready-made solution - either we get all the problems of the first option when adapting / configuring / adding, or we slip to the second solution.

In fact, as I was surprised to find out in 2009, there is a solution, it was invented back in (now) 2000 and it consists in the automatic migration of data and application source code. And yes, contrary to the opinion of the majority, this decision is quite working and carries a HUGE benefit to the company that goes to it.

Automatic migration

Automatic migration is rather complicated in terms of initial development, but a very fast and high-quality service for the end user.

Let's consider in more detail.

Data migration

Here, everything is more or less forgiven and does not cause any major complaints - almost always the data intended for older systems can be transferred to modern platforms (Oracle, MS SQL, in exotic cases - to the post-SQL database).

For many bundles, there are ready-made solutions (for example, MS SQL Data Transformation Wizard, Borland DataPump, etc.) when the solution is more complex than usual. You can adapt what you have, or write a small pump-application that will transfer data. I think that it is not necessary to dwell on this point.

Code migration

This item just causes the main skepticism in the IT-community. The truth most often objections are of the form:

• “If this were possible, I would know about it and generally be able to do it myself” - here you can only recall the bike about Columbus and the egg;
• “Yes, I will quickly rewrite it myself with my hands” - we reread the point about rewriting and especially the cost and terms of work.

In fact, almost all the objections are reduced to the above.

So how does it work?

It's 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.

Looks easy? Yes.

Then look deeper.

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 parsing and analyzing the code. In fact, exactly the same as with the usual broadcast, but then everything is more complicated. Programming languages ​​are different, the constructions of one do not always easily fall on the constructs of the other, and this problem is also difficult to solve.

The first converters simply modified the source code through RegExp'y, which left a very large scope 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 - links and other things will not. This is information for reflection for those who have the task of transferring a large system to a modern platform.

UPD

In the comments, it was reasonable to point out errors in the calculations - they are now marked as crossed out incorrect values, and behind them italics are new - correct . Many thanks to the gentlemen erp_shnik and asis - thanks to their attentiveness corrected. In general, the order of numbers still does not change the output. (in the second correction there will be a justification).

UPD2

In response to a lot of comments (special thanks to the gentlemen vladsharikov , lair , berez for constructive questions and clarifications), this week a second article will be written - examples of the converted code will be given there.

UPD3

Here is the second article , with examples of code conversion and GUI.