J. Software Engineering & Applications, 2008, 1: 1-7
Published Online December 2008 in SciRes (www.SciRP.org/journal/jsea)
1
Eliciting Theory about a Retirement Process
Mira Kajko-Mattsson, Anna Hauzenberger, Ralf Fredriksson
Dept. of Computer and Systems Sciences, Stockholm University/Royal Institute of Technology/Karolinska Institutet Sweden
Received November 25
th
, 2008; revised November 28
th
, 2008; accepted November 30
th
, 2008.
ABSTRACT
The software community has been so much focused on creating and improving development and evolution processes, so
that it has completely forgotten retirement. Today, there are no retirement process models whatsoever despite the fact
that many software organizations desperately need guidelines for retiring their old software systems. In this paper, we
elicit a retirement process model and compare it to the current retirement process models. Our goal is to educe theory
about retirement process, evaluate current retirement process standards and provide feedback for their extension. The
elicitation process has been made within one Nordic financial company.
Keywords: Archival, Conversion, Migration, Process Model
1. Introduction
Research on software lifecycle process models has not
been well balanced so far. Most of the attention has been
paid to software development and evolution. Less focus
has been put on software maintenance. No research been
made on software retirement whatsoever.
Retirement is the disposal process whose aim is to end
the existence of a software system [1]. It consists of the
actual removal of a software system from a regular usage,
migration of its still relevant parts to some other system(s)
and the archiving of it [2].
There are plenty of reasons why a system needs to be
retired. Some of them are the system age and complexity,
removal of its software and/or hardware platform, rules
embodied by the external environments, and the like.
Irrespective of the underlying reasons, retirement is an
extremely complex and difficult process. Hence, it must
be carefully planned and performed.
Except for a very few standards, there are no
retirement process models whatsoever. The extant
standard models are not based on any real-life studies
[3,4]. Due to the fact that their contents have mainly been
chosen in ballots, they are very general. At their most,
they cover a whole retirement process model within only
a few pages. Hence, the current standards do not provide
sufficient guidelines for the organizations in their
complex retirement work.
In this paper, we elicit a retirement process model. Our
goal is to provide a basis for creating theory on the
domain of a retirement process, to evaluate current
process standards and provide feedback for their
extension. The elicitation process has been made within
one Nordic financial company. This company has
recently undergone two retirement projects, one in
Sweden and one in Finland. Both these projects were
very comprehensive. They involved almost the whole
organization and they took several years to complete.
However, they differed in their prerequisites and process
designs. For this reason, in this paper we only report on
one of these retirement projects. The other project has
been reported in [5]. The project reported herein is called
EXIT and it was conducted in Sweden.
The remainder of this paper is structured as follows.
Section 2 briefly presents the organization studied and
the research method as applied in this study. Sections 3
and 4 describe the retirement process model as elicited
within the organization studied. Section 5 compares our
model to the existing retirement process models. Finally,
Section 6 makes final remarks and suggestions for future
work.
2. Research Method
This section describes the organization studied and the
research method we followed when eliciting our model.
Section 2.1 presents the organization and the systems to
be retired. Section 2.2 briefly gives an account of our
research steps.
2.1 Organization and Systems Studied
We studied one Nordic insurance organization. Due to
the sensitivity of the results presented herein, we do not
mention its name. Instead, we use its fictive name -
FORSAK. FORSAK is the leading property and casualty
insurance company in the Nordic region. It has about four
million customers in the Nordic countries. It provides
insurance services to both private customers and
commercial and industrial organizations.

