Debunk the myth that SaaS apps can replace all legacy systems

When executives instruct your IT team to replace all of the company's legacy systems with SaaS apps, you should give these four reasons why that's not advisable.

Image: Daniel Terdiman/CNET

Software as a Service (SaaS) apps are being used more and more in large enterprises. The two primary reasons why executives want employees to use the apps are:

  • Cost savings: The company saves the high upfront costs of expanding IT infrastructure that IT teams need to create new applications. The expansion costs include building a room and hiring additional programmers, systems engineers, and systems analysts. A SaaS provider gives the IT infrastructure and virtual machines needed to run the SaaS apps; it gets the apps from in-house or external SaaS developers.
  • Simplifies users' data-related task: SaaS apps help employees simplify the task of getting data to executives, which they need to help them make timely decisions and to include in the appropriate reports.

These benefits might lead upper management to think that it would be wise to replace all of the company's legacy systems with SaaS apps. However, your IT experience informs you that this idea is problematic for various reasons. Here are four concrete reasons to give when making your case to the executive team.

Tightly coupled legacy systems

A large-scale legacy system is characteristically tightly coupled; this coupling results from optimizing the overall design among the system's components. This leads to closer coupling among the system's service components and large numbers of critical dependencies between the components.

In a simplistic scenario, when a service component in the legacy system waits for a response, it locks up the legacy system. When the service component gets the response, the legacy system is unlocked and moves to the next service components for processing.

SaaS apps are usually loosely coupled. The service component in these apps can wait for a response asynchronously without locking up the application. For an example of how this works, think of shopping online: You put an item in the shopping cart and close the app; the next day, you open the app and see the item is still in the cart; you pay for the item.

CPU speed comparison

The more CPUs there are in a server, the faster an application or legacy system processes data. A legacy system requires more CPUs (at least 6-core) than a SaaS app. More laptops are being built with quad-core, and users use them to access the SaaS apps.

The server's CPU speed has a likely impact on multithreading in SaaS apps and legacy systems. Multithreading allows each task of a well-designed program to operate as independent of others -- nearly at the same time. Performance improves when multiple threads run on multiple CPUs. Multithreading performance gets better when a CPU's speed gets faster and the number of CPUs increases.

(A multithreaded application works just as well on a single-CPU system but without the added speed. The single-CPU system in a bygone mainframe is now a museum piece.)

Location, location, location of data

With the legacy system on-premise, executives know where the data is located, and this information helps them prepare a good disaster recovery plan.

If the executives subscribe to the SaaS apps in a public cloud, they don't care where the data is; if they subscribe to private SaaS apps, they would know where the data is.

Unlike the public cloud that is shared by enterprises, the private cloud is restricted to a single enterprise that must comply with strict regulations on data location and compliance deadlines. The enterprise provides its own servers, allowing the system administrators to shift workloads among servers during surge spikes or when a new application is installed.

A hybrid cloud is the best of both the public and the private worlds. SaaS-based e-commerce applications ensure sensitive data is secured by placing it "on-premise" in the private cloud.

Interoperability resulting in low survivability

When a SaaS provider announces it would go out of business, another SaaS provider that is locked in with a different vendor may find it difficult or even impossible to transfer SaaS apps from the first provider. Vendor-based SaaS apps are not designed to be interoperable between the SaaS providers, each with a different vendor. For this reason, the survivability of these SaaS apps is low when compared to that of legacy systems that have run for 20 years or so.


The best way to debunk the myth SaaS apps will replace all legacy systems is to offer sound reasons why some of your company's legacy systems are here to stay.

What other reasons would you add to this list? Let us know in the discussion.

Also read

By Judith Myerson

Judith M. Myerson is a Systems Engineering Consultant and Security Professional. She is the editor of Enterprise System Integration and the author of RFID in the Supply Chain. She has researched and published articles on a wide range of cloud computi...