Past webinar recording:

The webinar is called “migration of legacy Delphi projects to up-to-date Delphi versions” and we will talk about whether it has sense to migrate to Delphi, up-to-date versions, or it maybe we have to choose another technology. In the beginning I'd like to say a couple of words about me, about our company. We're specializing in applications re-engineering, applications enhancement and, of course, migration. Of course, there are a lot of different migration types and we will talk later today about these types. Anyway, we are also specializing in Delphi development. I think that I can even call myself a Delphi evangelist. This is why I'm leading this webinar. Also in the end of the webinar I suggest if you have any questions you can ask them. Not during the webinar, because maybe they will interrupt it and I will explain something that is not interesting for the others. Also I'd like to say something about the webinars’ focus group. It was prepared more for the people that are not really tech savvy, not for the developers. Here I won't explain exact migration tricks or migration steps, like which class we have to change, which one is obsolete and so on. Here today we will discuss what's the best way for migration of legacy Delphic projects, how to make a decision, which risks do we have and so on.

Okay, I suggest you discuss today's plan. In the beginning I’ll just say a couple of words about what is the role of Delphi right now and in the past, why should we still use Delphi. Also we will discuss what is the best way: migration to new up-to-date Delphi versions, like Tokyo/Rio, or maybe it doesn't have sense and we have to go to another technology. Also I hope I won't be too boring because my colleagues asked me to tell jokes. I will try. Next we will discuss a roadmap how to migrate from Delphi 5 and 7 versions to the up-to-date versions. I will provide some real cases. Of course, we will discuss a couple of new features and capabilities of new Delphi versions. Because we have to provide an evidence for people, for decision-makers, that right now Delphi is a relevant technology and we still have to use it. And then I prepared some questionnaires that will help us make a final decision on what to do. For example, migrate to Delphi, to new versions, or maybe select some intermediate solution, or maybe even select something totally different. Let’s move on.

What is Delphi today? In the beginning it's like an independent tool. When I'm talking about independent, it means that it does not belong to any operation system producer, it's not like native technology, for example like Visual Studio for Microsoft, Xcode for Apple or Android studio for Google. Delphi was very very popular in nineties and 2000. It was really revolutionary technology because, as I remember those times, it was like Visual Studio 6 when you couldn't even create a visual interface. You could but it was so so complicated and it was not for the wide list of guys or even junior developers. And it was real rapid application development tool when you could just create a form, put the component and magic happened. Of course, I think it were gold times, those 90s and twenties. But after 2003 even Microsoft introduced a new technology like .NET and Visual Studio. This Visual Studio became the main competitor for Delphi, especially for desktop development for Windows.

Of course, Microsoft has a lot of resources, a lot of money for marketing and right now we have what we have. And I think a very interesting thing is that the person who was like a lead architect and developed, I guess, Delphi and Object Pascal, was persuaded to move to Microsoft in 1996 and after that he worked on C# and Visual Studio. And I remember the story when I was on conferences with Visual Studio 2003 and somebody just showed this Visual Studio created project, put the component, press the play button and magic happened. I thought “Oh my god, we did it with Delphi 15 years ago. I mean not 15 but 10 years ago”. Of course, now I believe in Delphi, it is modern cross-platform development tool. Right now it's not only for Windows, like Windows 32 or 64, we also have a possibility to develop applications for Android, iOS and Mac OS. And I think we have a good future. Let’s move on.

Why should we still use Delphi today? I think that it's still rapid development for desktop and especially if we're talking about the rich UI. My team and me also have experience in development for the rich UI with Microsoft tools, like Visual Studio, and I can compare for example with WPF. WPF is one of the most popular frameworks for UI from the Microsoft and it's not easy and it's not easy to start to use this technology. By the way, yes, right now I'm talking about pros and cons of Delphi. Right now we're talking about pros. To create an interface with WPF, developer needs a lot of experience. But if for example compared with WinForms, of course, using WinForms is much much easier, it's something maybe the same as Delphi but the interface, anyway, looks ugly, and if you want to create or re-write some user interface, user experience, it takes a lot of time and knowledge.