2 Eliciting Theory about a Retirement Process
Figure 1. Retirement process phases in the EXIT project
FORSAK manages many systems. The systems that
are of interest for this study are Indra and Gliid. At the
beginning of the EXIT project (year 2002), Indra, based
on a client-server architecture, was about 14 years old
whereas Gliid, being a mainframe application, was about
20 years old. Both systems possessed overlapping
functionality and were used by about 100-150 users.
The evolution and maintenance of Indra and Gliid as
separate units was too expensive. First, it required
substantially increased effort to implement the same
functionality in two different systems. Second, the
differences in their system designs forced one to conduct
one and the same working routines in different ways. To
avoid this, FORSAK has decided to take appropriate
measures with respect to these two systems, that is, to
retire them and replace them with a new system. The new
system is called LH.
2.2 Research Steps
Our study was a typical design research [6]. Its goal was
to explore a theory about and model the domain of
retirement by identifying all its relevant process
constituents and the relationships among them. It
consisted of the following steps: (1) Literature Study, (2)
Study of the EXIT Project, (3) Creation of a Preliminary
Retirement Process Model, (4) Model Evaluation, (5)
Refinement of the Model, and (6) Comparison of the
Model with the Standard Models.
During the first step, we conducted an extensive and
comprehensive literature study. We went through various
articles and standard process models touching on the
retirement subject. None of them, however, provided us
with detailed information about the retirement process.
Only [3,4] outlined very general process models. Due to
their very coarse-grained nature, they did not provide any
sufficient platform for starting our process design work.
Hence, we may claim that the results of this work are
entirely elicited from scratch using the industrial support.
In the second step, the Study of the EXIT Project step,
we studied the EXIT project by first scrutinizing all the
relevant project documentation. This documentation
included about 100 different documents corresponding to
retirement project descriptions, project plans, status
reports, activity lists as created by individual project
members, system overviews, reports from various
meetings such as steering groups, reference groups, and
the like.
The documents studied did not fully describe the
whole retirement project. Hence, we had to complement
our study with interviews. Here, we interviewed the roles
such as a project manager, operation expert and decision
maker.
Based on the understanding gained so far, we created a
preliminary retirement process model. This model
outlined a set of process activities in the EXIT project, it
structured these activities into process phases, and it
identified roles involved in them. This preliminary model

Eliciting Theory about a Retirement Process 3
was then presented to the project manager in the
organization studied. The goal was to evaluate its
credibility and adherence to the EXIT project. The
evaluation step resulted in some minor modifications to
the EXIT retirement process model. These modifications
are listed in Section 5.1.
Finally, we compared our model to the standard
models [3,4]. To enable the comparison, we created a set
of comparison criteria. Due to the fact that the standard
process models studied are very general, we could define
our criteria only on a very general level. These criteria
are listed in Table 1. They mainly concern roles involved
in and activities being part of the overall retirement
process.
3. Overview of the Overall Retirement Process
The overall retirement process in this context consisted of
three main phases. As illustrated in Figure 1, these were (1)
Pilot Study, (2) Replacement Implementation, and (3)
Retirement Realization.
During the Pilot Study phase in the year of 2002,
FORSAK analyzed Indra and Gliid with the purpose of
identifying cheaper solutions for managing these two
systems. Two alternatives were suggested: (1) a merge of
Indra and Gliid and (2) development of a replacing
system LH and retirement of Indra and Gliid. The second
alternative was chosen. It was regarded to be cheaper and
more reliable in the long run. The Pilot Study phase
ended up with a decision to start a project during which a
new system LH would be developed and Indra and Gliid
would be retired.
During the Replacement Implementation phase in the
years of 2003 to 2005, FORSAK was in the process of
developing LH. LH was developed in an iterative manner,
where each iteration focused on a specific product
domain, such as car insurance, home insurance, and the
like. For this reason, the LH system was deployed in a
successive manner in the years of 2005 and 2006.
After the new system was developed, FORSAK
stepped into the Retirement Realization phase during
which it disposed itself of Indra and Gliid. As illustrated
by a star banner in Figure 1, this project was called EXIT.
It took place in the years of 2006-2007. During this time,
all the three systems were in use. In 2008, both Indra and
Gliid were closed down and only LH has been used since
then.
Table 1. Our comparison criteria
Roles
Activities
- System Analysis
- Archiving Strategy
- Migration Strategy
- Management of the adjacent systems
- Retirement planning
- Risk management
- Conduct archival
Figure 2. Illustrating the simultaneous administration of
insurances in Indra and LH
Regarding the years 2005-2007, all the three systems
were used in production. FORSAK was forced to keep
the old systems running due to the fact that many of the
insurances recorded in them were still valid. Indra and
Gliid administrated all the old insurance cases whereas
LH administered the new ones. This implies that
insurances for one and the same customer were managed
by the old and new systems simultaneously. The choice
of the system to be managed at this time depended on the
insurance period. Figure 2 provides a fictive example of
how reported injuries for one and the same customer
were administrated by two of the systems, Indra and LH.
4. The Project Phases
The EXIT project consisted of four phases are (1) Pre-Study
(2) Preparation, (3) Conversion, and (4) Closedown.
They involved the following roles:
• System Manager (SM): a role responsible for the
operation and maintenance of the system. System
Manager manages the implementation, testing and
deployment of all the prioritized change requests.
• Decision Makers (DM): a set of managerial roles
making important decisions within the organization. In
the context of retirement, these roles may be project
sponsors or managers of the departments affected by the
retiring or replacing systems. Decision Makers are
responsible for planning and managing the retirement
process.
• Operations Expert (OE): a role possessing expert
knowledge of the organization’s operation and the
systems supporting the operation. Operations Expert also
possess good knowledge of various rules and laws that
may affect the retiring and/or replacing systems.
• Project Leader (PL): a role that manages a
retirement project. He plans, follows, and follows up the
project. He also assures that right resources are assigned
to the project.

