LEGACY MIGRATION AS PLANNED ORGANIZATIONAL CHANGE

Teta Stamati, Panagiotis Kanellis, Konstantina Stamati, Drakoulis Martakos Department of Informatics and Telecommunications, University of Athens, Athens, Greece

Email: {teta, kanellis, stamati, martakos}@di.uoa.gr

Keywords: legacy migration, enterprise modeling, organisational change

Abstract: Traditionally, legacy migration has been viewed as the simple replacement of aged or problematic hardware and software, including the applications, interfaces and databases that compose an information system infrastructure. Our position is that this view is outdated and is at best myopic taking into account that the role of technology is not merely supportive but today pervades every aspect of the way enterprises conduct their business. As such, our position is that migration should be approached as a planned change process that first and foremost requires an understanding and an approach that covers the range of issues and organisational entities involved. In this context, this paper presents such a structured approach that defines the landscape, deals with the semantics of legacy migration and, can be applied by organisations that recognise the need to manage the process in a controlled and not in a piecemeal and ad hoc fashion.

1 INTRODUCTION

Any modification or enhancement of a legacy system within an organisation inevitably brings changes in the way work is organised. Similarly, any organisational change should be reflected in the corporate systems. However, due to the rate of change experienced in contemporary commercial settings, organisations are witnessing the disabling effects that the build-up of legacy systems has on the ability to respond to such change (Brodie & Stonebraker, 1995). Legacy systems are characterised as being very brittle with respect to change (Ganti & Brayman, 1995; Wu et al., 1997) with small modifications or enhancements leading frequently to unexpected project failures (Brodie & Stonebraker, 1995; Bateman & Murphy, 1994). To complicate matters, legacy systems are usually mission-critical systems and must be operational at all times (Brodie & Stonebraker, 1995). Projects tend to fail for a number of reasons (Brodie & Stonebraker, 1993, 1995; Bennet, 1995) but a common thread that arguably runs through the

majority of them is the fact that legacy migration is viewed solely as a technical challenge. To the best of our knowledge, existing migration approaches tend to ‘see’ the legacy system as a standalone and self-contained application or database, defining steps and activities to be performed at the technical level. This ignores social and organisational issues that any change process involves. Today, due to the rate of change, legacy migration is not merely the replacement of existing systems with sets of newer systems offering the same functionality. Migration should widen its scope so as to include organisational change as well as change in computer systems that enables the enterprise change. This wider scope requires a mindset and approaches that can accommodate a wider range of issues, emphasizing the cognitive and social and not merely the technical aspect. In this paper we present a broader, generic approach to legacy migration as planned organisational change which is based on six ‘knowledge states’ (Kavakli & Loucopoulos, 1999) and imposes three views or ‘profiles’ on the process, namely the intentional, operational and informational. The paper begins by providing an overview of the approach and then proceeds in a sequential manner describing and analysing the three

aforementioned profiles. The last section concludes the paper.

2 A GENERIC APPROACH FOR LEGACY MIGRATION

What underlies our approach for legacy migration which we term “Migrate Method” is the following definition: “Migration is a process, which involves business change and this involves more than just the movement or reorganization of database systems, application programs and program interfaces”.

In general, the motivation for any migration process is the incremental transition from an initial organisational situation A, which is unsatisfactory in some aspect, to a desired situation B where the problem is addressed. Possible causes to such change include perceived opportunities, threats, social pressures or political decisions, including for example the opportunities offered by new technologies, increased customer demand for better service quality or the globalisation of markets. The main objective of our approach is the provision of a semantic roadmap based on a set of Knowledge States that define a migration process. We approach migration not as an undirected process, but as a purposive activity driven by organisational goals. Hence, its effectiveness depends on being able to make good decisions about what migration goals to pursue, on selecting the appropriate strategies for achieving the desired goals, and on guiding the application of the chosen strategies. In order to be able to systematically plan and model a legacy migration process, a series of relevant procedures are executed. It is possible to make the distinction between six different types of Knowledge States involved in a migration process, namely:

i) Knowledge about the current business processes, the legacy systems that serve these processes, as well as the requirements for migration (As-Is).

