Application and Database Migration and Replatforming

Most large companies, regardless of the industry segment, maintain and use on a daily basis data warehouse applications or database transaction systems. Almost always, these are mission critical systems that must be running at all times with high availability and performance. We also find that systems like that usually consist of many diverse components: databases with hundreds of tables, indexes, triggers, stored procedures, dozens of UNIX shell scripts performing maintenance functions or invoking other programs, Pro*C code, 4GL reports, Powerbuilder front-end application, 3rd party business intelligence tools, Java components, etc. These systems get developed over the years by many different programmers, with different programming styles; sometimes companies acquire 3rd party off-the-shelf applicatons or components and customize and add them into the existing system. Eventually, there comes a time when the customer wishes to switch to a different database engine or platform.

Reasons for why organizations want to migrate or replatform their applications vary. Perhaps they realize they are running and supporting every database technology known to man, and it's time to reduce their licensing costs, staff training expenses, simplify overall infrastructure and maintenance, and make sure their mission critical application is based on technology that is well supported by its vendor. We've had customers switch from Informix to DB2 for these exact reasons. Sometimes migrations take place because customers decide to upgrade their hardware, such as from aging HP-UX boxes to newer IBM pSeries machines. Once in a while companies are forced to port their applications to a new database technology or platform at the request of their own large potential customer, when the deal is too lucrative to pass by (we would buy your product but it has to run on database X and on platform Y). There are also purely technical reasons why people migrate. A system that has been in use for years and years might be reaching its peak performance and needs to be migrated onto newer technology and hardware to support growing usage.

Migrating an application usually involves redesigning the database (tables, views, indexes, triggers), re-writing stored procedures, functions, packages in the language used by the target database engine, re-writing all application code to use SQL syntax supported by the target database, sometimes changing the architecture of the application a bit to better support the architecture of the new platform. A lot of work usually goes into functional and performance testing and tuning in these projects. What we also find is that even seemingly very similar database migration projects always have some unique requirements or components that may not be obvious at first, and that makes each such project so ever slightly different from all other such projects.

Over the years, we have gained a lot of expertise in migrating applications from various vendor databases and systems to various other vendor databases and systems. We have done migration projects involving these systems: AIX, DPPX, HP-UX, Linux (Intel, pSeries, zLinux for zOS and System/390), MVS, OS/390, OS/400, Solaris, VM, VSE, Windows, zOS; these databases: Adabas, DB2, IMS, Informix, MySQL, Oracle, PostgreSQL, SQL Server, Sybase, VSAM; and these programming languages: C, C#, Pro*C, COBOL, JCL, Korn shell, Java, Powerbuilder, 4GL, EGL, Perl, PHP.

Server consolidation may accompany application migration or it could be a completely separate activity. At some point, organizations realize they are running a large number of widely diverse servers, acquired over the years from different vendors and for different projects. Each of these servers is barely utilized (sometimes only 10-15% of server resources are actually being used), and yet the company is paying for floor space, power, cooling, and system administration resources. Consolidating numerous applications onto a much smaller number of more powerful and modern servers results in better resource utilization, reduces power consumption, simplifies overall architecture, and reduces the number of software licenses that must be purchased. Virtualization techniques could be used to dynamically provide more resources to certain applications when needed.

Are you considering application or database migration or replatforming, or thinking about consolidation? Get in touch with us.

Powered by Google App Engine Valid XHTML 1.0 Strict Valid CSS! Mozilla Firefox Google Chrome IE Safari
Site Design by GlobalSys Services