Modernizing Your Application: Where to Begin

Upgrading a legacy application can seem daunting. This series will guide you through the process, highlighting strategies for a smooth transition without disrupting your current operations. We’ll begin with identifying your starting point.

First, we need to know what type of app you have.

• Standalone Applications: Operate independently without server interaction. Examples include traditional desktop software like Photoshop or Microsoft Word. If your application falls into this category, consider whether integrating server functionality could enhance its features, such as enabling collaboration.
• Client-Server Applications: These applications already utilize a server for core functions. The modernization path for these applications may be more straightforward, especially if APIs are already in use.

For standalone applications, assess the benefits of adopting a client-server model. Perhaps there are features that you could enable if you included a server in the mix. For example, Google Docs introduced real-time collaboration, challenging Microsoft Office despite having fewer features initially.

If a client-server model isn’t beneficial, consider porting your application to the web using WebAssembly (WASM), which allows applications written in languages like C++, C#, .NET, and many more to run in modern browsers. Adobe reused Photoshop’s existing C++ code base when it ported Photoshop to the web using WebAssembly.

If your application includes server functionality, the next question to ask is whether or not there are existing application programming interfaces (APIs).

Early web applications tended to intermingle business logic and the presentation layer. This intermingling becomes problematic because you can’t upgrade one without potentially breaking the other.

Therefore, the first task is to separate the business logic from presentation code. This might involve creating APIs for front-end interaction, allowing you to update the user interface with modern web technologies while maintaining the existing back-end.

After the front-end client launches, you can upgrade or replace the back-end. As long as the new server supports the same APIs as the old one, the front-end client will continue to work. That’s the big benefit of moving from a monolithic application to one built around APIs and microservices.

If your app already has APIs, you can leverage them to develop a modern web client even if the existing client uses a different technology. For example, we helped ImageQuix convert a Java client into a web app, and the new client mostly used the same APIs.

While it may be tempting to simply port your existing client to the web, you shouldn’t. Don’t limit your vision and your design to the way your old application looked and features it supported. The modern web provides many opportunities for a richer and more powerful experience for your customers.

Every journey begins by knowing both where we’re going and where we’re starting from. Identifying your application’s current architecture is the first step on your modernization journey. In the next article, we’ll talk about tactics for delivering incremental improvements—taking baby steps if you will—towards your end goal.

In the meantime, if you have an existing application that you need to modernize, we offer free one-hour consultations that provides you with high-level feedback on what your modernization path might look like.