ii) Knowledge about the stakeholders’ goals and how they can be satisfied in terms of alternative migration plans as well as the specific processes that will achieve the predefined migration goals (Migrate Goal Model – Migrate Process Model).

iii) Knowledge about a set of proposed migration transformations that describe a unique way of pursuing stakeholders’ goals (Migration Scenarios).

iv) Knowledge about the validity of the above transformations and thus, knowledge about the most suitable proposed plan (Candidate Migrate Scenario).

v) Knowledge about the candidate legacy systems that are to be migrated (Legacy Systems).

vi) Knowledge about the most suitable custom or off-the-self migration solution based on the profile of the legacy systems (System Migration).

Two additional states in the framework are available: the Null State and the Target State. These describe respectively the state where ‘no knowledge’ about the migration is available and the state where ‘enough knowledge’ has been obtained.

The “Migrate Method” extends across the three different views or levels of abstraction, which feature in enterprise modeling. It examines a migration process from the intentional, operational and informational perspective. The intentional view is concerned with the enterprise objectives and the reasons that prescribe these objectives. It also considers the actors and the corresponding roles that they play in the organisation as well as the business rules. The operational view concerns the business process level, describing the logical localization of data in the different departments of the enterprise, the distribution of functions in these departments and the actors involved in each function. Finally, the informational view defines the logical and physical components of the information systems that support the business processes. The “Migrate Method” encompasses all three profiles and integrates the three complementary views as submodels. Knowledge States and submodels form the “Migrate Method” Metamodel (figure 1) that defines the logical form of the migration process. The metamodel includes information about the semantics of legacy migration; it identifies the entities, their attributes and the explicit relationships between them. The following paragraphs provide a description of the three submodels.

With reference to figure 1, a Migration Goal is a desired state concerning a legacy system that needs to be attained. Migration Goals pertain to stakeholders. A stakeholder is defined as someone who has an interest in the system design and usage. Migration Goals are generated by issues. An issue is a statement of a Strength, Weakness, Opportunity or Threat that leads to the formation of the goal. Migration Goals are then realized by Migration Processes. This is expressed in the metamodel through the Goal Realisation Relationship. Note that the Migration Goals cannot be mapped directly onto Migration Processes.

The transition process from intentions to processes and thus from the intentional to operational profile of the migration process, encompasses the ‘causal transformations’ of general migration goals into one or more sub-goals that

constitute the means for achieving desired ends. Each step can result in the identification of new goals that are linked to the original one through causal relations, thus forming a hierarchy of goals.

A directed edge from a goal A to another goal B implies that the achievement of A depends on the achievement of B. This goal transformation is usually referred to as goal satisfycing1. For each goal alternative satisfycing options may be identified, leading to different ways of resolving this goal. Additionally, the same subgoal may contribute to the achievement of two or more goals. Thus, the resulting structure is a goal graph, called Migration Goal Model, rather than a hierarchy. Relationships between goals in the goal graph are of the AND/OR

1 The term ‘satisfycing’ (Simon, 1979) refers to decision-making process as a process that seeks satisfactory solutions rather than optimal ones.

type and are defined as such in the metamodel. Once the leave goals are operationalised by migration processes, the Migration Process Model is generated.

Any path in the Migration Process Model including only AND type satisfycing relationships between goals and their processor goals constitutes a Migration Scenario documenting how specific migration goals are (or may be) achieved. Alternative paths in the Migration Process Model represent alternative Migration Scenarios. The validity of a particular Migration Scenario is determined through the evaluation of the scenario’s components and the calculation of measurements. This measurement reflects the ‘appropriateness’ of a solution with respect to one or several migration evaluation goals and can be either quantitative or qualitative. Based on the evaluation a scenario may be accepted or rejected.

Migration Processes are expressed in terms of the Migration Actors and the Migration Roles that they play. An actor is a physical entity that plays one or more roles. A role denotes a collection of responsibilities. Discharging these responsibilities requires the realisation of a set of role goals. Such goals are mainly operational goals and they are expressed in terms of business objects and activities that realise them.

Migration Goal

Stakeholder

Issue

Strength

Weakness

Opportunity

Threat Goal Relationship

Goal RealisationRelationship

Goal SatisfycingRelationship