4 Eliciting Theory about a Retirement Process
• User (U): a user of the systems to be retired. A user
tests the results of the conversion of information and data
from the retiring to the replacing system.
• Developer (D): a role involved in the implementation of
the retirement process. This role covers programmers,
database developers and database administrators.
• System Analyst (SA): a role responsible for planning
and analyzing the software systems within the
organization. He collects information and gathers
requirements on the organization’s operation, maps out
its supporting processes and systems and the roles
involved.
• Support Technician (ST): a role responsible for the
operation and support of the system to be retired and its
software and hardware platforms.
• System Architect (SAR): a role added to our model
after the industrial evaluation step as described in Section
5.1. System Architect is responsible for knowing the
overall architecture of the systems to be retired.
The EXIT retirement phases are illustrated in the box
marked with a star banner in Figure 1. Their inherent
activities and the roles performing them are listed in
Table 2. Below, we describe each of the EXIT phases in
Sections 4.1-4.4, respectively.
4.1 Pre-Study
The goal of the Pre-study phase was to investigate the
systems to be retired, determine which of their parts
should be migrated and disposed off, identify appropriate
archiving and migration strategies, and define a
retirement project and to plan for it.
As shown in Table 1, one first investigated the types of
business objects managed by the systems to be retired.
One then determined their volume. An example of a
business object is an insurance, a customer or an
encountered injury. Usually, the objects to be migrated
were valid insurance claims.
Having an overall picture of the types and volume of
the business objects to be migrated, one then determined
the archiving and migration needs to be further used for
identifying the appropriate migration and archiving
strategies. However, no strategies were determined at this
phase. FORSAK realized that deeper analysis was
required for determining them. Hence, at this stage, one
only determined that the active business objects should
be migrated to the new system. Passive objects, on the
other hand, should be archived. An example of an active
object is a reported injury that has not yet been fully
attended to.
After having identified the migration and archiving
strategies, one determined the project scope. When doing
it, one first analyzed Indra and Gliid’s overall
architecture and design. One then identified dependencies
to other systems. Here, one considered systems and their
users that were dependent on the retiring systems. Four
interfacing systems were identified: two insurance
administrative ones, one bookkeeping system, and one
accounting system.
Identification of the interfacing systems affected by the
closure of Indra and Gliid led to the identification of the
additional activities required for managing the retirement
project. In our case, one recognized (1) a need for
analyzing the migration and archiving strategies, and (2)
a need for making deeper analyses of the adjacent
systems and their connections to the systems to be retired.
These analyses were then conducted in the Preparation
phase.
Finally, one defined a retirement project. The project
definition included risk management and creation of a
retirement plan. Risk management concerned risks such
as access to resources required, staff illness and various
technical risks. The retirement plan, on the other hand,
covered most of the rudimentary project planning
activities such as the identification of the stakeholders
to be involved in the retirement project, identification of
the roles required for managing and executing the
project, determination of the competence required for
managing and implementing the retirement process,
determination of the project budget and schedule, and
the like.
4.2 Preparation
The goal of the Preparation phase was to further analyze
the systems to be retired, make a decision on archiving and
migration strategies, determine changes to be made in the
adjacent systems and to identify changes to be made in the
replacing system.
As a first step, one studied the business objects to be
migrated. The goal was to identify active objects and to
attend to inconsistencies in them. To be able to recognize
active objects, one had to define appropriate analysis
activities and the roles required for performing them. An
example of an analysis activity is a task to create a list of
open injuries, go through the injuries and determine which
of them should stay open and which of them should be
closed. The open injuries were subjects for migration.
For all the active business objects, one analyzed their
individual data fields in order to determine whether they
should be migrated to the new system. One also analyzed
special cases of business objects. An example of a special
case is the situation when one and the same business
object is administered by both the retiring and replacing
systems.
For the data fields to be migrated, one created a
conversion table so that the fields in Indra and Gliid
would match the fields in the new LH system. Finally, one
created a conversion testing plan. The testing implied that
one chose a specific numeric field, summed it for all the
business object instances in the systems to be retired and
compared their sum to the corresponding sum in the new
system.
As a next step, one determined the migration strategy.
The choice was between manual and automatic
conversion techniques. In total, one estimated that there
were about 2400 active objects. To manually convert them
would take about 20 man-minutes. This implied 100

