How to Modernize Legacy Applications: A Step-by-Step Guide

To modernize legacy applications, work through twelve steps for one application: agree the goal, list what you have, pick the first application, measure it, choose a route, test, release in small pieces, run old and new together, switch users over, retire the old parts, measure again and hand over. Each step has an owner and an output.

Modernizing an application means changing its code, structure or connections so that it is easier and safer to change, run and connect, which goes beyond moving it to new hardware. In short, this guide covers the order of work for one application, after the decision to change it. It leaves out the signs that an application needs work, scored reviews and a comparison of the options. This is work Signisys carries out for clients; see how Signisys changes an existing application.

How Do You Modernize Legacy Applications, Step by Step?

The work runs in twelve linked steps, each resting on the one before, and it applies to a single application at a time. A sound order is:

1. Agree the goal.
2. List what you have and who owns it.
3. Pick the first application.
4. Set the before baseline.
5. Choose the route.
6. Set tests and a safety net.
7. Release in small pieces.
8. Run old and new side by side.
9. Cut over (switch users from the old to the new).
10. Retire the old parts.
11. Measure against the baseline.
12. Hand over.

Every step has an owner. We recommend a business owner for the goal and the go/no-go decision, an application owner, a technical lead and a named approver for each release. With that split, a leader can also see who is accountable for each step.

A change that is decided and then left idle is harder to restart, so the order matters more than the speed. Signs, scored checks and the choice between options are outside this guide. To decide whether an application is due for change, read the eight warning signs and what each costs. This one covers the build order only.

Steps 1 and 2: Agree the Goal, List What You Have

Step 1 is to write the goal as one business outcome that the owner can check. For example, a change that takes weeks should take days, or a report that needs a person should run alone. IT and the business unit agree it before anyone discusses a route, because the two groups can want different things. Owner: the business owner. Output: a one-page goal with a date to review it.

Step 2 is to list the applications, the data each one holds, the links in and out, and the people who run and use it. Also write down the business rules inside the code. In practice, some of them appear in no document, so ask the people who use the application what it does for them. Documentation is likely to be incomplete, and a rule that nobody wrote down is easy to lose when the code changes.

The application owner builds the list with the technical lead. Together they put a named owner against each application. Owner: the application owner with the technical lead. Output: an inventory with a named owner for each application, and a list of rules that are written nowhere else.

This list is also the base for every later step. If you plan to modernize legacy code, start here: no one can safely change what the team has not described.

Steps 3 and 4: Pick the First Application, Set the Baseline

Step 3 is a short rule that a business owner can apply. Next, ask four yes or no questions about each application:

• Does it have one named business owner?
• Does it have a goal from step 1 that you can measure?
• Is it small enough, with few outside links, to show a first result in a few months?
• Does the business lose little if the first release is slow?

Pick the application with the highest number of yes answers. The oldest or the costliest application is a poor default, because it can carry many links and leave little room for a slow first result. Add a stop rule as well. For example, if the value is low, a replacement is ready or retirement is near, write “retire” against it and move on. Owner: the business owner. Output: one chosen application and a written reason.

Step 4 is to measure the old application before you change it. For a wider look at the application first, run an assessment checklist that rates each area of the application. Take five measures:

• the time to make a change;
• failures in a month;
• the effort to run it, in people and hours;
• the effort for each release;
• the wait a user sees.

Use the same measures and the same method again at step 11, so the before and after are comparable. Owner: the application owner. Output: a one-page baseline with dates.

Step 5: How Do You Choose the Route for One Application?

Step 5 is a short rule of four questions, asked in this order. Each has one outcome. For a wider view of the routes across many applications, read how modernization routes compare across a portfolio.

If the answer is to move the application unchanged, that is a different job, covered in the use case on moving an application unchanged.

Owner: the technical lead, with the application owner agreeing. Output: one sentence that names the route and the reason.

Steps 6 and 7: Test, Then Release in Small Pieces

First, before the first release, a team needs a record of how the application behaves today. To modernize legacy applications safely, treat that record as the starting point for the work.

