Legacy systems contain thousands of service components that perform an array of business functions. For instance, let’s say a set of components in an on-premise legacy system your organization is running delivers a statistics report to an executive. In order to get this weekly report by her deadline, the executive should consider migrating the necessary components to a new Software as a Service (SaaS) app.

If an economic feasibility study indicates this migration would be a smart decision, she should collaborate with other executives and a team of developers, system engineers, and business analysts to break the legacy system into components before working on the app.

1: Identify legacy system assets

The development team, the executive, and the legacy system owner need to identify the legacy system’s assets. The assets include:

  • Documentation, including legacy system descriptions and flowcharts, and a disaster recovery plan;
  • The facility where the company’s internal data center is located;
  • Stakeholders associated with the legacy system; these include current users (including executives), developers, system administrators, and business analysts;
  • IT infrastructure on which the legacy system runs; and
  • Developers’ tech skills, such as developing a SaaS app on a Platform as a Service (PaaS), allows developers to share their skills virtually.

2: Discover the necessary components and their dependencies

A developer should scan the source code for service components for later extraction. The source code includes the main program and its interfaces with subroutines, which may be written in a programming language that’s different from the main program’s language.

The next step is for the developer to identify dependencies among the components in the main program and its subroutines. A service component’s dependency can have many-to-many relationships with the dependencies of other service components.

During the process of identifying the components, the developer should also create a flowchart to help him visualize how service components are dependent on one another.

3: Extract the components

The developer should determine which components should be extracted from the legacy system. The ease of extracting service components depends on five factors:

  • how well the source code was written from the start;
  • how often the source code has been patched and re-patched to fix bugs;
  • whether the legacy system’s documentation has been periodically updated;
  • the developer’s tech skills (e.g., the legacy system’s original developers may no longer be available); and
  • the complexity of the service components’ dependencies.

4: Accept or reject the extracted components

Once the developer untangles the dependencies, he can accept or reject them. Accepting dependencies do not always equate to accepting a service component as is. The developer may need to restructure the service component to meet new business requirements. Combining dependencies might result in fewer service components by eliminating duplicate or similar service functions. The developer puts all accepted service components in a repository to use when creating the SaaS app.

Creating and installing the SaaS app

When creating the SaaS app on the PaaS, developers should determine:

  1. what the user, developers, sys admins, and business analysts expect from the SaaS app, and then choose the type of cloud deployment the SaaS app should run on: private, public, or hybrid.
  2. what accepted service components to use in creating the app based on the expectations from users, developers, systems developers, and business analysts.
  3. the most cost-effective way of orchestrating the service components into a loosely-coupled (i.e., the app can wait for a response from a user while the rest of the app continues to operate) SaaS app, and test if the app results meets the expectations.

After installing the app, developers should monitor the SaaS app’s performance and any changes in business requirements that may require updating and restructuring the app’s service components.

Disclaimer: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.