Eliciting Theory about a Retirement Process 5
Table 2. Retirement process phases and activities. The abbreviations in the parenthesis as listed after each activity
correspond to the roles performing them. Underlined activities and roles written in bold text were added after the
industrial process model evaluation step
man-days for the whole manual conversion. The estimates
for manual conversion were then compared to the
estimates made for the automatic conversion. The
decision was made that most of the objects were to be
automatically converted.
The archiving strategy was determined in this phase as
well. Here, one investigated (1) how the data should be
archived, (2) the need for accessing it in the future, and (3)
the effects of archiving it. Together with the laws and
rules as identified in Activity 2, this information provided
feedback for deciding upon the technical archiving solution.
The criteria used were technical feasibility and cost.
The strategy chosen was to let all the data stay
untouched in Indra and Gliid and just to close the two
systems for update. The cost of having these systems in
operation was estimated to be very low. The alternative
archiving strategies were to move all the data from
Indra and Gliid to LH or to build a completely new
archive. Both these alternatives were regarded to be too
costly.
As a next step, one analyzed dependencies to the
interfacing systems. When doing it, one identified and
analyzed how they were affected by the closure of Indra
and Gliid. The analysis showed that the closure did not
imply any major changes and implications to these
systems. The only action that was required was to inform
their managers about the forthcoming closure. Finally,
one determined the date when the business objects should
be migrated to the new system and when the old systems
should be retired.

