How hard is it to migrate a project from Delphi 7 to Delphi XE?

Question

Our company have a software that has been in development for over 10 years, so there are some really dated stuff in there. It's still quite functional and everything, but I see the new features on Delphi XE and it makes me want to switch. Problem is that the source code itself is over 300mb of .pas files (1gb total with components, etc).

We're using custom components, old jvcl stuff and the latest devexpress.

How hard can I expect things to be if I decide to migrate from Delphi 7 to Delphi XE?

Thank you.

Kirkcudbright

It should be quite easy, it will just take you time since your project is large – Pyoid

Thats subjective question. Yes it is hard, but no, not much. – Walk

@Walk - I suppose it is, but the answers here helped me a lot, I'll be way better prepared when the time for the conversion comes. Thank you everyone. – Kirkcudbright

Answer 1

The only real problem is conversion to Unicode. You should learn how Unicode support is implemented in Delphi - start from Marco Cantu White Paper: Delphi and Unicode

It is impossible to estimate the amount of work required to upgrade old applications to Unicode without knowing the actual code. If you were using string types in the standard way, the conversion would be easy. Any low-level tricks with string types (like storing binary data in strings) are now deprecated and the correspondent code should be rewritten.

Godship

Answer 2

Some small tools either migrate without needing to do any modifications, or just a couple of unicode fixes to get it to run.

However, if your codebase is as huge as you're explaining, you shouldn't completely rely on what anyone here is going to tell you. Just get a copy of XE and load the code. See what problems you run into to get a feel for the amount of effort it's going to take.

At this moment I've ported all of my code to XE (even old projects). I re-use the same libraries as much as possible, so once I've converted most of those, "porting" applications from Delphi 7 to Unicode Delphi's was usually merely a repetitive task to either deal with updated interfaces in the libraries, or to fix compiler errors and warnings.

Most common errors that I've encountered:

• Unicode stuff. This will take 90% of the time. It's annoying if the code does a lot of low-level string handling, but most of the problems can easily be fixed by adding some typecasts.

• the compiler bitches when you use c in ['a'..'z']. You're supposed to use CharInSet() for unicode strings.

• If you set ShortDateFormat, you'll get a compiler warning that you should use FormatSettings.ShortDateFormat instead. In new code that's a good idea. If you're porting, just ignore it initially if you just want to get going.

Additionally, you'll probably upgrade your third party libraries to newer versions, so that you don't have to port those yourself. It's not uncommon for those to have changed their interfaces or workings, so i'd download some trial versions of those to see what has been changed.

Welter

Thanks, I'll be facing a lot of those then. I'm just poking around because then we would have to buy Delphi XE. – Kirkcudbright

Answer 3

You mentioned SQL in one of your response comments... Does your database support unicode? If not, you could be in for a lot of work. You may need to convert databases on-the-fly or make a conversion tool for your users. You may need to upgrade the database or even switch to something else. For example, DBISAM is not unicode capable, but the vendor makes ElevateDB which is. The transition is not trivial. And some other libraries like Hyperstring, written largely in assembler, are another sore spot.

Unguentum

I'm using Microsoft SQL Server 2008 SQL_Latin1_General_CP1_CI_AS, I don't think I ought to be facing problems with it, should I? – Kirkcudbright

You're not forced to change your database to Unicode (as long as you don't need to store the whole Unicode set). The DB client and the driver will convert back and forth, but be careful to write what can be converted without losses, as long as you're using LATIN1. What many Delphi programmers miss is many databases are not under the application private control. They are company data used by many applications, and the application must comply with database design, not viceversa. – Dentate

Answer 4

I've been doing quite a few of those conversions.

You should prepare by making your current code base testable. Preferably using automated unit tests, but at least have a good end-user testing plan.

Then you should plan for the biggest portion: the Unicode conversion for both your app and your database.

Finally there are less major, but potentially very time consuming aspects:

• if you are using BDE, this is the time to get rid of it
• the Delphi XE is more strict than Delphi 7
• 3rd party library versions that bump up quite a few versions and are usually far less backward compatible than the VCL is

When you have ported it, it is time to change things: since you have seen the whole code base, now you know where your weak points are, so you can start refactoring them and get a better app than you had before.

Rochellrochella

Answer 5

My project is about a million lines of code and I recently ported from CB9 to XE. To cut down on the amount of work I first rewrote a lot so I was no longer dependant on 3rd party component packs, then carefully went over everything string related (unicode) and only then moved to XE. The preparation was a lot of work, the actual port was relatively easy.

Creamer

Ahh, that's a good idea, mine is very large too. The biggest problem i face are the custom components, they were made specifically for delphi 7, and they are variations of the common controls (edited versions of edits, labels, buttons, etc). The biggest reason for the custom components were adding a property that read their caption from the sql, this was implemented as a localization resort, which I believe to be dated. – Kirkcudbright

that won't be a problem at all – Pyoid

Don't worry, Delphi own localization technique was broken after D7 and not fixed until XE. THereby in this regard you didn't miss anything new. – Dentate

Answer 6

It is definitely a challenge for this MIGRATION to be executed. But need good PLANNING!

We first need to find all the possible components which also needs to be migrated along with the Code. If there are 3rd party components used in Delphi7 project which are not available then its quite complicated to get further on. Secondly, the other type conversion related to Unicode, which is quite easy. And finally ofcourse we need to get other supporting libraries, BDE, and Database Adapaters in place.

For Rich User Interface, Delphi FireMonkey can be used.

Delphi is getting better and better as it has now support from Desktop to Web to Mobiles application development.

Cursed