Cost‐driven software migration: An experience report

Software migration projects are often bound either by time or cost or by both. If the project is bound by both time and cost, the user must sacrifice something else, usually the quality. The migration strategy depends on how the project is bound. Most migration projects are bound by time. The new system must be in operation by a given date, no matter what it costs. The project described here—a state employee payroll system—is bound by cost. It must remain within the budget, no matter how long it takes. The original costs were estimated based on the code size and the productivity measured in previous migration projects using three different approaches: conversion, redevelopment, and reimplementation. The conversion approach would have been the cheapest, but it had already been tried and failed. The redevelopment approach was considered to be out of the question due to the high costs. Thus, reimplementation remained as the only alternative. The costs of this approach were estimated using three different estimation methods and approved by the state government. The project has been in progress for 4 years, and until now, the estimated costs and actual costs are in the same order of magnitude: the costs have remained within budget. In fact, the costs are less than what was estimated with some methods. As this particular project is not bound by time, it is a good example of continuous migration. Redevelopment is often prohibitively expensive and/or fails. Automated conversion is error prone, delivers unmaintainable code, and is high risk. Reimplemention sits between conversion and redevelopment: the old business‐logic remains, only the underlying technology is changed (see Figure 1). Reimplementation is often tried after (several) failed attempts to redevelop and/or convert. We illustrate this for a state employee payment system. Our cost/risk estimates turned out to be reasonable; its migration progresses as expected without significant problems.