Step 6 is to write down the key business actions, the numbers that a finance or operations user relies on, and the reports. These become the tests that the new part must pass, and the business owner signs the list. Then set the way back before the first release: who may stop the work, what is switched off, and how data is put right. Owner: the technical lead and the business owner. Output: a test list with sign-off, and a written way back.

Step 7 is to release in small pieces. A small release is one business action, or one part that users can notice. Also ship it with an on/off switch, so that the team can turn it off without a full roll-back. Then state what the release must prove before the next one starts. The idea of gradual replacement of an application part by part describes building new parts beside the old and moving behaviour across a bit at a time. Also, the team chooses its own cadence and writes it down.

Owner: the technical lead, with a named approver for each release. Output: a release list, each release with its check.

Steps 8 and 9: Run Old and New Together, Then Cut Over

For a time, both versions run. Step 8 is to decide who sees which version, how records stay in step, and how long both are kept, with an end date. Keep one agreed place that holds the truth for each record, and do not allow two-way editing. We recommend a regular check that the records in both versions agree. Running both has a cost in people and effort, so state it up front.

Then compare the outputs against the step 6 tests, and watch failures and the wait a user sees. The full comparison of all five measures waits for step 11, because change time, run effort and release effort are not readable while both versions run. The technique of putting a layer between callers and the old part dates from 2014. It then switches callers to the new part, compares old and new behaviour in test and deletes the old part once nothing uses it. Owner: the application owner. Output: a comparison log.

Step 9: Who Decides When to Cut Over?

Step 9 makes the cut-over a decision that a named owner takes at a go/no-go meeting, with the date following from it. Hold a go/no-go meeting with a named owner, and keep it away from month-end, quarter-end and audit dates. In practice, agree the go and no-go conditions in writing before the meeting, so the decision is not made under pressure. Also pause other changes for a short time, and keep the way back from step 6 ready until the old version is retired.

Owner: the business owner decides, and the technical lead executes. Output: a signed go/no-go and a record of the cut-over.

Steps 10 to 12: Retire the Old Parts, Measure and Hand Over

Step 10 is to retire the old parts in a set order. First confirm that nothing still calls the old part, including scheduled jobs, reports and links from other systems. Next, keep the data that law or the business needs in a place where it can be read, remove access and licences, switch off, and sign off. Rules for data retention depend on your sector, so ask your own regulator or auditor what applies. Owner: the application owner, with sign-off by the business owner. Output: a retirement record that lists the data kept, the access removed and who signed.

Step 11 is to take the step 4 measures again, with the same method, and put the before and after side by side against the goal from step 1. Also say plainly what did not improve. Owner: the application owner. Output: a before and after page, shown to the business owner.

Step 12 is to hand over, so that the team can support, govern and improve the application. In practice, write a runbook, name an on-call owner and a second person, and keep the test list running. Aim for a new joiner to be able to learn the application from the runbook. Owner: the technical lead. Output: a runbook and a named owner. Then pick the next application with the step 3 rule.

Which Set-Up Mistakes Trip Up Each Step, and What Fixes Them?

We recommend avoiding one set-up mistake at each step. The table is Signisys’ working view, not a finding from any study.

How Can You Start to Modernize Legacy Applications This Week?

Start with steps 1 and 2 for one application: write the goal and list the owners. Three actions fit this week:

• Pick one application that the business wants changed.
• Write its goal as one outcome with a date to review it.
• List its data, its links and the person who owns it.

Finally, ask for help when several applications are linked, when no one knows the code, when an audit or contract date is fixed, or when no second person can review the work. This guide does not cover signs, scored checks or the comparison of options, so read it for the order of work only. For choosing between options, read decision rules and tie-breaks for each application.

Signisys provides application modernization work, and you can follow this guide on your own. To plan the first application with a specialist, see application modernization for mid-size firms, the solution for changing applications and watching them run and the delivery and automation services that support it.

Modernize Legacy Applications FAQ: Quick Answers