A roadmap for

legacy system replacement

10 practices to drive business success

A contractor’s fable
Like so many good stories, the legacy modernization one draws
inspiration from historic fact. For many years, large systems
integrators framed a modernization effort in technology terms. After
all, they reasoned, the required replacement stemmed from obsolete
technology. Consider the support costs for the underlying
commercial platforms: exorbitant they extolled. And your code: far
too complicated to modify for legitimate business changes. You
need to manage your risk!
As production outages hamstrung the business, old technologies
precipitated calls -- both internal and from these vendors -- for
radical change to this proverbial house of cards. To begin the
painful legacy modernization cycle comes with a simple declaration:
if the system is large, the solution approach must be LARGE, too.
After decades of change and growth of the business, lines of code
numbered in the millions, transactions processed each day may
exceed tens of thousands, budget line items for support are a
noticeable percentage of the business expense, and because most of
the business staff interact with the application almost every day, the
MCCA has become a tolerated way of life.
For very large solutions there is only one answer – a large contract
with teeth, awarded to one of the big boys, a integrator with the
initials sure to appease risk managers and lawyers alike. After all,
who else can staff the hordes of programmers required for this
massive project? Who else has the experience solving these
problems (they run lots of these applications every day), who else
will be so invested in the outcome that failure isn’t an option?
Because the modernization activity is a technology problem, the
solution can be isolated from the day-to-day of the business. The
large vendor stands up a new team skilled in the new technologies
that form the target architecture. Because this project is so big and
will take a while, vendor and client agree to add lots of features
during the replacement. Additional staff is required. Finally, a
contract mechanism is created to ensure that the new system does
what the old system does – requirements documents. The vendor
starts hiring immediately and builds a team ready to work together
for the first time. The legacy team isn’t needed for this activity (or
even consulted); after all, they are the ones who let the existing
system get into such a state!
The project managers build glorious schedules with infinite detail
that show the first release just three years away. Programming
begins. Exuberance dominates the ethos as the excitement of
starting a new project infects everyone. But as the years grind on
and the deadline for the first release approaches, doubt emerges.
There has been no sighting of working code. Or at least anything
that behaves like the existing system. Eventually the deadline
looms without a prayer of a delivery and the obvious cannot be
hidden anymore. The date needs to move. But, it’s just a matter of
planning. We need more planning. Project managers are replaced
and new, better ones arrive.
You can tell where this ends. The project was framed incorrectly, a
number of starting assumptions weren’t validated, a number of clues
along the journey were missed, and expectations are now wildly out
of whack. No late fourth quarter drive can rescue this campaign.
1
Modernizing the backbone of business
Mission critical custom applications (MCCA) are the backbone
of many businesses and government agencies. By definition
and practice, MCCA are so critical to the mission that running
the business without them is inconceivable. Indeed, if an
MCCA breaks, business operations are severely compromised
or may even cease. But the great circle of life applies to
software, too, and what started as inspiration, grew
exuberantly, and matured gracefully into a showpiece of the
business eventually becomes a victim of its own success.
By virtue of its criticality to the business, the MCCA’s
inexorable decay into life-support is cause for grave concern.
Legacy systems are extremely complicated due to decades of
optimization and enhancement, blurred boundaries between
technical and business system, and lost knowledge.
Conventional solutions to the ailing MCCA problem focus on
replacement strategies that concentrate on the software,
ignoring attendant business practices and institutional
knowledge. In an effort to do it all at once, these solutions
often delay first delivery for years and dramatically
underestimate complexity.
The result is high cost, high failure rate, and unpleasant
consequences for the stakeholders. Here, we present a more
effective legacy modernization solution.
Our approach leverages existing business system knowledge
and combines it with expertise in system architecture, design,
product development and integration. Our solution entails
replacing pieces of the MCCA iteratively to deliver measurable
results at frequent and predictable intervals, and leaves the
business with a revitalized team to support evolving business
needs going forward. This highly disciplined yet flexible
approach has demonstrated a high success rate over the last
decade for a number of systems and customers. This white
paper exposes the limits of the “big bang” replacement
approach and offers a legacy modernization framework and
lessons learned to guide management and technology
executives to make the best decisions to strengthen their
mission critical systems.

By the numbers:
In a recent study of 250 larger legacy replacement projects, only 10% came in on-time and on- budget. Fully two-thirds
(67%) had major delays, overruns, or were outright cancelled.

2
 Breaking the Cycle
