IMS to DB2 Migration: Exploring the Options

3 Pages

IMS to DB2 migration is on the radar of many mainframe IT managers. This article explores the issues surrounding the migration of IMS-based data, from the underlying business drivers to evaluating the possible approaches. It also offers a preferred approach that reduces risk and time-to-market while protecting investments.


Modernization has become a central theme in the IBM mainframe world. Even today, 20 years after the introduction of client/server computing and a decade since the introduction of Internet-based computing, the mainframe continues to play a key role in supporting critical processes. But with decades of investment comes islands of data and process logic, often implemented in different generations of technology. It’s not uncommon in most mainframe data centers to find multiple database management systems, multiple development languages, a combination of home-grown and packaged applications, and several architectural styles, including host-based, client/server and Internet-based computing models.

These silos create a major challenge to any modernization initiative.

Numerous studies have shown that as much as 80 percent of a typical IT budget is spent on supporting the current software portfolio, leaving precious little for supporting new strategic business initiatives. In this context, modernization can mean the elimination of duplication, which can reduce costs in areas such as licensing, maintenance, and operations. It also can mean providing an architecture into which new functionality can be rapidly introduced by leveraging existing investments.

For many mainframe pundits, modernization means replacing legacy applications with modern integrated packages. While this may be the most appropriate approach in some instances, the mainframe applications that survived Y2K scrutiny did so because they provide unique value to the business. Discarding this investment in favor of new technologies may resonate well with our consumer-orientated thinking, but it fails to take into account the complexity and risk involved in large-scale IT migration projects and the fact that those mainframe applications contain the logic that defines how organizations work, something that won’t come “out of the box” with new applications. A better way to think about modernization is to use the most appropriate approaches and techniques to bring key applications and data stores into the 21st century while preserving the unique intellectual property that supports the business.

Modernization initiatives focus on several architectural elements, including the user interface, application and process logic, underlying data layer and scalability of the overall design needed to deliver the required service characteristics. Architectural change is often needed in one or more layers to provide support for processes that increasingly span divisions, organizations and channels. The challenge is to minimize risk and cost by focusing on the right layers to address the requirements at hand.

We’ll focus here on the data layer because it can often provide the quickest win with the least disruption to existing application portfolios.

Focusing on the Data

A significant percentage of business data still resides in mainframe data management systems, with much of that mainframe data still in pre-relational data management systems such as IMS. IBM has positioned DB2 to fulfill the central role of data management for today’s modern Service-Oriented Architectures (SOAs). Its rich feature set and ongoing enhancements consistently place it top of the list for flexibility and compatibility with other standards-based data environments. The modernization of the data layer is clear; unlocking the potential of data stored in pre-relational data management systems such as IMS requires that data be moved to DB2. How we achieve that depends greatly on the data in question, the application requirements placed on it, and the rationale driving the need for migration. Let’s look at several scenarios.

3 Pages