AND_GoalRelationship

OR_GoalRelationshipAND/OR_Goal

RelationshipOperational

Goal

MigrationProcess

Migration ScenarioMeasurement

QuantitativeMeasurement

QualitativeMeasurement

AcceptedScenario

RejectedScenario

EvaluationGoal

Legacy System

H/WInfrastructure

S/WInfrastructure

DatabaseSystem

InterfaceSystem

ApplicationSystem

System Migration

H/W InfrastructureMigration

DatabaseMigration

InterfaceMigration

ApplicationMigration

S/W InfrastructureMigration

Role

Activity

generated_byn..m

pertain_ton..m

involved_in1..n

Argumentjustified_by1..n

1..ninvolves

1..n

realises

1..1has

1..1has

1..nidentified_by

1..ncomposed_of

1..n

performs

lead_ton..m

affects

1..n

INTE

NTI

ONAL

SUBM

ODEL

INTEN

TIO

NAL

SUBM

ODEL

OPERATIONAL SUBMODELOPERATIONAL SUBMODEL

INFO

RMATI

ONAL

SUBM

ODEL

INFO

RMATI

ONAL

SUBM

ODEL

Figure 1: The “Migrate-Method” Metamodel

The Migration Processes are linked to the Legacy Systems that support the business operations. A specific Migration Process may indicate more than one Legacy Systems to be migrated or else may specify certain components of the whole system that need replacement or enhancement whilst it may also point out to inadequate justification for the migration of some other legacy components. The association of Migration Processes to specific Legacy System indicates the informational profile of the migration process.

The Legacy Systems could be any of the various physical systems, which are classified below:

i) An application system - software, which is used to support a particular function or process.

ii) A database system - consists of the actual database and the DBMS, where the database is a collection of records stored, according to some data model.

iii) An interface system - is a piece of software, which is used to interface a particular application either with other applications or with system’s users.

iv) A software infrastructure system - is software, which is dedicated to the operation of a computer system, typically an operating system.

v) A hardware infrastructure system - is a piece of physical equipment, whose operation may rely on software and even firmware. Typical examples are computer workstations, printers and even a Local Area Network (LAN).

The connection between Migration Processes and Legacy Systems is that the latter supports the former. Based on the above classification, Systems Migration may involve any of the migration activities listed below:

i) Application systems migration – the movement or reorganisation of software applications to some new improved form or location.

ii) Database systems migration – the movement or reorganisation of a database to some new improved form or location.

iii) Interface systems migration – the movement or reorganisation of interface components to some new improved form or location.

iv) Software infrastructure migration – the movement or reorganisation of software infrastructure to some new improved form or location.

v) Hardware infrastructure migration – the movement or reorganisation of hardware infrastructure to some new improved form or location.

Some of these migration activities are more common than others, for example, application and database systems migration are likely to occur frequently in an overall legacy migration, but software and hardware infrastructure systems migration are probably less likely to occur. It is worth noting that the various forms of migration have been listed in descending order of complexity with application systems migration being the most difficult and hardware systems migration being the simplest.

2.1 Intentional Profile

The approach commences at the intentional level, by understanding the current enterprise situation and representing the current goals and objectives into the Current Enterprise Goal Hierarchy. Having obtained knowledge about the future stakeholders’ goals, the approach proceeds to model those with respect to the migration process into the Migration Goal Model.

The input in the ‘black box’ in figure 2 corresponds to the Current Enterprise Goal Hierarchy and the outcome to the resulting Migration Goal Model. Both hierarchies are goal graphs and their branches are related by one of the three relationships: AND ( ), OR ( ) and the hybrid ANDOR ( ).

Current Enterprise Goal Hierarchy

Designingfor

migration

Current Enterprise Goal Hierarchy

Migrate Goal Model Migrate Goal Model

Contextual Forces Contextual Forces

S at isfy custom er

Ensure product quality

M in im is e product costs

Prov id e electron ic serv ices

Prov ide af ter sa le support

D evelop electron ic m ark etp lace

D evelop on line help to th e D eal w ith

author iz at ion

D evelop new serv ices

INTRODUCE

Improve efficiency of enterprise processes

IMPROVE

Introduce new automated processes

