LEGACY MIGRATION AS PLANNED ORGANIZATIONAL

CHANGE

Teta Stamati, Panagiotis Kanellis, Konstantina Stamati, Drakoulis Martakos

Department of Informatics and Telecommunications, University of Athens, Athens, Greece

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

501

Stamati T., Kanellis P., Stamati K. and Martakos D. (2004).

LEGACY MIGRATION AS PLANNED ORGANIZATIONAL CHANGE.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 501-508

DOI: 10.5220/0002630605010508

 SciTePress

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.

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

502

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 satisfycing

. 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

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

The term ‘satisfycing’ (Simon, 1979) refers to decision-making

process as a process that seeks satisfactory solutions rather

than optimal ones.

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.

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

Migration Goal

Stakeholder

Issue

Strength

Weakness

Opportunity

Threat

Goal Relationship

Goal Realisation

Relationship

Goal Satisfycing

Relationship

AND_Goal

Relationship

OR_Goal

Relationship

AND/OR_Goal

Relationship

Operational

Goal

Migration

Process

Migration Scenario

Measurement

Quantitative

Measurement

Qualitative

Measurement

Accepted

Scenario

Rejected

Scenario

Evaluation

Goal

Legacy System

H/W

Infrastructure

S/W

Infrastructure

Database

System

Interface

System

Application

System

System Migration

H/W Infrastructure

Migration

Database

Migration

Interface

Migration

Application

Migration

S/W Infrastructure

Migration

Role

Activity

generated_by

n..m

pertain_to

n..m

involved_in

1..n

Argument

justified_by

1..n

involves

1..n

realises

1..1

has

1..1

has

1..n

identified_by

1..n

composed_of

1..n

performs

lead_to

n..m

affects

1..n

INTENTIONAL SUBMODEL

OPERATIONAL SUBMODEL

INFORMATIONAL SUBMODEL

Figure 1: The “Migrate-Method” Metamodel

LEGACY MIGRATION AS PLANNED ORGANIZATIONAL CHANGE

503

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 ( ).

urrent

nterprise

oal

ierarchy

Designing

for

migration

urrent

nterprise

oal

ierarchy

igrate

oal

odel

igrate

oal

odel

Contextual Forces

Satisfy

customer

Ensure product

quality

Minimise

product costs

Provide electronic

services

Provide after sale

support

Develop electronic

marketplace

Develop on line

help to the

Deal with

authorization

Develop new

services

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

rocesses

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

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

504

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

Figure 3: Input and Output of Migration Process Modeling

Definition

processes

igrate

oal

odel

igrate

oal

odel

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

rocesses

IMPROVE

Improve the Process

Workflow Mgt System

IMPROVE

Improve the MIS

Organisational Forces

igrate Process

odel

igrate

rocess

odel

Z1. Z2, Z3

1, 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

rocesses

IMPROVE

Improve the Process

Workflow Mgt System

IMPROVE

Improve the MIS

RODUCE

Introduce new

Knowledge Mgt System

LEGACY MIGRATION AS PLANNED ORGANIZATIONAL CHANGE

505

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.

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.

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).

Scenarios

Generation

igrate Proc ess

odel

igr ate

rocess

odel

1, A2, A3, A4

Z1. Z2, Z3

P1, P2, P3, P4

IN TRO DU CE

Improve efficiency of

enterp rise proce sses

IM PRO VE

Introduce new

autom ated processes

INTRODU CE

Introduce new

Information Systems

IM PRO V E

Improve existing

Information System s

IM PRO VE

Improve O rganisational

Structures

CEAS E

Cease non-profit and

useless enterprise

rocesses

IM PRO VE

Im prove th e Process

Workflow Mgt System

IM PR O V E

Im prove the M IS

INTRO DUCE

Introduce new

Know ledge M gt System

P1, P2, P3, P4

INTR O DU CE

Improve efficiency of

enterprise processes

IM PR OV E

Introduce new

automated processes

IM PROVE

Im prove existing

Information Systems

IM PROVE

Improve Organisational

Structures

CEAS E

Cease non-profit and

useless enterprise

rocesse s

IM PR OV E

Improve the Process

Workflow Mgt System

IM PR OV E

Improve the M IS

Z1 . Z 2 , Z 3

cenarios for

igr ation

cenarios for

igration

1, A2, A3, A4

IN TR O D U CE

Improve efficiency of

enterprise processes

IM PR O V E

Introduce new

automated processes

INTRO D UCE

Introduce n ew

Inform ation Sy stem s

IMPRO VE

Improve O rganisational

Structures

CEAS E

Cease non -profit and

useless enterprise

rocesses

IN TR O D U CE

Introduce n ew

Knowledge M gt System

ure 4: In

ut and Out

ut of the Mi

ration Scenarios Generation Process

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

506

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.

Scenarios

Evaluation

cenarios for

igration

cenarios for

igration

1, A2, A3, A4

IN TR O D UCE

Improve efficiency of

enterprise processes

IMPRO VE

Introduce n ew

autom ated processes

INTR O D UCE

Introduce new

Information Systems

IM PROVE

Improve Organisational

Structures

CEASE

Cease non -profit and

useless enterprise

roce ss es

INTR O DUCE

Introduce n ew

Knowledge Mgt System

andidate

cenario

andidate

cenario

P1, P2, P3, P4

INT ROD U CE

Im prove efficiency of

enterprise processes

IM PROVE

Introduce new

automated processes

IM PROV E

Im prove existing

Information Systems

IM PROV E

Improve Organisational

Structures

CEASE

Cease non-profit and

useless enterprise

rocesse s

IM PROV E

Imp rove the Process

Workflow Mgt System

IM PROVE

Improve the MIS

Z1. Z2, Z3

P1, P2, P3, P4

INT ROD U CE

Improve efficiency of

enterprise processes

IM PROV E

Introduce new

automated processes

IM PROVE

Improve existing

Information Systems

IM PROVE

Imp rove Organisational

Structures

CEAS E

Cease non-profit and

useless enterprise

rocesse s

IM PROV E

Imp rove the Process

Workflow Mgt System

IM PROV E

Imp rove the M IS

Z1. Z2, Z3

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

ocess

LEGACY MIGRATION AS PLANNED ORGANIZATIONAL CHANGE

507

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.

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,

Proceedings of the 17

International Database

Conference, pp. 129-138.

System

Migration

andidate

cenario

andidate

cenario

P1, P2, P3, P4

INTRODUCE

Improve efficiency of

enterprise processes

IMPROVE

Introduce new

automated processes

IMPROVE

Improve existing

Information Systems

IMPROVE

Improve Organisational

Structures

CEASE

Cease non-profit and

useless enterprise

rocesses

IMPROVE

Improve the Process

Workflow Mgt System

IMPROVE

Improve the M IS

Z1. Z2, Z3

P1:

Improve the S/W of the System.

P2:

Upgrade the H/W of the System.

P3:

Examine and re-evaluate the

predefined Workflows (data).

P4:

Re-examine the access to the

System.

Z1:

Upgrade the H/W of the System

Z2:

Upgrade the S/W of the System

Z3:

Reconsider the update the data of

the System

P1: Software Infrastructure System

Migration

P2: Hardware Infrastructure

Migration

P3: Database System Migration.

P4: Application System s Migration.

Z1: Hardware Infrastructure

Migration

Z2: Software Infrastructure System

Migration

Z3: Database System Migration

Figure 6: Input and Output of the System Migration Process

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

508