Why this interview?
What are the biggest reasons why someone should want to perform a migration? We will find out in this interview with Vera Maruga, the business development manager at Ispirer. She will tell us a bit more about migration from the business side and she will explain us the benefits you can get from doing it.
Here there are some quotes I found particularly interesting:
The reasons for migration are different: many companies decide to move from legacy technologies to modern ones, because they feel lack of industry support of outdated languages, or because they have difficulty in finding programmers to support outdated languages, or maybe they realize the necessity to support new performance and security features of modern technologies. Another important trend that we see is moving to open source technologies.
Many people who turn to us have the opinion that the migration has more disadvantages over manual rewriting. In fact, I would like to point out the advantages of automated migration: the main advantage is speed, and if there are several hundreds of thousands or even millions lines of code, then manual rewriting of such amount of code will take a lot of time.
From our experience, I could say that using our technology allows to decrease time expenses at least four times and to decrease cost expenses at least twice.
There is such an opinion that automated migration is impossible, is ineffective, that migration of a human written code is a very complicated task. But in reality, it is possible, and thanks to the technology that underlies our product.
Federico Tomassetti: Hi, Vera, thank you for joining us today. It’s a pleasure to have the chance to talk with you. So nice to meet you.
Vera Maruga: Hi Federico, it’s a pleasure for me as well.
Federico Tomassetti: Today, we have Vera Maruga from Ispirer, that will tell us a bit more about migration, and we will look at it a bit more from the business side. With respect, we thought her interviews have been more technical, as Vera is the business development manager at Ispirer. So, she can tell us what is the experience for client doing migration with Ispirer, and why it makes sense to do that, and we can dive a bit more on her experience. So, thank you for agreeing to this interview. And yes, I want to start exactly with that, so discussing the reason for the migration. What are the biggest reason why someone should want to perform a migration?
Vera Maruga: Well, frankly speaking, the reasons for migration are different. Many companies decide to move from legacy technologies to modern ones, because they feel lack of industry support of outdated languages or because they have difficulty in finding programmers to support outdated languages or maybe they realize the necessity to support new performance, and security features of modern technologies. So, in effect, multiple factors may be the reason for the companies to search for alternative solutions. Another important trend that we see is moving to open source technologies.
Federico Tomassetti: Mm-hmm (affirmative).
Vera Maruga: Many companies choose Postgres, because it is opensource, reliable, flexible, and meets their database system requirements. And nowadays, there are many reliable support providers across the globe for this technology.
Federico Tomassetti: Do you think it’s also related to costs? I mean it’s…
Vera Maruga: Well, yes. The question of costs is also important. Many companies would like to avoid vendor lock-in and to cut the expenses that they have supporting, and maintaining paid technologies.
Federico Tomassetti: I think that maybe some listeners can wonder, why not just rewriting everything? Can you share your thoughts on that?
Vera Maruga: Well, yes, I agree. Many people who turn to us have the opinion that the migration has more disadvantages over manual rewriting. In fact, I would like to point out the advantages of automated migration. The main advantage is speed, and if there are several hundreds of thousands or even millions lines of code, then manual rewriting of such amount of code will take a lot of time.
Federico Tomassetti: Mm-hmm (affirmative).
Vera Maruga: Of course, if the amount of code is not big, and if the company has enough resources, internal resources that may be allocated for manual rewriting, then yes, this may be a viable option. On the other hand, some applications may have very high performance requirements, and the refinement of this application, of the code after automated conversion may take a lot of time. So that time and cost expenses will be comparable to rewriting from scratch. So in each case, one should decide pros and cons and take the best decision. From our experience, I could say that using our technology allows to decrease time expenses at least four times and to decrease cost expenses at least twice.
Federico Tomassetti: It seems like a good deal. I wanted to ask about some trends, but you have already named some of them like the interest to moving to open source, the desire to move away from vendor lock-in, and also the tendency of using more and more Postgres. Okay, what I would like to discuss with you is also, what kind of migration do you do? Do you do migration from one language to another, to one database to another, to a framework to another? Can you tell us a bit more about the typical projects that your company does?
Vera Maruga: Mm-hmm (affirmative). Okay. We support and help in migration tasks that include both the migration databases and the migration of applications, and we also help to migrate embedded SQL and database API. We support many directions of migration. So, if we speak about our approach to migrations, first of all, we need to determine whether the direction of migration is supported by our tool or whether it needs to be extended.
Federico Tomassetti: Mm-hmm (affirmative).
Vera Maruga: If it is one of the well-developed directions, for example, if we’re talking about databases, very popular directions are migration from Oracle to Postgres, from Oracle to Microsoft SQL Server or from Microsoft SQL Server to Postgres. So, these directions are already supported on a good level, and we may offer to purchase the license at once and use our product. If we receive some specific request, and the direction is not currently supported, in this case, we start cooperation from the proof of concept stage. The goal of the proof of concept is to check the viability of our approach. In other words, to check if it makes sense to transfer this code to this target technology, using our solution. And then we also decide if extension stage, one or several is required to prepare our toolkit for the usage by the customer.
Vera Maruga: The extension stage may also be required in the event if the direction is already supported, but the amount of code is very big. In such case, there may be a lot of places which require adding new conversion rules into our tool. So, during the extension stage, Ispirer team takes the part of the representative code, and based on this part, includes new conversion rules into the tool. After that, we deliver the customized version of the tool to the customer, and this updated version converts the code with higher level of automation. Depending on the amount of code, on its complexity, there may be more than one extension stage. But after that, usually the customer continues to convert the code using the updated version.
Federico Tomassetti: So if I understand correctly, you have a tool that can already deal with many pairs of languages conversion, or database conversion, but you have also the possibility of extending it to support better, certain clients when they have a huge code base, makes sense. Or in other cases, you could develop a support for new combination, and you do that through a POC.
Vera Maruga: Yes, yes, you’re right. We may offer the tool at once for some directions which are already supported. Then we may tune the tool to meet the specific requirements of the customer. We may add a new direction of migration and not only new direction, for example, it may be the migration to a special Java framework. If the amount of code is big enough, then it makes sense to turn to us, to convert the code to a special framework, and we will start from the proof of concept, and then continue with the extension stages to develop such a possibility, and to offer our solution.
Federico Tomassetti: I’m curious about how your user typically use your system. Do your user typically convert from some language to another language, and then start maintaining the translated code or do they keep evolving the original code, and do the migration over and over? I was curious about these things, because I’ve seen that some companies from whatever, they maybe write the translator from COBOL to Java, but then they have still, I don’t know, COBOL developers. So they keep writing COBOL and then translate. Every time they write new COBOL code, they translate to Java. While many companies instead do the translation once, throw away the COBOL code, and then they always maintain the Java code.
Vera Maruga: Usually the migration is done one time and after the migration, the customer doesn’t need our support at all. But yes, we’re seeing requests when the original system continues to exist, and continues to be developed. And yes, from time to time, the clients require our support to migrate the code that was generated afterwards. And if speaking about, for example, COBOL to Java conversion, this direction can be very well automated. And for one of our clients, it was the University of Maryland, they turned to us with the task to migrate their mainframe COBOL batch programs to Java.
Vera Maruga: The amount of code was big, and manual rewriting was considered as a very time consuming option. So they chose Ispirer and during six months engagement phase, our team prepared the tool, added new conversion rules specifically for this code. And after this tuning, the level of automation was increased up to 95% and at the end, the University migrated the code successfully. The migrated code was similar to COBOL code, which was an additional advantage, and their COBOL developers easily switched to maintaining this Java code.
Federico Tomassetti: Yeah, because that’s a good point to consider that if a company migrate, then they have also maybe to retrain developers too, to keep them around.
Vera Maruga: Yes, it’s true.
Federico Tomassetti: And regarding this project you’ve named, that the fact that it took six months, so I was curious in general, how long are these projects, from the simplest projects to the longest project, can you give us an idea?
Vera Maruga: Well, when the amount of code is not big, then yes, it may take several months to use our tool. And if the direction is already developed, then yes, the company might take our tool for three or for six months and migrate all the code, and afterwards to make the optimization and improving the performance, which are obviously the works that are performed apart from conversion. And if we speak about the projects, application migration projects, they are usually long-term, and massive and include millions lines of code. So usually they have the duration of several years, but still this is more advantageous than writing from scratch a new program.
Federico Tomassetti: I was curious if you could share some success stories. You have already nominated the University of Maryland. I was wondering, if there were other project that was particularly interesting?
Vera Maruga: Well, yes, sure. We have performed many projects during 20 years of existence of our company, and so more than 1000 happy customers are in our portfolio. Though many of them have increased confidentiality requirements, and our team is always ready to meet such requirements, and we are flexible. For example, some years ago, we were contacted by one US based company, a software provider and they have very high security requirements. But at the same time, their task was to migrate about one million lines of Progress 4GL code. And after the successful proof of concept, our team worked for about two years on client’s premises. So all the works were done on-site. They analyzed the code, and created new conversion rules, and received their updated tool, made the conversion and implemented the result in the production system. And all these works were done on client’s premises. So we’re ready to meet any specific requirements of the client.
Vera Maruga: Another case study is about the migration from Oracle to Microsoft SQL Server, which was performed for one of our European customers. Though this direction of migration is already supported on a good level and a very high level, the code of this client contained many geometrical objects, and our company extended the tool to support the automated migration of these geometrical objects, and afterwards, the tool was ready to perform such automated migration. In this project, the time frame was crucial for the customer and our team managed to perform this tech challenge within a couple of months. And our customer admitted that an outstanding result of migration allowed them to significantly reduce time and cost on this project.
Federico Tomassetti: Yeah, congratulations. And so you say, you’ve talked about clients in US and Europe. Are you working with clients all over the world or in specific areas?
Vera Maruga: Exactly, exactly. We work with the clients all over the world.
Federico Tomassetti: And where are you based?
Vera Maruga: Well, the headquarters of our company is in the United States, but most of the development team is in Eastern Europe.
Federico Tomassetti: Okay. So distributed team, good. And other things maybe we could discuss is, what are the most difficult challenges you face? So what are the situations that make more difficult to perform migrations?
Vera Maruga: Speaking about the disadvantages of automated migration, I should tell you that there are situations, when it is not viable option.
Federico Tomassetti: Mm-hmm (affirmative).
Vera Maruga: For example, when the source and the target technology differ greatly. It happens from time to time when the customer has the task to migrating a desktop application to a Web one. Also, there are desktop specific constructions, which are implemented in a different way in Web. And there is simply no automatic solution for such transfer. So in this case, it is very difficult to achieve high level of automation. And that is why we recommend to start from the proof of concept, because this rather small stage, allows to check if we are able to help or if it’s better to find another option or maybe to choose another target technology.
Federico Tomassetti: And can you tell us a bit more about your typical client. If you work typically with large companies or you work with companies in specific industries? We have already seen that you are not working with clients in a specific country, because you work with clients from all over the world, but just to give some more idea of who should contact you.
Vera Maruga: Our typical client is the company that understands the need for migration. So we work with companies which represent all essential industries, insurance, finance, banking, transportation, manufacturing, virtually any company requires our support on its way to modern technologies. So, we are ready to help the companies of different sizes. If we speak about database migration, then our typical client is a medium size company, and if we speak about application conversion, then as long as such projects are long-term and massive, they are usually performed for big enterprises.
Federico Tomassetti: Yeah. I see. You said that one requirement is that your client already understand the need for migration. So in your case, when the clients contact you, they already know they need the migration. It’s not you explaining to them that they need the migration, right?
Vera Maruga: Yes, usually that’s correct. We don’t know all the factors that may influence on such decision. Of course, from our side, we help to describe the advantages and disadvantages. We show our solution, we give the trial version to make the decision if our product is the best fit. But no one, except for the management of the company, is able to take such decision, whether the migration is the best option or whether they should consider something else.
Federico Tomassetti: And do you think that many companies are aware that it’s possible to perform automatic migration or…
Vera Maruga: Yes, you know there is such an opinion that automated migration is impossible, is ineffective, that migration of a human written code is a very complicated task. But in reality, it is possible, and thanks to the technology that underlies our product. So, the conversion is performed in several steps. At first, the code is parsed and we get a complete syntax tree of the input object. And the tree is stored in XML format. Then a set of conversion rules for transformation from source technology to target technology is applied, and we also receive an XML tree, object representation in the target technology. Such step-by-step conversion process allows to collect the information about all the relationships, and dependencies in the project, and as a result we receive high quality and flexible migration. So, thanks to our unique technology, it is possible to achieve very good results when we speak about automated migration.
Federico Tomassetti: Good, good. Of course, at least 1000 companies know that automated migration are possible. I was just curious, if some companies may be could benefit from it, they just don’t know that it exists. So they don’t look for a solution. This is also why I try to write about these topics and try to build more awareness. Do you think that in this field, there are many competitors?
Vera Maruga: Well, we have competitors. Some of them have their solution for only one direction of migration, and some of them offer professional services for migrating the code, but still we believe that we have advantages over them. The main advantage is that we support many technologies, and are able to add the new directions of migration. The second advantage is customization, that our technology is flexible, and we may even add the migration to some Java frameworks, for example. And our unique technology that underlies our product, which is able to consider all the dependencies in the project while conversion, it allows to show high quality of migration. So, we believe that, we are able to meet their highest demands, and to help to perform the migration with as much rate of automation as it is possible to achieve.
Federico Tomassetti: If I understand correctly, you have a solution that is extensible. It’s based on a product, but this product is extensible. In addition to that, you can combine it with specific services. So you can help the client, you don’t give to them just the tool, but you are also able to extend the tool, and to support them in using the tool.
Vera Maruga: Correct. Our tool is in continuous development, and during the projects, we enhance it. We improve our tool and during the license validity period, if we speak about selling the licenses, we always offer our support. So our clients may turn to us with any questions they come across during this process.
Federico Tomassetti: Okay. I think we ask you, your opinion on many topics. I would like now to conclude with a couple of questions, and I would like to ask how can someone get start working with you? So, what should someone do to work with Ispirer?
Vera Maruga: Well, it’s easy to find us in the Web. The person may simply go to our website, www.ispirer.com, and our site contains not only information about us, but contains many pages devoted specifically to various directions of migration. The information is about what we can offer. There is videos with showing how our tool is used, testimonials of our happy clients. Then there is the possibility to request the 30 day free trial and use our product. The possibility to request free assessment tool that collects the information about the source code, and the possibility to request any further info by completing contact form. Once the contact form is completed, you will be contacted by our representative very shortly.
Federico Tomassetti: Perfect. Is there anything else that you want to add?
Vera Maruga: Well, in general, yes, I think that we covered the main topics that we wanted. Of course, there are many people who still have doubts of whether the migration is possible, and whether the automated migration is the best way for solving their tasks. And we are ready to discuss each case individually, and to offer our support on the way to modern technologies, to anyone who has such a need.
Federico Tomassetti: Okay. So I think we answered a few questions. So hopefully who is interested in migration will now have a better idea of what is possible. So I would like to thank you very much for your time.
Vera Maruga: Thank you very much for this opportunity, and we also hope that thanks to this interview, more people will be aware of that possibility to migrate automatically.
Federico Tomassetti: Okay. Thank you. Bye.
Vera Maruga: Okay. Bye.
Parsing: Tools and Libraries