INTRODUCE Introduce new

Information Systems

IMPROVE Improve existing

Information Systems

IMPROVE Improve Organisational

Structures

CEASE Cease non-profit and useless enterprise

processes

IMPROVE Improve the Process

Workflow Mgt System

IMPROVE Improve the MIS

INTRODUCE Introduce new

Knowledge Mgt System

Figure 2: Input and Output of the Migration Goal Modeling

Both are traversed as well in a breadth-first manner: all the nodes on one level of the hierarchy are considered before any of the nodes on the next level. In both graphs, any goal at each refinement level describes what needs to be done. At the same time this goal can also be considered as an end (why) for another goal, as well as means (how) for still another goal at a higher level.

The generated Migration Goal Model describes all the possible routes that an enterprise can follow to reach its new business goals. This graph includes details about the stakeholders’ requirements in addition to alternative ways of acting towards realising the desired future. Each goal in the Migration Goal Model is characterised by a verb, which describes the nature of the change: maintain, introduce, cease, enable, improve, etc. Figure 2 illustrates a rather simple Migration Goal Model but in a real-world situation the resulting model is likely to be very large because the model is normally developed during brainstorming sessions.

Migration goals express the stakeholders’ needs and desires, as well as external constraints with respect to the migration process. The identification of migration goals is a complex task that encompasses a number of sub-tasks such as definition of stakeholders’ goals in a participative manner, determination of the impact of these goals on the existing enterprise state, agreement on a structured set of business requirements, etc. In the same way, each of these sub-goals may lead to some other concerns. For example, participative definition of migration goals includes issues such as: definition of the individuals that should be involved in the process, definition of the manner that participants are going to communicate with each other, definition of the way that the stakeholders reach agreement on the process, etc.

2.2 Operational Profile

Once the leaves of the Migration Goal Model are mirrored by the required Migration Processes, the approach progresses to the operational view with the Migration Process Model. This includes a hierarchy of goals together with the attached processes at the operational level. Migration processes constitute the means to fulfill the goals. Each role involved in a process intends to achieve one or more defined goals. The goals related to a process present a hierarchical structure whereby individual role goals constitute refinement of higher-level goals that ultimately make up the goals fulfilled by the processes.

The input in the ‘black box’ in figure 3 corresponds to the Migration Goal Model and the outcome to the resulting Migration Process Model. The association of the processes with the goal leaves in the Migration Process Model exposes the operational profile of this modeling. These processes exhibit the activities carried out to complete a process as well as the actors involved in each process and the roles that these actors play. This does not necessary mean that every role in a process aims to achieve the same goal. Satisfaction of the specific goals of individual roles supports the achievements of the operational goals that is realised by the processes.

Once an initial Migration Process Model has been developed, it is necessary to refine the model in order to eliminate changes, which may prove difficult or even impossible to achieve. This refinement is carried out by ‘pruning’ the initial Migration Process Model. Pruning involves cutting off either branches or leaves to eliminate certain change, which may be difficult to achieve.

Figure 3: Input and Output of Migration Process Modeling

Definition of

processes

Migrate Goal Model Migrate Goal Model

INTRODUCE

Improve efficiency of enterprise processes

IMPROVE

Introduce new automated processes

INTRODUCE Introduce new

Information Systems

IMPROVE Improve existing

Information Systems

IMPROVE Improve Organisational

Structures

CEASE Cease non-profit and useless enterprise

processes

IMPROVE Improve the Process

Workflow Mgt System

IMPROVE Improve the MIS

Organisational Forces Organisational Forces

Migrate Process Model Migrate Process Model Z1. Z2, Z3

A1, A2, A3, A4

P1, P2, P3, P4

INTRODUCE

Improve efficiency of enterprise processes

IMPROVE

Introduce new automated processes

INTRODUCE Introduce new

Information Systems

IMPROVE Improve existing

Information Systems

IMPROVE Improve Organisational

Structures

CEASE Cease non-profit and useless enterprise

processes

IMPROVE Improve the Process

Workflow Mgt System

IMPROVE Improve the MIS

INTRODUCE Introduce new

Knowledge Mgt System

Pruning is carried out using evaluation criteria

