Legacy Application Modernization

What this covers

Many agencies depend on applications written years ago in languages and platforms that are hard to staff and support. Modernization replaces or re-platforms those systems while preserving the business rules embedded in them.

Typical activities

• Application portfolio assessment and prioritization
• Reverse engineering of business rules from code and data
• Strategy selection: rehost, refactor, rewrite, or replace with a product
• Database migration from end-of-life platforms
• Incremental replacement using the strangler pattern to reduce risk
• Parallel running and reconciliation before cutover

What you receive

An assessment and strategy, a modernized application with documented business rules, migrated data with reconciliation records, and a cutover plan.

Considerations for public agencies

Legacy systems often encode statutory rules, fee schedules, and historical exceptions. We document those rules explicitly so the modernized system is auditable and future changes are easier.

Signals that modernization can no longer be deferred

The signals are usually operational rather than technical.

• The vendor or open source community has stopped issuing security patches for the runtime, database engine, or operating system the application depends on, and the agency renews security exceptions to keep it running.
• Knowledge of the code sits with a small number of people, and their departure would leave no one able to change it safely.
• Routine changes, such as a fee schedule update or an added reporting field, are estimated in months and described as risky.
• The application cannot authenticate against the agency identity provider, or cannot produce an audit trail that satisfies a records request.
• The application cannot meet the accessibility standard that applies to it. Under Title II of the Americans with Disabilities Act, a federal rule sets a technical standard based on the Web Content Accessibility Guidelines for state and local government web content and mobile applications, with compliance dates that vary by entity type and size.
• Other systems obtain the application's data through scheduled file transfers because there is no interface they can call.

These matter more together than separately. When several appear at once, the question is usually not whether to act but how much of the system has to change and in what order.

What the agency needs to supply

An assessment is only as good as the material it starts from. Confirm before work begins that the agency can produce:

• Source for every component still in use, including batch jobs, scheduled reports, and utilities that run outside the main application.
• Database schemas and a restored copy of production data. Rules the code does not state are often visible only in the data.
• A list of everything that consumes the application's output, including reports and spreadsheets kept by program staff rather than by IT.
• License and support terms for embedded components such as reporting tools, form engines, and runtimes, since some cannot be re-hosted without renegotiation.
• Time from the program staff who can say whether an unusual rule reflects statute, local policy, or a workaround that outlived its reason.

Program staff attention is the scarcest input and the one most often left out of the plan. Name those people and secure their supervisors' agreement before the schedule depends on them.

What to require in the solicitation

• Make the catalog of recovered business rules a named deliverable with its own acceptance criteria, due early rather than at closeout.
• Require written reconciliation criteria before any data is migrated: record counts, control totals, a stated tolerance, and how a difference outside it will be explained and approved.
• Require a rehearsed rollback for each cutover, a go or no-go decision point, and a named agency decision maker.
• Require source, infrastructure definitions, pipelines, and tests to build from a clean checkout on infrastructure the agency controls. A modernization the agency cannot rebuild has traded one dependency for another.
• Ask bidders what will be running in production at the end of each increment. A plan that reaches production only in a final phase concentrates risk where the budget has least room left.
• If the proposal replaces the application with a commercial product, require the bidder to state which current rules the product will not support and how each gap is to be closed.
• Set license and data terms so that schema changes and extracts of the agency's own records are not billable events.

Measuring whether it worked

Take a baseline while the old system is still running, then measure the same things after stabilization rather than at go-live.

• Elapsed time and staff effort for a representative small change, using comparable requests before and after.
• Security exceptions and unsupported components attributable to the system.
• Manual workarounds retired: re-keying between systems, shadow spreadsheets, and side databases built around the old system's limits.
• Availability and error rates on the interfaces other systems depend on, compared with the file transfers they replaced.

Expect some of these to look worse in the weeks after cutover, and judge the result once the workarounds have been retired.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions