DoD Software Migration Planning
John Bergey
Liam O'Brien
Dennis Smith
Product Line Practice Initiative
[Top]
1 Introduction
Many DoD organizations face the problem of having to modernize their existing software systems by migrating to more capable systems. Modernizing legacy software systems is a complex engineering problem that includes most aspects of traditional software development with more constraints [Feiler 93]. A successful migration effort requires both a sound development plan and a sound migration plan.
A development plan addresses the selection of the appropriate software processes, methods, tools, and hardware and software platforms. A migration plan created in conjunction with the development plan is necessary to help ensure that the operational transition to the new system goes smoothly.
A good migration plan should weigh programmatic and technical drivers for system development against customer priorities. Because of this, the plan may impact system development and certainly should impact system deployment. Iteration among the key stakeholders is necessary for an effective migration effort. Like development, migration planning involves tradeoffs among cost, schedule, risk, and resources.
Migration issues have been identified previously [Bergey 97], [Bergey 99a]. This current note focuses on migration planning, identifies influencing factors, outlines a set of migration planning activities, and offers a set of guidelines for the migration planning process.
[Top]
2 Migration Planning
Figure 1 is based on experience with reengineering and migration efforts
[Bergey 97],
[Bergey 99a]. This figure illustrates the activities that are part of developing a migration plan.
These activities are outlined in the following subsections.
As shown in
Figure 1, migration planning relies on planning and development artifacts as inputs. These inputs provide a baseline description of the current state of the legacy systems, a baseline description of the new system, and a concept of operations that describes the target system from a user-oriented point of view. A review of these artifacts provides an initial understanding of the degree of compatibility between the new and legacy systems.
The inputs should include the following information:
Using this data, the review of inputs should address the following set of questions:
Managing the migration effort is a critical success factor. It is important to determine how on-going enhancements to legacy systems will be managed while the target system is being developed.
The migration management approach needs to consider how to
Prototypes can effectively test the potential solution, especially in cases where current systems are complex and involve many users. The migration plan should identify prototyping needs. At the same time, it should address the extent to which migration considerations call for prototyping both to mitigate risks and to demonstrate proof-of-concept to users.
This activity also should address the scope of the prototyping need, the migration concepts that are being tested, a set of expected outcomes, and mechanisms to evaluate whether the expected outcomes have been achieved. The prototypes need to be meaningful, and they need to be more than just a public relations type of "demo." Prototype solutions can be evaluated through a variety of means, including proof-of-concept evaluations, user evaluations, and architecture evaluations.
The user interface is particularly appropriate for prototyping. For example, rapid "storyboard" prototyping provides a software snapshot of a display screen that mimics what a user would see with the system. A prototype can be completed in weeks as opposed to months of laborious specification. An effective prototype can also enable users to sign-off on the new user interface and operational usage scenarios before hard system and software implementation decisions are made.
Because of the large number of factors in the legacy environment and the number of users who are potentially affected, pilot implementations on a small scale may be recommended to provide help in the migration effort. This activity should address the extent to which migration considerations suggest that pilot solutions are needed to validate system integrity, performance, and acceptance by users.
Besides their value in testing a technical solution, pilots also serve as a mechanism for providing informed user input and for achieving user buy-in. After determining the scope of the pilot, it is necessary to establish the degree of user involvement in validation and verification.
The Second DoD Product Line Workshop identified the following situations
where a pilot approach might be appropriate
[Bergey 99c]:
To succeed, the pilot
Once the pilot is performed, it is important to evaluate its results and determine if the vision and goals are still practical or whether they should be scaled down, revamped, or possibly even abandoned. These kinds of decision points should be built into the migration plan.
The rollout of new capabilities needs to be carefully planned. Rollout tasks include
As part of developing the migration plan, an evaluation should be made of the number, type, and phasing of system builds that would best support customer priorities and user needs.
The plan should address the following set of questions:
Milestones need to be identified in the migration plan that customers, developers, and users can all accept. A risk assessment should be performed before finalizing system build rollout plans to ensure planning estimates are reasonable, the approach is well conceived and in line with organizational priorities, and the potential impact on customers and users is acceptable.
A level of support must be provided to assist users in using each build and transitioning to the new system. In addition, users often require operational assistance to help them understand the target system’s capabilities and operations. Issues that need to be addressed include
The migration plan should focus on addressing these questions by targeting user support in the areas of
After each new rollout and training phase is complete, the developer needs to ensure that users migrate to the new target system. Basic issues include both the timing and the extent to which users will be able to convert to the new system.
The migration plan should develop approaches to accelerate the migration effort and to decommission the legacy systems as soon as practical. Extra effort may be necessary to accommodate the "late adopters" and other users who are experiencing unanticipated or thorny problems. This may require developing temporary workarounds until a suitable solution can be developed, tested, and included in the next software release or system rollout. Another aspect of this activity is estimating the time and cost to complete the transition of all users to the new system and to decommission the old systems.
The developer should consider incorporating the following approaches to help migrate users of legacy systems:
3
Guidelines
Previous work has identified checklists for system evolution
[Bergey 98], enumerated reasons why reengineering
projects fail
[Bergey 99b], and identified guidelines for migration
efforts
[Bergey 99a]. We derived guidelines from these reports and, in this section, apply them to the migration planning process.
These guidelines include:
4
Conclusion
Despite its importance to success, the development of migration plans has been neglected in the past. Nevertheless, a migration plan can help ensure that a development organization can successfully transition an active user community from a legacy system to its replacement. A realistic migration plan addresses the deployment and transition issues associated with migrating to a new system and phasing out an existing system. This technical note outlines the activities involved in migration planning. It presents steps that an organization can take in developing a migration plan. The note also provides a set of guidelines for implementing a migration plan.
References
REPORT DOCUMENTATION PAGE
Form Approved
OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 1. agency use only 2. report date
August 2001
3. report type and dates covered
Final
4. title and subtitle
DoD Software Migration Planning
5. funding numbers
C — F19628-00-C-0003
6. author(s)
John Bergey, Liam O'Brien, Dennis Smith
7. performing organization name(s) and address(es)
Software Engineering Institute
8. performing organization
CMU/SEI-2001-TN-012
9. sponsoring/monitoring agency name(s) and address(es)
HQ ESC/XPK
10. sponsoring/monitoring
11. supplementary notes
12.a distribution/availability statement
Unclassified/Unlimited, DTIC, NTIS
12.b distribution code 13. abstract
The DoD often faces the challenge of migrating from legacy systems to new target systems. Such migration efforts represent a complex engineering problem. These efforts call for a migration plan to supplement the development plan. The migration plan addresses issues associated with phasing out legacy systems and moving to the new system. These issues include user interface compatibility, database compatibility, transition support, system interface compatibility, and training. By producing and implementing a migration plan, a development organization can help a user community make the transition in an orderly fashion.
This note describes migration planning, identifies influencing factors, outlines a set of migration planning activities, and offers a set of guidelines for the migration planning process.
14. subject terms Migration planning, software evolution, software reengineering
15. number of pages
16. Price Code
17. security classification
UNCLASSIFIED
18. security classification
UNCLASSIFIED
19. security classification
UNCLASSIFIED
20. limitation of abstract
UL
NSN 7540-01-280-5500
The Software Engineering Institute is a federally funded research and
development center sponsored by the U.S. Department of Defense. Copyright 2001 by Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL
IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO
WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER
INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND
WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe
on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare
derivative works from this document for internal use is granted, provided the
copyright and "No Warranty" statements are included with all reproductions and
derivative works. External use. Requests for permission to reproduce this document or prepare
derivative works of this document for external and commercial use should be
addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract
Number F19628-00-C-0003 with Carnegie Mellon University for the operation of
the Software Engineering Institute, a federally funded research and
development center. The Government of the United States has a royalty-free
government-purpose license to use, duplicate, or disclose the work, in whole
or in part and in any manner, and to have or permit others to do so, for
government purposes pursuant to the copyright license under the clause at
52.227-7013.
For information about purchasing paper copies of SEI reports, please visit the
publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html)
Form Approved Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 1. agency use only (Leave Blank)
2. report date
June 2001
3. report type and dates covered Final
4. title and subtitle Real-Time Systems: Engineering Lessons Learned from Independent Technical Assessments
5. funding numbers F19628-00-C-0003
6. author(s) Theodore Marz, Daniel Plakosh
7. performing organization name(s) and address(es) Software Engineering Institute 8. performing organization CMU/SEI-2001-TN-004
9. sponsoring/monitoring agency name(s) and address(es) HQ ESC/XPK 10. sponsoring/monitoring agency report number
11. supplementary notes
12a distribution/availability statement Unclassified/Unlimited, DTIC, NTIS
12b distribution code The Software Engineering Institute (SEI) has performed several Independent Technical Assessments (ITAs) on mission-critical/real-time systems for the Department of Defense and other agencies. This paper contains observations, recurring themes, trends, and lessons learned about systems development as derived from real-time/mission-critical programs that have been reviewed over the last three years. It is hoped that the observations contained in this paper will be of value to future program managers and help ensure their success.
14. subject terms real time, independent technical assessment, ITA, acquisition reform, commercial off the shelf, COTS, reuse, earned value, incentives, reliability, fault tolerance
15. number of pages 28
16. price code
17. security classification of report Unclassified
18. security classification of this page Unclassified
19. security classification of abstract Unclassified
20. limitation of abstract UL
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102
Figure 1: Scope of Migration Planning Activities
Figures in this file are displayed in a separate browser
window. This window will remain open to display figures in this file,
although it might be hidden behind other browser windows.
2.2
Describe Migration Management Approach
2.3
Identify Migration Prototyping Needs
2.5.1
Describe Phasing of System Builds
2.6
Describe Approach for Completion of Migration
[Top]
[Top]
[Top]
[Bergey 97]
Bergey, J. K.; Northrop, L. M.; & Smith, D. B. Enterprise Framework for
the Disciplined Evolution of Legacy Systems (CMU/SEI-97-TR-007).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,
1997.
[Bergey 98]
Bergey, John K. "System Evolution Checklists Based on an Enterprise Framework."
Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute
(February 1998)
http://www.sei.cmu.edu/reengineering/pubs/white-papers/Berg98/Checklist.pdf.
[Note: Because this document or Web site is no
longer available online, the link to it was removed from this file.]
.
[Bergey 99a]
Bergey, J. K.; Smith, Dennis B.; & Weiderman, N. H. DoD Legacy System Migration Guidelines (CMU/SEI-99-TN-013, ADA370621). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, September 1999.
[Bergey 99b]
Bergey, J. K.; Smith, D. B.; Tilley, S. R; Weiderman, Nelson H.; &
Woods, Steven G. Why Reengineering Projects Fail
(CMU/SEI-99-TR-010, ADA362725). Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University, April 1999.
[Bergey 99c]
Bergey, J. et al. Second DoD Product Line Practice Workshop Report
(CMU/SEI-99-TR-015, ADA375845). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, October 1999.
[Feiler 93]
Feiler, P. Reengineering: An Engineering Problem
(CMU/SEI-93-SR-005, ADA267117). Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University, July 1993.
[Jacobson 99]
Jacobson, Ivar; Booch, Grady; & Rumbaugh, James. The Unified Software Development Process. New York: Addison-Wesley, 1999.
[Hofmeister 99]
Hofmeister, C.; Nord, R.; & Soni D. Applied Software Architecture. New York: Addison-Wesley, 1999.
[Royce 98]
Royce, Walker. Software Project Management: A Unified Framework. New York: Addison-Wesley, 1998.
[Top]
Carnegie Mellon University
Pittsburgh, PA 15213
report number
5 Eglin Street
Hanscom AFB, MA 01731-2116
agency report number
21
of report
of this page
of abstract
Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. Z39-18 298-102
[Top]
REPORT DOCUMENTATION PAGE
OMB No. 0704-0188
Carnegie Mellon University
Pittsburgh, PA 15213
report number
5 Eglin Street
Hanscom AFB, MA 01731-2116