against which the desired goals are evaluated. The pruning exercise is likely to be carried out by a domain expert, or even a group of domain experts. This is so because of two reasons: firstly domain knowledge is necessary for the selection of suitable evaluation criteria and secondly the actual performance of the pruning calls for knowledge of what can and cannot be achieved in terms of migration goals.

The “Migrate Method” proceeds to define a structured way of identifying and evaluating the alternative transitions for migration within the whole Migration Process Model. Thus, the approach encompasses the Migrate Scenarios Generation technique. Migration Scenarios are defined as possible alternative transition for change. They enable the stakeholders to convey their ideas very easily by developing a shared understanding of the future system’s functionality and leading to the validation of this system.

Alternative Migration Scenarios are modeled as

alternative ways of traversing the Migration Process Model. They occur as a consequence of the OR relationships that exist in a generic Migration Process Model. Each Migration Scenario is a sub-hierarchy of migration goals, which are related through AND relationships only and specifies a unique way of pursuing stakeholders’ goals. Using the definition of a Migration Scenario, the process of Scenario Generation can be carried out systematically. It involves traversing the change process model and identifying the sub-trees, which consist of only AND links and marking each of these sub-trees as single change scenarios. This process is repeated exhaustively using a depth-first search until all possible scenarios have been identified.

The process Scenario Generation starts with a Migration Process Model and ends with a set of excerpts from the same Migration Process Model, which correspond to different scenarios. Figure 4 illustrates the identification of scenarios.

S c e n a r io s E v a lu a t io n

S c e n a r io s f o r M ig r a t io n S c e n a r io s f o r M ig r a t io n A 1 , A 2 , A 3 , A 4

I N T R O D U C E

I m p ro v e e f f ic ie n c y o f e n t e r p r is e p ro c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I N T R O D U C E I n t r o d u c e n e w

I n f o r m a t io n S y s t e m s

I M P R O V E I m p ro v e O r g a n is a t io n a l

S t r u c t u re s

C E A S E C e a s e n o n -p ro f it a n d

u s e le s s e n t e rp r is e p ro c e s s e s

I N T R O D U C E I n t r o d u c e n e w

K n o w le d g e M g t S y s t e m C a n d id a t e S c e n a r io C a n d id a t e S c e n a r io

P 1 , P 2 , P 3 , P 4

I N T R O D U C E

I m p r o v e e f f ic ie n c y o f e n t e r p r is e p r o c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I M P R O V E I m p r o v e e x is t in g

I n f o r m a t io n S y s t e m s

I M P R O V E I m p r o v e O r g a n is a t io n a l

S t r u c t u r e s

C E A S E C e a s e n o n - p r o f it a n d

u s e le s s e n t e r p r is e p r o c e s s e s

I M P R O V E I m p r o v e t h e P r o c e s s

W o r k f lo w M g t S y s t e m

I M P R O V E I m p r o v e t h e M I S

Z 1 . Z 2 , Z 3

P 1 , P 2 , P 3 , P 4

I N T R O D U C E

I m p r o v e e f f ic ie n c y o f e n t e r p r is e p r o c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I M P R O V E I m p r o v e e x is t in g

I n f o r m a t io n S y s t e m s

I M P R O V E I m p r o v e O r g a n is a t io n a l

S t r u c t u r e s

C E A S E C e a s e n o n - p r o f it a n d

u s e le s s e n t e r p r is e p r o c e s s e s

I M P R O V E I m p r o v e t h e P r o c e s s

W o r k f lo w M g t S y s t e m

I M P R O V E I m p r o v e t h e M I S

Z 1 . Z 2 , Z 3

Figure 5: Input and Output of the Migration Scenarios Evaluation Process

S c e n a r io s G e n e r a t io n

M i g r a t e P r o c e s s M o d e l M ig r a t e P r o c e s s M o d e l

A 1 , A 2 , A 3 , A 4

Z 1 . Z 2 , Z 3P 1 , P 2 , P 3 , P 4

I N T R O D U C E

I m p r o v e e f f i c i e n c y o f e n t e r p r i s e p r o c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I N T R O D U C E I n t r o d u c e n e w

I n f o r m a t io n S y s t e m s