To replace legacy MCCA demands a very clear understanding of the problem. First and foremost, the legacy MCCA is not just
a computer system. It is a complete business system inside a very rich context that has evolved over a very long time. This
context encompasses business goals, business processes, real-live humans, and lastly the computing system. All of these
elements must be addressed continuously during any replacement effort to increase the probability of a successful outcome.
An appropriate methodology to replace a legacy system consists of four major activities:

INVENTORY
ROADMAP
REPLACE
TRANSITION
It is wrong to think of this as a serial process, or to call these activities phases. It is more accurate to think of these as a
pipeline of concurrent activities with dependencies. Of course, in the beginning, inventory and plan must precede replace and
transition, but eventually all activities may operate concurrently. The astute reader will note that this framework assumes (and
advocates) an iterative replacement strategy.

3
10 practices to drive your success
1. Learn from the past
Whether client or service provider, do your
homework. Learn about the history of the
project. Why was the MCCA created, what led
to its success, what drove modifications, and
most importantly, what other efforts preceded
this one to rebuild or replace the application?
Past efforts will have produced valuable artifacts Case-in-Point:
that you can leverage, or can illustrate pitfalls
and bad choices. Most important of all, the One of the authors was asked to rescue a failed release of major
history will help you learn the stakeholder mission critical system. It took about a year to rebuild the team and
terrain. Be aware of who will ally and who will get the system running smoothly. During this time, the new team
repel change, and why, and who has the most observed that the application was inefficiently constructed: lots of
knowledge useful to the legacy modernization redundant code, too much hardware needed, and a excessive
regression required at each release. The team was eager to
activity. rewrite the application in a modern stack, yet could not formulate a
business case that made sense. The application was very stable,
2. Re-evaluate the business goals the rewrite would be large and risky, and the business could easily
Know what problem you are solving, seek afford the current expense. Three years passed and the underlying
clarity around the business goals, and re-validate development platform vendor forced an upgrade to their latest
the business case. This is a corollary to the version.
carpenter’s dictum: measure twice, cut once.
There are many valid reasons to replace a legacy By that time, there was a body of expertise in the market and great
tooling support for pursuing the modernization effort we had tabled
system and some not so good ones. Frequently, previously. It took less than a year to do the upgrade and in the
the perceived urgency to replace the application process the system was markedly streamlined. Not doing the
or the money to be saved is dramatically replacement years earlier turned out to be the right answer.
overstated. Oft heard is “I won’t be able to find
these skills in a few years.” A small investment
in salary and training to attract fresh skill is a
drop in the bucket compared to the cost to
replace a system. Be sure you can answer the
question “Why now?”

4
3. Don’t underestimate size and complexity
MCCA that have undergone even small changes for decades are
complicated – very, very complicated. Eager to proceed, project
managers or engineers often mistakenly assume equivalence between
software metrics from old and new systems. Their sense of metrics
has been calibrated against systems they have recently created. But
because old applications have almost always lost architectural
integrity and had countless changes implemented over many years to
handle increasingly complicated exceptions to business process, it is
not acceptable to equate new-code metrics to old-code metrics. The
result is often underestimation, sometimes gross underestimation,
which puts the plan at risk, and all the expectation management that
goes along with the plan.
4. Know when to get started
The initial inventory and roadmap activities will provide the
information needed to define the overall MCCA modernization
program as well as the first release. But how will you know when
you have correctly scoped the first release? As mentioned above, the
first release should be planned for implementation in 9 months.
Longer duration indicates a loss of discipline and failure to maintain
the “ship” mentality of a successful product company. You know
you’ve got the right scope when sufficient analysis and prototyping
gives the team 95% confident that they will deliver the scope within
the allotted time-box and within budget. These time and confidence
guidelines will help ensure the initial release successfully delivers
value and fuels forward momentum of the project.
5. Challenge your assumptions about COTS
When contemplating Legacy MCCA replacement of custom
software, decision-makers often assume that there must be a
commercial off-the-shelf software (COTS) package that can address
the problem. The real challenge with COTS-based replacement,
however, is that most businesses are unwilling or unable to change
business processes in order to avoid significant COTS customization
– a major project risk. Therefore, the default position for custom
replacement should be custom rewrite, not COTS package. To test
the feasibility of COTS, look for recent, successful MCCA
replacement of comparable functionality. The existence of an older
COTS package implementation of similar complexity is likely to
have sustained significant customization, making it legacy, too. More
than minor customization of COTS is too risky.
6. Involve the right team from the start
The goal of the inventory and roadmap activities is to coalesce a core
team to determine the system modernization strategy. For maximum
risk mitigation, the core team should have four ingredients: the
highest level of skill, sufficient experience to ensure utmost respect
for the complex MCCA, the smallest possible size that still has
working leadership for each functional domain2, and legacy
knowledge. This team will build a roadmap of how the system will
be replaced, understanding the impact of replacement to user
communities, evaluating the most advantageous cutover plan, and
determining the feasibility of high-risk elements of the new solution.
The team that does the planning must do the implementation; this
group will drive prototyping early, and system implementation later.
5
 Correct Team Size is Critical
