Migration of Legacy Information Systems

1997

Legacy information systems typically form the backbone of the information flow within an organisation and are the main vehicle for consolidating information about the business. As a solution to the problems these systems posebrittleness, inflexibility, isolation, non-extensibility, lack of openness etc. -many companies are migrating their legacy systems to new environments which allow the information system to more easily adapt to new business requirements. This paper presents a survey of research into Migration of Legacy Information Systems. The main problems that companies with legacy systems must face are analysed, and the challenges possible solutions must solve discussed. The paper provides an overview of the most important currently available solutions, and their main downsides are

Proceedings of the 17th …, 1997

The widespread use of computer technology over several decades has resulted in some large, complex systems which have evolved to a state where they significantly resist further modification and evolution. These Legacy Information Systems are normally mission-critical : if one of these systems stops working the business may grind to a halt. Thus for many organisations, decommissioning is not an option. An alternative solution is Legacy System Migration which has recently become an important research and practical issue.

1979

Abstract As requirements change, database administrators come under pressure to change the schema which is a description of the database structure. Although writing a new schema is a relatively easy job and transforming the database to match the schema can be accomplished with a modest effort, transforming the numerous programs which operate on the database often requires enormous effort.

2004

The paper studies some problems that arise when a technology change induces the migration of a data-centered application. In particular, it addresses the difficult problem of migrating application programs from a legacy data manager, such as a COBOL file system, to a modern DBMS, such as a relational database management system. The approach suggested in this paper relies on the concept of inverse wrappers, that is, wrappers that simulate the legacy API on top of the new database. This architecture allows (1) the design of a fully normalized database rid of the anomalies of the legacy data, (2) future programs to be developed on a sound basis and (3) legacy programs to work on the new database with minimum transformation, and therefore at low cost. The paper describes the components of this architecture, a methodology to design them and a CASE tool that automates their generation.

2008

Relational DataBases (RDBs) are dominant in the market place yet they have limitations in the support of complex structure and user-de ned data types provided by relatively recent database technologies (i.e., object-based and XML databases). Such a mismatch inspires work on migrating an RDB into these technologies. The problem is how to effectively migrate existing RDBs, as a source, into the recent database technologies, as targets, and what is the best way to enrich RDBs' semantics and constraints in order to meet the characteristics of these targets? Existing work does not appear to provide a solution for more than one target database. We tackle this question by proposing a solution for migrating an RDB into these targets based on available standards. The solution takes an existing RDB as input, enriches its metadata representation with as much semantics as possible, and constructs an enhanced Relational Schema Representation (RSR). Based on the RSR, a canonical data model is generated, which captures essential characteristics of the target data models that are suitable for migration. A prototype has been implemented, which successfully migrates RDBs into object-oriented, object-relational and XML databases using the canonical data model.

The widespread use of computer technology over several decades has resulted in some large, complex systems that have evolved to a state where they significantly resist further modification and evolution. Although these Legacy Information Systems pose considerable problems (brittleness, inflexibility, isolation, non-extensibility, lack of openness, etc.), they may also be mission-critical: if one of these systems stops working the business may grind to a halt. Thus for many organisations, decommissioning is not an option. An alternative solution is Legacy System Migration that has recently become an important research and practical issue. Legacy System Migration is a relatively new field of research and few comprehensive methods or practical experiences have been reported. This paper provides a brief overview of existing research and practise when dealing with Legacy Information Systems, and in particular of the area of Legacy Information System Migration.

2007 IEEE International Conference on Software Maintenance, 2007

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document and are linked to publications on ResearchGate, letting you access and read them immediately.

Proceedings of the 2004 ACM SIGMOD international conference on Management of data - SIGMOD '04, 2004

… , 1997. Asia Pacific... …, 1997

The problems posed by mission-critical legacy systems -brittleness, inflexibility, isolation, non-extensibility, lack of openness etc. -are well known, but practical solutions have been slow to emerge. Most approaches are "ad hoc" and tailored to peculiarities of individual systems. This paper presents an approach to mission-critical legacy system migration : the Butterfly Methodology, its data migration engine and supporting tool-kit framework. Data migration is the primary focus of the Butterfly methodology, however, it is placed in the overall context of a complete legacy system migration. The fundamental premise of the Butterfly methodology is to question the need for parallel operation of the legacy and target systems during migration. Much of the complexity of the current migration methodologies is eliminated by removing this interoperation assumption.

Every type of system may replace or enhance the functionality currently delivered by legacy systems to new system, regardless of the type of project/application; some data conversion may take place. Difficulties arise when we take the information currently maintained by the legacy system and transform it to fit into the new system. We refer to this process as data migration. Data migration is a common element among most system implementations. It can be performed once, as with a legacy system redesign, or may be an ongoing process as in storage of historical data in the form of a data warehouse. Some legacy system migrations require ongoing data conversion if the incoming data requires continuous cleansing. It should be that any two systems that maintain the same sort of data must be doing very similar things and, therefore, should map from one to another with ease. Legacy systems have historically proven to be far too lenient with respect to enforcing integrity at the atomic level of data. Another common problem has to do with the theoretical design differences between hierarchical and relational systems. In data migration one method apply in twice (i.e. automated and manual). This paper explores the steps to migrate date in form of manual, i.e. process of data migration without the help of any special tool those made for data migration. Manual data cleaning is commonly performed in migration to improve data quality, eliminate redundant or obsolete information, and match the requirements of the new system in correct and efficient form.