I M P R O V E I m p r o v e e x i s t i n g

I n f o r m a t i o n S y s t e m s

I M P R O V E I m p r o v e O r g a n i s a t i o n a l

S t r u c t u r e s

C E A S E C e a s e n o n - p r o f i t a n d

u s e l e s s e n t e r p r i s e p r o c e s s e s

I M P R O V E I m p r o v e t h e P r o c e s s

W o r k f l o w M g t S y s t e m

I M P R O V E I m p r o v e t h e M I S

I N T R O D U C E I n t r o d u c e n e w

K n o w le d g e M g t S y s t e m

P 1 , P 2 , P 3 , P 4

I N T R O D U C E

I m p r o v e e f f ic ie n c y o f e n t e r p r is e p r o c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I M P R O V E I m p r o v e e x is t in g

I n f o r m a t io n S y s t e m s

I M P R O V E I m p r o v e O r g a n is a t io n a l

S t r u c t u r e s

C E A S E C e a s e n o n - p r o f i t a n d

u s e le s s e n t e r p r is e p r o c e s s e s

I M P R O V E I m p r o v e t h e P r o c e s s

W o r k f lo w M g t S y s t e m

I M P R O V E I m p r o v e t h e M I S

Z 1 . Z 2 , Z 3

S c e n a r io s f o r M ig r a t io n S c e n a r io s f o r M i g r a t io n A 1 , A 2 , A 3 , A 4

I N T R O D U C E

I m p r o v e e f f ic ie n c y o f e n t e r p r is e p r o c e s s e s

I M P R O V E

I n t r o d u c e n e w a u t o m a t e d p r o c e s s e s

I N T R O D U C E I n t r o d u c e n e w

I n f o r m a t io n S y s t e m s

I M P R O V E I m p r o v e O r g a n is a t io n a l

S t r u c t u r e s

C E A S E C e a s e n o n -p r o f it a n d

u s e le s s e n t e r p r is e p r o c e s s e s

I N T R O D U C E I n t r o d u c e n e w

K n o w le d g e M g t S y s t e m

Figure 4: Input and Output of the Migration Scenarios Generation Process

Evaluation of alternative scenarios is concerned with evaluating competing migration options. Alternative Migration Scenarios are modeled as alternative ways of traversing the Migration Process Model. The evaluation of scenarios requires the active participation of the stakeholders. Stakeholders are the ones who determine whether a solution is valid or not. The evaluation task is facilitated by the identification of criteria for judging the alternative scenarios for migration and commences with the set of scenarios that have been retrieved from the Migration Process Model with the Scenario Generation process. It ends with the Candidate Migration Scenario that represents the most desirable route to change (figure 5).

2.3 Informational Profile

The Candidate Migration Scenario is modeled as a submodel of the initial Migration Process Model describing explicitly the most significant migration goals fulfilled by corresponding processes. The association of the Migration Processes with the Migration Goal leaves in the Candidate Migration Scenario indicates the beginning of the information system modeling. These processes exhibit the activities carried out to complete a process as well as the specific Legacy Systems that support these activities.

Figure 6 illustrates the process of System Migration. The System Migration commences with the analysis of the processes described in the Candidate Migration Scenario and ends with the matching of the processes with the corresponding Legacy Systems that should be migrated. The factors, which are used to measure the degree of complexity of various forms of migration, are the following:

(a) Complexity – complex systems are often difficult to understand and are difficult to decompose in terms of function and data into smaller, more manageable sub-components; (b) Cohesion – measures the strength by which systems are stuck or bonded together; (c) Coupling – relates to how systems link to one another with systems that contain many interfaces and complex links exhibiting a high degree of coupling; (d) Modularity – in general modular systems are easier to migrate than those, which are not modular; (e) Inertia – a measure of the extent to which a system resists, or refuses change or movement. It should not be too difficult to understand how these factors impact on legacy migration. They are commonly used as metrics in assessing the degree of flexibility of systems in the more general sense. For example, factors (a)-(d) are metrics, which are often used to quantify software systems in terms of maintainability and portability.

