I work in “property tech,” as part of a small team of developers that maintains and enhances a legacy property application for landlords, realtors and rental agencies. It's over 1.4 million lines of Delphi code that began life around 25 years ago.

Could we convert the application to a more modern language like C#? Well, most likely not. I converted a 20,000-line Delphi application to C# using a commercial converter, and it took a couple of weeks for me to manually edit and fix the 1,600 compiler errors that the conversion produced—now imagine doing that on a project 80 times as large. And that's just to get it to compile, not even addressing the issue of making it work in a web environment.

Move to Web?

The rest of the company has made the transition to web applications, but that's practically impossible to do for us. If the application had few customers, it might be cheaper to rewrite it from scratch—but it's still a bestseller, with several hundred SME clients, many of them with hundreds of users. 

The advantages of web applications over desktop are well-known. There's no need to install software on the customer's computers and you can update without the customer even realising. The downsides include the UI being not quite as good, and the architecture is web-oriented (it's not as easy to run a report that takes an hour if a session times out after 20 minutes).

The company decided to switch it from being on-prem (running on customers' computers) to running in a SaaS (Software-as-a-Service) environment using Microsoft Remote Desktop Services (RDS). This meant setting up a datacenter and servers to run it on. Customers access it either by using RDP to log into a server or via a published app. With a published app, it looks like you are running it locally but it’s running on the server using RDP invisibly.

SaaS offers similar benefits to web: you run things centrally, simplifying updates and installs. It needs more resources to run than web, especially for those customers with larger numbers of users. 

The big downside to SaaS is if your application uses Microsoft Office. Ours uses MS Word for mail merge, MS Excel for reports and MS Outlook for composing and sending emails. Running MS Office on a server incurs significant licensing fees, but there is a legitimate way to avoid those—and that's what I've spent the last couple of years developing. It uses Microsoft's own technology that underpins RDP to access MS Office on a customer's computer.

Microsoft Virtual Channels

Microsoft virtual channels is a technology that lets you create a communication channel between an application running on a remote server and an application running on your Windows computer. It's quite technical to implement and took me eight months from scratch to get it working; the channel endpoint that runs on your computer is written as a multithreaded COM server dll that is loaded by MSTSC (the Windows application that drives RDP). When the RDP session starts, the COM server dll is loaded by MSTSC and sets up the channel. 

As everyone in the team knows Delphi and no one except me knows C++, I thought it best to do a line-by-line translation of this project on GitHub to Delphi. However, don't use TCP/IP for the transport mechanism; virtual channels has its own transport, and that worked out at least fifty times faster! Despite Delphi now being a legacy language, it is as good for Win32 low-level stuff as C++, and you can write all the COM code, multi-threading and so on that you need. 

Messages are sent from the property tech application on the server to my computer, which does some processing with MS Office and sends a response message back. The bulk of development work was adapting the existing prop tech application to work this way, and that took twice as long as the conversion. Nothing quite beat the first-time experience of clicking a button in the program running on a server 5,000 miles away and having a File dialog spring open on my laptop. 

Addressing Remote Files

How do you refer to a file on a connected laptop when it's located on, say, a C: drive? I experimented with various schemes, such as using other drive letters. However, there are so many clients with their own networks that most likely any drive letter I thought of using (e.g. V:) might already be used by someone. Instead, I added a special prefix like <Drive> before the path. So C:\folder was a folder on the RDP server and <Drive>C:\folder was located on my computer. 

Alternative Technologies

If you don't want to interact with MS Office directly but wish to generate Office-compatible files (.xlsx, .docx, etc.), there are various solutions produced by the likes of third-party libraries Aspose and Syncfusion (for instance, running a batch report that outputs to a temporary file on the server then copies it to the laptop). 

Conclusion

The other thing you should consider is how you debug software running on another computer. I did it by putting in log statements using a simple library I wrote (it built on the Win32 OutputDebugString function call). By running DebugView from Microsoft’s SysInternal’s site, I could view the log in real-time. I think there’s something like 600 log statements scattered throughout the source.

It was a big project and technically, the most complicated development in my career. The work was justified because it allowed the prop tech application to run pretty much unchanged on the SaaS system and offered substantial savings. If you’re also tackling a huge project, keep in mind that even things that seem impossible are often solvable if you understand your options and the principles of good project management.