6 Eliciting Theory about a Retirement Process
It was suspected that the retirement work would lead
to some additional changes to be made in the LH system.
To identify these changes, one analyzed current working
routines, suggested changes to them and their supporting
system (LH), and determined the impact and
consequences of their implementation. For all the
changes identified, one created change requests and sent
them to the team responsible for making changes to the
LH system.
An example of a major change to be introduced in LH
was the implementation of the report generators that
were used in the Indra and Gliid systems. An example of
a minor change was the creation of a certain data field.
All the major and minor changes were tested in the LH
system before the Conversion phase started.
4.3 Conversion
The Conversion phase started only after all the
preparations had been successfully conducted. As a first
step, one developed the automatic conversion method
including scripts and automation processes. This method
was then tested with the purpose of estimating the
conversion time and of assuring a problem free
conversion. After the tests had been successfully passed,
one conducted both the automatic and manual
conversion on the day as determined in Activity 7 in the
Preparation phase. The results were finally tested to
verify a successful conversion.
4.4 Closedown
In the Closedown phase, one closed down the Indra and
Gliid systems and removed their dependencies to the
adjacent systems. The closure in our case implied that the
users could no longer access information in Indra and
Gliid.
5. Evaluation
In this section, we make two evaluations. We first present
the results of our fifth research method step during which
we evaluated our elicited model within FORSAK. We
then evaluate it against the current standard retirement
process models [2,3].
5.1. Industrial Evaluation
The retirement process model was presented to the
project manager responsible for the retirement project.
According to her, our model was realistic and it fully
reflected the retirement process as performed within the
EXIT project. She has, however, observed three minor
deficiencies which she believed were very important for a
successful execution of a retirement process. These
concerned adding two new activities to the first
retirement phase and adding a new role.
The first new activity dealt with risk management.
According to her, controlling risks was an essential
activity within the retirement process. Not doing it
implies a critical business risk by itself. The second
activity concerned determination of retirement project
budget. According to the project leader interviewed, due
to the criticality of retirement projects, it is very
important to assign substantial resources to the retirement
project. Otherwise, one runs the risk that one
underestimates the project and thereby fails with its
completion.
Regarding the missing role, it concerned the role of a
System Architect . According to the project leader, this
role is indispensable in all the retirement projects. Not
only does this role know the system to be retired but also
all its architectural flaws and deficiencies that should not
be migrated to the new system.
As a response to these deficiencies, we have added the
budget and risk management activities and the System
Architect role to our model. The modifications are
marked with the underlined text written in bold letters in
Table 1.
5.2 Evaluation against Current Standards
In this section, we compare our retirement process model
with the standard process models as described in [2, 3].
When doing this, we follow the comparison criteria listed
in Table 1. Except for the criteria concerning the roles, all
the comparison results are outlined in Table 3.
None of the standard process models suggests any
roles to be directly involved in the retirement process.
Regarding the ISO/IEC standard [3], it only briefly
mentions that personnel be trained in retirement actions.
The IEEE model [2], on the other hand, mentions a user
role, who should be notified about the closure of the
system. Within the EXIT project, we have however
identified nine different roles. These are listed and
described in Section 4.
The broad portfolio of the roles identified in the EXIT
project indicates that the retirement project involves the
majority of the organizational roles ranging from user to
various analyst and design roles, to managerial roles and
even to support roles. This, in turn, indicates how
complex and comprehensive the retirement process
model is.
As illustrated in Table 3, none of the standard process
models includes the activities during which one analyzes
the retiring and replacing system. We believe that these
Table 3. Our comparison results
Activities IEEE ISO/IEC EXIT
- System Analysis – – +
- Archiving Strategy – + +
- Migration Strategy – – +
-Management of the
adjacent systems
– + +
- Retirement planning + + +
- Risk management – – +
- Conduct archival +
+ +