It's not easy to use WinForms for rich UI. Because right now for Delphi we have FMX framework with all these styles, ideology and, anyway, I can say that we can play whatever we want and it's much easier. Again, it's just our experience. Easy to deploy - it's also what we're hearing from our clients, our partners, that with Delphi we can still create an application compiled and you will have executable file. Again, if we are comparing with Visual Studio, you will need a .Net framework, you’ll have to think about versioning, and you’ll have to think about compatibility of different assemblies for different software products and so on. The third item is that Delphi still has a huge set of 3rd party components. If we talk about for example TMS, we can go to their website and we can see all the sets of components, it's like you can cover, I guess, at least 80% of all years of party integrations with any SDKs, social media. And, as a third party systems, again it’s very good that Embarcadero provides regular releases for Delphi. It's not like they developed something two years ago and that's all. Of course, each year such companies like Apple and Android provide new SDKs, new OS versions, and Embarcadero provides updates for Delphi with updated support of the newest mobile technologies. Of course, it's not ideal, sometimes Delphi is not covering hundred percent of all these SDKs but you have a possibility to create a bridge for any of additional SDKs. But it's a technical thing, we are not talking right now about such things. The next one I think is one of the pros that right now you can take legacy Delphi project and during migration create from this project up-to-date project with new technologies and you can save the budget. Because, anyway, you can still use an existing business logic source code, and if you want an up-to-date and good looking design, all that you need is just for example go to the new UI. And going to this new UI can be just going for example from VSL Framework to FMX, you can even just migrate not all the forms and you can save this existing source code.

But, of course, pros can’t be without cons. I think all Delphi geeks know about them and they think about them and everybody I think is worrying about this question. Because the first one is like future risks. Even for me. Will Embarcadero have enough resources to compete on a par with other development tools? Of course, how can we compare Embarcadero with giants like Google, Apple or Microsoft. Because Embarcadero all the time have to fight and provide some benefits why Delphi is better than Visual Studio, why people still have to use this technology. Because, of course, Visual Studio also is improving all the time and I guess they invest a ton of money to this technology, into this IDE, and this is a risk even for me.

The second one it's correlated risk. Will we have enough specialists and developers on the market? Yes, unfortunately, we have this gap of Object Pascal and Delphi specialists after 2000 when, for example, even I studied Delphi in my University and at those times it was like one of the major tools for development, and all the technical universities were based on Delphi courses, and after 2000 it was a gap and people and all this PhD started to teach students on visual studio, C#, because it became a modern technology. Even now, even today unfortunately, I don't hear that somebody's studying Delphi engineering in the University. But, as you know, last year Embarcadero introduced this community version and it's free for the universities and schools, and this is why I think maybe it will somehow change the situation for the better because we need Delphi specialists. Unfortunately, even for our team sometimes we cannot find young people after the university who want and who is ready, because, again, they don't want to work with this technology because the next risk is like negative information noise. When some student says to his former colleagues “I’m going to work on Delphi”, they are like “Oh my god! Is it still alive? I don't believe. It's like for old school guys which are using so far file manager for copying files”. This is why even we are trying to fight and somehow broke this way of thinking. This is the risk. And of course, for example, somebody faces with this technology, with the word Delphi, he can see that the community it's not so huge like for .NET. You even can go and briefly check statistics how many questions we have for .NET technologies and for Delphi and, of course, there is a 15 times difference between the numbers.

One more risk is of course this situation that Delphi is an independent developer and it will be like a half a step back, because if somebody like Microsoft already has this technology, Delphi should create a support for this technology. Of course, they have something like the versions which like not releases when Delphi can create a support from your technology and only after release theoretically Delphi and Visual studio will have the same capabilities but unfortunately it's not possible.When Apple changes its SDK, they can add something new and, unfortunately, Embarcadero have a limited time to add this support and sometimes, unfortunately, they don't have enough resources and time, I guess. The one more risks, again it’s my opinion, that Delphi is not suitable for web development. Because, again, if we compare, for example, development with .NET, PHP or with modern JavaScript frameworks, it seems like Delphi is like compromise, it's a solution with compromise for web. And, of course, the next one is like okay, Delphi has a cross-platform mobile development and of course we can create a beautiful web mobile applications with Delphi, but we have an experience with creating very complicated office applications with Delphi and it's very very complicated, it's not like when you want to implement some easy solution, you open for example Android studio, SDK description, it’s just five minutes job and with Delphi it can take couple of days, because you have to create a bridge file, you have to test, you have to import somehow resources for deployment, and, unfortunately, it's not so easy. That was about cons of Delphi. Let's go further.