Very large software teams are almost
always fatal. In one legacy replacement
program, the leadership team modeled
various team sizes during the roadmap
activity.
The sponsors had asked repeatedly,
"Can we go faster if we add more
people?" The simulations confirmed that
a team size over 35 would drop
probability of success below 50%. The
leadership opted for a team of about 25.
The result was a successful replacement
of a very complicated mission critical
application over a four year timeframe.
7. Leverage existing IP
A software system is a body of code and a team of people. Without the
people who currently operate and know the system, system replacement will
be slower and costlier (experience tells us that it takes at least two years for
a new team to understand the system and business context). Manage project
risk by creating a team that is a hybrid of legacy resources for system
knowledge and new resources for platform and methodological knowledge,
and employ savvy management to meld these two teams into one. Legacy
resources may fear that they will be discarded after the project, so it is
critical to emphasize their key role driving analysis and change
management, and their key role maintaining the system after retirement.
6
8. Don’t go ugly early
Well-run green-field projects observe the GUE principle – Go Ugly
there will be ample opportunity for enhancement. Inevitably, the
Early - that is, tackle your hardest problems first. While the initial
project team will discover that the legacy system is failing to meet the
roadmap activity of a legacy modernization program should assess
business needs in some areas today.
the risk in the most difficult (ugliest) parts of the system, avoid
selecting the most difficult component for a first release. The benefits
Where the system is incomplete, ad hoc business processes and
of having the stakeholder and team see a part of the old system retired
support systems will have grown up to compensate for the deviation
and replaced by something new are numerous.
between business practice and the capabilities of the software
application. It doesn’t make sense to re-implement features that aren’t
Small victories build confidence, processes improve with the practice
used or to inject inefficiency, so go ahead and allow the new system
of delivery, the surprises (and there are always surprises) are smaller
to support the actual business process. But confine enhancements to
and more manageable, and the knowledge learned by delivering offer
the later releases in the roadmap, keep them contained, and be
opportunities for course correction. In reality, the dependencies that
vigilant in avoiding scope creep. If you take the approach that it’ll be
determine the sequence of replacement are unlikely to nominate the
cheaper while the patient is open,
hardest piece first, but should they, the importance of a successful
you may never close the patient.
first release outweighs the value of the risk mitigation derived from
GUE.
10. Address user change management head on
Personnel who use or support the legacy system are often threatened
Be forewarned, though. The first piece to release to production will be
by a replacement activity and defend the status quo in subtle ways.
painful and will likely under-perform. It’s a new team, change
This antipathy must be neutralized. Get senior buy in. Engage and
management is immature, and requirements will be missed. Use this
include stakeholders and actively manage change. Do not over-
experience as a springboard to improve, rather than a reason to back
promise and under deliver, or you will be giving naysayers reason for
off.
criticism. Out of a sense of protecting the business, one key user can
add years to an already lengthy project by obstructing change. If the
9. Do enhancements later
system is already the victim of one or more failed replacement
A large MCCA replacement is subject to getting hijacked as leverage
attempts, jaded users may have honed their skills of obstruction.
to change the business. Don’t fall prey to this dynamic! A good
Change management is essential and must start at project inception.
mantra especially in the beginning is: no new features. Adding
features and trying to change the business are major risk factors to
any MCCA modernization effort. After the replacement is complete,

7
 The iterative legacy replacement approach offers the promise of success that other approaches
can’t. Our depth of experience, technical expertise, and focus on business process enables us to
partner with clients to navigate successful MCCA modernization. For 30 years, we have been
solving our clients’ information technology challenges through shared problem solving and
true partnerships. Today, government agencies, nationally recognized companies, and major
associations routinely turn to us for our sophisticated IT solutions and our highly effective
approach to project management. If you would like to explore a legacy replacement strategy
for your organization we can be reached at:

Larry Fitzpatrick, President

301.656.4030
lfitzpatrick@computechinc.com

Stuart Tweed, Legacy Modernization Practice Lead

301.656.4030
stweed@computechinc.com

For more about Computech’s legacy modernization practice, visit www.computechinc.com