Eliciting Theory about a Retirement Process 7
are one of the most important activities within the
retirement process. They could be compared to the
requirements specification activities. It is a common
knowledge that non-recognition of the requirements,
irrespective of what type of a project it concerns, does not
lead to successful project results. For this reason, we
claim that lack of analysis activities is a series deficiency
in the standard process models studied.
Only the ISO/IEC 15288 standard [4] suggests the
identification of archiving strategies. None of the
standard models proposes migration strategies. In our
opinion, identification of both these strategies is very
important. Identification of the retirement strategy is a
must. However, the identification of the migration
strategy should be an option. This is due to the fact that
not all retiring systems undergo migration. We believe,
however, that the inclusion of this strategy in the
retirement process model indicates that the retirement
process does not exist in a vacuum. Many times, parts of
the retiring systems have to be migrated to other new
replacing systems or other new archiving systems.
Only the ISO/IEC 15288 standard [4] briefly mentions
that the interfaces to the adjacent systems should be
considered. None of the standard models suggests how
the interfacing systems and their users should be handled.
In our opinion, this is a serious omission. Improper
management of the adjacent systems may lead to big
inconsistencies and problems in their future operation.
Hence, we suggest that the interfacing systems and their
handling should be highly prioritized in a retirement
process.
Both the standard process models studied included the
planning activities. However, they only recognized the
need for planning. They have not provided any
suggestions specific to the retirement planning process.
None of the standard process models studied included
risk management. We did not include it either in our
preliminary process model outline. Even if a risk
management is a separate process, we strongly believe
that it definitely should be integrated with the retirement
process. Retirement and replacement imply many serious
business risks. Not considering them may jeopardize the
whole retirement process, and thereby the organization’s
future business opportunities.
Finally, all the standard process models included the
archival activity. This activity however was only briefly
mentioned, even in our process model. We suspect that
this activity is quite complex. Hence, it should be further
studied and explored.
6. Final Remarks
In this paper, we have elicited a retirement process model.
Our goal was to provide a basis for creating theory on the
domain of a retirement process, to evaluate it against
current process standards and provide feedback for their
extension. The elicitation process was made within one
Nordic financial company.
Our results show that our process model is realistic and
that it correctly reflects the EXIT retirement project.
Although, its design is based on only one project, it
already may provide a basis for comparing it with current
retirement standard models and for making suggestions
for their improvements and extensions. These improvements
and extensions are the following:
· Extend the retirement process model with the roles
involved in the retirement process. Given the specific
characteristics of the retirement process, it is not always
obvious who should do what and why. To fully provide
support to the organizations, one needs to compliment the
retirement process models with the list of roles and their
responsibilities.
· Include analysis of the system to be retired. Only then
you may make sure that you have not gotten rid of
important information.
· Extend the retirement process model with the
migration strategy. This is a way of indicating that a
retirement process model is always conducted in a major
context.
· Provide clear instructions for how to manage the
adjacent systems. This concerns both the adjacent
systems and its users.
· Make suggestions for how to plan a retirement process.
This will help the organizations identify the full coverage
of retirement and migration activities necessary for
shipping successful project results.
· Include risk management in the retirement project. It
is only in this way; one may become proactive against
many serious business risks in this very critical activity.
Our next step is to create a generic retirement process
model. In [5], we have elicited another instance of a
retirement process model. This instance substantially
differs from the process model elicited herein. For this
reason, we believe that we are going to meet a great
challenge when trying to consolidate these two process
models. We are however prepared to meet this challenge.
REFERENCES
[1] V. T. Rajlich and K. H. Bennett (2000), “A staged model for
the software life cycle,” Computer 33(7), 2000.
[2] S. W. Ambler, M. J. Vizdos, and J. Nalbone, “The enterprise
unified process: Extending the rational unified process,”
Upper Saddle River, N. J.: Prentice Hall PTR, 2005.
[3] IEEE Standard for Developing Software Life Cycle
Processes, IEEE Std 10741991, The Institute of Electrical
and Electronics Engineers, Inc. 345 East 47th Street, New
York, NY 10017-2394, USA, 1991.
[4] ISO/IEC 15288, Systems and Software Engineering-
System life cycle processes, IEEE Std 15288-2008, 2008.
[5] M. Kajko-Mattsson, R. Fredriksson, and A. Hauzenberger,
“Elicting a retirement process model: Case Study 2,” in
Proceedings, International Conference on Innovation in
Software Engineering, IEEE, 2008.
[6] B. Laurel, “Design research: Methods and perspectives,”
the MIT Press, 2003.