Now I will briefly explain what is migration in our situation. Of course, it's a very wide term. It can be migration from deployment platform to another, from one technology to another technology, data migration, and a lot of different companies have a different understanding of it. But I have to explain what we put into this term. It's not like migration for example for website from one technology to another. We also put to this term migration from legacy Delphi project to the up-to-date Delphi. For example, migration project from Delphi to Visual Studio and .NET. Of course, this is correlated with reengineering.

Now just a couple of ideas how can you understand that you need migration and this is like a compilation or request from our previous clients. It’s something most often requested: sorry but my application looks very ugly. I'm not talking about ms-dos, of course, but applications which were built 15 years ago, these huge productive systems and a lot of people or companies are still using them, but they look very ugly. Of course, everybody is watching TV, App Store and when they look at all these beautiful applications and websites with this design, they want the same. The second one, again, we have some clients which say sorry but our developers don't want to move, they just may retire and what we have to do, we have a product with Delphi seven but we cannot find who can support this technology. This is why we can suggest to go to the latest one. Of course, if you cannot easily enhance your applications, you cannot run your application on 64 platform, you have to migrate because even now, as I know, for the next version even Apple will get rid of 64 version for 62 version of application, and I think in the future Microsoft will do something. Of course, you need migration, if you need a 24/7 access for your software from any place of the world. And yes, you can do that for example with RDP, but in real life people want to have web technologies and don't have a headache about managing their own servers or virtual machines. Also, maybe you need migration if your development tool or development environment lost official support. You know that right now Delphi seven and even everything up to Delphi Seattle is not supported by Embarcadero. Maybe I’m wrong but this is what I know that they have patches and updates of frameworks only for the latest versions. And of course, you need migration if you want a mobile application. And I can of course continue with this list but I think it's enough.

If you need migration of course there are a lot of risks. These risks are correlated with cons of Delphi technology. For example, the first one is communication risk. If somebody has a legacy Delphi project which works somehow, it has a huge maybe sometimes spaghetti code, beautiful code and you want to migrate to something new, there is a lot of problems that people cannot explain the business logic, even if they can explain business logic but they cannot explain architecture of the application, and this migration is a risk because you can for example create new specification, and architecture, and design and develop from scratch, but another thing is reengineering and trying to understand how works the current software. Because there can be a lot of different tricks and everybody forget about them and when you're trying to migrate to a new version it can start work in such places and you’ll never know what's going on.

The next risk is that legacy application source code is ugly, it's spaghetti code, it does not have any OOP because, like I told, it was developed in 90th and 2000 and there were a lot of people who became developers, and maybe it’s historically but, for example, I saw a lot of bad code which has to be migrated, and if you migrate, you will have to make a decision what to do: to use the same code or perform a code review and rewrite it but it can also take a lot of resources. And, of course, the next risk is that instead of saving money or budget you can spend the same amount, and maybe even more, if compared, for example, with developing from scratch. And, of course, psychological risk: you still will use obsolete technology and this mental risk I think is also worrying me and other people. But when you make a decision that finally you want and you're ready to go from Delphi to up-to-date Delphi, not to another technology, because on this webinar we are talking about going to the Delphi, not to another technology, when you understand the risks, I will explain how we can do this, what is our plan how to migrate. And also, in the end of the webinar on the last page of my presentation I created some questionnaire with like a graph where, again, according to our experience and our suggestions, we provided advice how to make this decision.

Here are just ten steps of the migration according to our experience, this is like we did with some of the projects we migrated accordion these steps, and this is for migration from Delphi seven to Delphi Tokyo version (10.2). The first one, of course, you have to prepare a migration roadmap. Roadmap is something like this plan. The next step is analyzing the current application and analyzing current source code. Will it really be cost effective or maybe your current application has ninety percent of dead code which is not necessary and you can just drop it and just develop from scratch ten percent. This ten percent and you will have a new application on new technology.

The next question that we have to ask is if it is possible to reuse an existing source code. Is it possible to keep 60-80% and use in the new version? Usually we have a lot of systems which work with hardware, they have implemented interfaces protocols and we can and we have to use the same code because rewriting it will cost lots of money, if we're talking about any ATM machine, kiosks and it does not have a sense to develop all this communication from scratch. But if for example application consists of only UI and operations with databases, maybe it's easier and it does not have sense to use Delphi. Also be ready that UI can be and maybe will be revealed in hundred percent. Because if you want a beautiful, a rich application, you have to write and maybe you have to take artists and write the application from scratch and implement it as beautiful as you can. You can even combine VSL forms and FMX forms and just leave these VSL forms like history, like just in case but create the main application with FMX and change everything.