The identification of the Legacy Systems that should be migrated is carried out by domain experts since it requires specific knowledge and skills. At this stage migration engineers should try to identify the best solution whether, for example, this should take the form of a custom or off-the-self migration application as different migration solutions suit different legacy systems. The selection of the most appropriate solution depends on a number of factors such as the cost, time limits etc. For instance, the process ‘Upgrade all systems to a new interface using 4GL tools’ may require a ‘screen-scraping’ migration solution if the organisation sees that a quick and low-cost solution is most appropriate.

System M igration

Candidate Scenario Candidate Scenario

P1, P2, P3, P4

IN TRO DU CE

Improve effic iency of enterprise processes

IM PROVE

Introduce new automated processes

IM PROVE Im prove ex isting

Inform ation System s

IM PROVE Im prove O rganisationa l

Structures

CEAS E Cease non-profit and

useless enterprise processes

IM PROVE Im prove the Process

W orkflow M gt System

IM PROVE Im prove the M IS

Z1. Z2, Z3

P1: Improve the S/W of the S ystem . P2: Upgrade the H/W of the System . P3: Exam ine and re-evaluate thepredefined W orkflow s (data). P4: Re-exam ine the access to theSystem .

Z1: Upgrade the H/W of the System Z2: Upgrade the S/W of the System Z3: Reconsider the update the data ofthe System

P1: Software Infrastructure SystemM igration P2: Hardware InfrastructureM igration P3: Database System M igration. P4: Application Systems M igration.

Z1: Hardware InfrastructureM igration Z2: Software Infrastructure SystemM igration Z3: Database System M igration

Figure 6: Input and Output of the System Migration Process

3 CONCLUSIONS

Existing migration approaches view migration as the replacement of a current operational system to a new platform, retaining and if possible, enhancing the legacy system’s functionality and causing as little disruption to the operational and business environment as possible. However, and to the best of our knowledge, none offers an integrated and structured approach for planning and monitoring a migration project considering it as a general change process.

Migration involves general organisational change as well as change in the information systems themselves. Our position is that migration processes for contemporary organizations need a well-structured and wide in scope approach that takes into consideration the semantics of planned organizational change. The approach presented in this paper defines a number of interlinked procedures that model the transformation of a current organisational state to a desired future state. We do not claim that our approach represents some form of magical tool for planning and carrying out successful migration projects. We would rather like to see it as a roadmap that includes the semantics of a landscape far wider and complex than previous migration approaches have considered. As such we believe that its value derives from the fact that it can primarily be used for revisiting our current, but arguably outdated, mindsets for legacy migration. From an applied point of view it can also help for the generation of information models and the informed selection of a tool-set of appropriate techniques that can be used to carry out the modeling and other tasks that need to be performed for moving from one ‘knowledge state’ to another. For legacy migration, organizations need both, and we believe that the approach presented herein can be employed for making the first steps towards these directions.

REFERENCES

Bateman, A. and Murphy, J, 1994. Migrating of Legacy Systems. School of Computer Applications, Dublin City University. Working Paper, CA-2894.

Bennett, K. 1995. Legacy Systems: Coping with Success, IEEE Software, Vol. 12, pp. 19-22.

Brodie, M. and Stonebraker, M., 1993. DARWIN: On the Incremental Migration of Legacy Information Systems. GTE Labs Inc., Internal Report No TR-022-1092-165.

Brodie, M. and Stonebraker, M., 1995. Migrating Legacy Systems: Gateways, Interfaces & The Incremental Approach. Morgan Kaufmann Publishers, Inc.

Ganti, N. and Brayman, W., 1995. The Transition of Legacy Systems Architecture to a Distributed Architecture. John Wiley & Sons, Inc.

Kavakli, K. and Loucopoulos, P., 1999. Legacy Information and Business Process Change. Communications of the Association for Information Systems. Vol. 2, No. 6.

Simon, H., 1979. Rational Decision Making in Business Organizations. American Economic Review. Vol. 69, No. 4, pp. 493-513.

Wu, B., Lawless, D., Bisbal, J., Grimson, J., Wade, V., O’Sullivan, D., Richardson, R., 1997. Legacy System Migration: A Legacy Data Migration Engine. In the Proceedings of the 17th International Database Conference (DATASEM ’97), pp. 129-138. Czechoslovak Computer Experts Press.