Common Migration Scenarios

In most cases, it is important to understand what type of migration you are undertaking. There are a few basic migration pathways most commonly seen in business:

•  A total application migration from one environment to another (DB2 to Oracle). In this case, you are replacing one software application with another. In most cases, you are also moving to different physical machines and changing operating systems. The application code of the old system will be all replaced with new code. The database(s) (if any) of the old system will be replaced with Oracle.

•  A migration of databases to support the same application (Sybase to Oracle). Here, you see the application code and front-end remaining the same, yet the database supporting the application changing. In many cases, this is simply a database migration and the application will even remain on the same or similar physical machines and operating systems. Application code changes are minimized to the changes needed to support the new database.

•  A migration of only a subset of one application (VSAM to Oracle). In this case, only one module of an application, probably part of a very large application, is migrated to a different hardware/operating system and/or database.

•  An application that needs existing data from another system—one-time data transfer (Informix to Oracle). This is the easiest form of migration. Your new application is simply built and tested, according to new specifications. Once the application is finished, old data is loaded into it. There is no transfer of the application logic from the old system to the new; there is just the need for old data, possibly from more than one source.

You will explore these four common scenarios throughout this chapter by using different technologies as examples. You will learn about many of the common technical issues faced in migration. You will also look at different aspects of the migration mindset that must manage the many resources and tasks that make a migration successful.

Downsizing

Downsizing from a mainframe to a more open environment by using Oracle not only requires you to battle technical issues that span these different types of systems, but to wage battle across time itself as older paradigms give way to newer paradigms.

Assume you are migrating a complete system from a mainframe environment to an Oracle environment, UNIX/Oracle/Oracle*Forms 4.5, for example. This migration is so difficult because so many components need to be moved (see Figure 7.5).

Figure 7.5.  A legacy downsizing migration, where all components of the old system need to be replaced.

Aside from the many changes that need to be made, there is a radical paradigm shift when moving from a mainframe to a more open system. For one, IMS uses a hierarchical model to store data, whereas Oracle uses a relational model. Secondly, you are moving from character block-mode CICS screens to a GUI front-end interface. In this case, you need to redesign both the database and the front-end.

Not only will you be undertaking a massive redesign effort, but the new design of both the database and front-end will come from a totally different paradigm; therefore, the design process must change. The way that relational databases are designed differ greatly from the way hierarchical databases are designed. The way that GUI front-end systems are designed is also different from the way character-mode systems are designed.

Front-End Considerations

If you decide to minimize changes to the front-end, you might just copy all the screens using Oracle Forms 4.5. But by doing this, you would have a very nonstandard GUI interface. True, you could elect to build character-mode forms in Oracle Forms 4.5, but this choice would be only a partial system migration, because the front-end would be still designed for a system it was no longer using.

Sometimes cost and time considerations can force you to first complete a partial migration. You might decide that character-mode screens are the best choice for now, because users will not have to be retrained for as long as when the new system comes online. This decision is valid, but eventually you might want to redesign your front-end, given new possibilities and GUI standards. Many two-phase migrations are centered around this type of philosophy (see Figure 7.6).

Figure 7.6.  Sometimes a system is migrated in stages so as to minimize impact in user retraining.

As long as you are conscious of your decision to delay a redesign of the front-end, you are not in peril. If, instead, you think that because you have an old front-end mapped to a new GUI tool you have a valid GUI front-end, you are mistaken. There are many GUI standards make different GUI front-ends easy to learn. If you do not use these features, your system may technically have a GUI front-end, but will force GUI users to spend more time learning the system (see Figure 7.7).

Figure 7.7.  When you don’t design a front-end around its new environment, you confuse users and fail to realize processing gains.

Aside from the future training costs of a nonstandard GUI application, you may suffer in terms of functionality. Assume your front-end is designed to buy and sell stocks; you might realize faster speeds for the end user in task completion and fewer keystrokes if you used modern GUI features. This would translate into a large, value-added gain for the migration project because transaction speed is of paramount importance to any trading system.

Like any business decision, you must choose how much money you want to invest in your downsizing. You need to consider all of the previous factors when deciding how much money and time to spend on the front-end migration. Many migration efforts have failed to see the differences of front-end paradigms between mainframe and GUI environments, and have spent a great deal of money ending up with a front-end that belonged to neither world.