Of course, next you have to gather the experienced team who knows how to do it. Thanks God, we still have a lot of talented developers, Delphi developers. I'm not talking only about our company. I’m talking about the situation all over the world, a huge community in Brazil, in Japan and so on. Next step, like we do, we’re creating in Photoshop or any other graphical tool modern UI, just approve it with the client, we are creating new modern user experience with all these techniques. Then the next step is just developing a prototype of UI where we create the prototype implementing all these UI forms and navigation. Customer and client can take it, play with it, see how it works, how it works on different resolutions, how these responsive techniques work, and so on. The next step is like migrational functionality. We are implementing these new forms like step by step. We can take for example the existing VSL application, we are taking the first form, adding it to the application, changing the code and creating the links and so on. And, of course, in the end we test and delivering the app and it works. An in the end we have successful clients who have really good looking modern applications.

I'd like to say a couple of words about new Delphi features. I think that you guys know about them, but still. The first one is that we can create a modern UI and we can suggest modern UI support for the applications. This is because of FMX framework because the idea of how to create with FMX is totally different like for VSL for example, and using FMX we can create whatever we want much easier without creating new components. We even can create everything with standard components. And if you will migrate hundred percent for VSL you have a change to create a cross-platform application which will support other platforms. Maybe it will be not like mobile maybe it can be Linux, MacOS, and you will be able to use your application on these operation systems not like only with RDP or other virtualization technology. And one more thing it's like a new feature, I think of course you all know that Delphi is trying to support this 64 architecture for MacOS and I hope this year it will be implemented. Of course, everything is not ideal, like we discussed it with this independent tool, and Embarcadero should apply a lot of forces to make the product up-to-date.

Here is the schema which I said I suggested for you, how to make a decision, what to do with your legacy software. I have to be aware that Delphi is not ideal for everything and I'm not saying that everybody if you are Delphi evangelist we have to use Delphi. It has pros and cons. This is why I created this questionnaire and I hope everybody can understand what to do. Because, for example, if I have an old legacy Delphi application, if this is just a desktop Windows application and we still want to have this Delphi Windows application, but maybe with just improved UI, yes, we can choose Delphi migration.

But maybe somebody wants to use Delphi application but he also needs a web browser access from any place of the world, he doesn't want to give for example like into virtual machine and work on virtual machine, yes, in this case we have RDP support, like web client and you just open the virtual machine not like RDP web but including like such virtualization like parallels, shadow, you just can have Delphi application in the browser without the operation system. Yes, it’s possible, you even can use this on mobile devices, on the tablet, but for example, if you want to move to web back-office and front office, I think it will be the better way, and you want to use some cloud solutions, where you just can put your application and don't think about the scaling, about risks, how it will work, it's better to go to a web solution and choose something else and migrate to another technology. Also, if we're talking about mobile applications, for some reason it's good to use Delphi FMX and cross-platform if your application is not very complicated and does not have tons of integrations you can use Delphi my vote is for this. But if your application is too complicated, my vote is for going to the native technologies, or maybe others, like xamarin, because, anyway, xamarin has a better support of all the libraries. I think my assistants will send for you later after the webinar the recording and you will be able to check this diagram.

I think that's enough, maybe you have some questions for me, you can write them in the chat and I will see them and I will answer them. Here is my contact, you can find me on Twitter if you have any questions you can ask them. I'll be glad to answer them. What can I say anyway, that I'm trying to create also some informational noise, but positive noise, about Delphi. I saw who subscribed to my webinar and I saw new names and names which I knew. Anyway, I think that I know some insights about migration and if you have even technical questions I can also answer them, because we have a team who migrated big projects and we know these tricks. Like for example Object Pascal changed, a lot of components just disappeared and, of course, it's not like we just can take legacy code and compile for the new version. Because from one side a lot of components is very good but from another side when all legacy applications were created with a lot of custom components which just does not exist right now, it can be a problem. Anyway if we don't have any questions I think that's all, bye-bye guys, thank you for coming.