Replace the system or modernize around it: a decision guide

Reference article · 8 min read

Every agency has at least one system that most people agree is a problem. It runs a core program, it was built long ago, the staff who understand it are retiring, and changes take longer than the program can tolerate. Eventually something forces the question: an end-of-support notice, an audit finding, a change in law, or an outage. Replace it, or work around it.

Four answers are defensible. Which one is right depends on facts about your system, your data, and your organization rather than on a general preference for building new or keeping what works. The wrong one often gets chosen for reasons unrelated to the system: replacement because it fits a budget narrative, inaction because no one wants to own this year's risk.

Full replacement

Retire the existing system, stand up a commercial product or a custom build, migrate the data, and cut over.

Where it fits: the business process has changed, or needs to change, and the current design prevents it. The platform can no longer be patched or staffed. A mature product exists for the process, and leadership is willing to change local practice rather than customize heavily. Replacement is also the only option that eventually ends the cost and risk of the old platform outright, leaving one system to operate, secure, and train people on.

Where it fails: requirements get written from what the old system does rather than from what the program needs, undocumented rules surface during testing, and data migration is planned as a task when it is a project of its own. It is usually the wrong choice when the real complaint is integration or reporting, or when no one on the program side can act as a full-time product owner.

Incremental modernization using the strangler pattern

Leave the old system running and move one function at a time into new components, routing traffic to each piece as it is finished, until little of the original remains.

Where it fits: systems whose functions can be separated, and situations where continuity matters more than speed. It converts one large commitment into a sequence of smaller ones, each of which can deliver something usable and be evaluated on its own.

Where it fails: it requires engineering discipline sustained across multiple budget cycles and changes of leadership. Two systems run at once, with the data synchronization, duplicated support, and dual operating costs that implies, so total elapsed time and total spend can end up higher than a single replacement. If every function writes directly into one shared database, there is nothing to separate until the data layer is addressed. Work without a visible delivery date can lose funding before it finishes.

Re-platforming

Move the system to current infrastructure with minimal change to the application: cloud or modern virtualization, supported operating system and database versions, a current runtime.

Where it fits: buying time. If the hosting arrangement is the emergency and the application itself is tolerable, re-platforming can remove the immediate support and security risk on a shorter timeline than a replacement. It also works as the first step of a longer plan, because a system in a supported environment is easier to instrument, test, and eventually separate into parts.

Where it fails: it changes nothing about functionality, maintainability, or the shrinking pool of people who know the language, and the relief it provides is easily mistaken for a finish line. Hosting costs can also rise if the system is never adjusted to the new environment.

Leaving it in place and building an API layer

Keep the system as the system of record and put a documented interface in front of it, so portals, dashboards, and other systems can read and write without touching the core.

Where it fits: the core processing is reliable and the pain is at the edges, such as no self-service for residents, no usable data for reporting, or manual re-keying between systems. An API layer is usually smaller in scope than a replacement and creates a seam: once consumers use the documented interface instead of the database, what sits behind it can be changed later with less disruption.

Where it fails: it does not extend the supported life of the platform, and it can hide decay. Wrapping a system that cannot be patched leaves the same exposure behind a more convenient surface. If the underlying data model is wrong, the interface inherits it. It is also one more component to build, secure, version, and support.

How to decide

Work through these in order. The first few usually remove at least one option from consideration.

What is forcing the decision, and when does it take effect? Write down the specific event and its date: a vendor end-of-support notice, an audit finding with a response deadline, a statutory or regulatory change with an effective date, hardware that can no longer be replaced. If that date is short relative to a normal procurement and implementation cycle, replacement is not available as the answer to it, and the real question is which holding action to take first. If there is no dated event, you have time to assess, and assessment is a better use of it than starting a procurement.

Is the pain in the core or at the edges? List the top complaints from program staff and mark each one as core (the rules the system applies, how work moves through it, what it can record) or edge (access, reporting, integration, re-keying between systems). Mostly edge points toward an interface. Mostly core points toward replacement or incremental modernization. A mix usually means the edges can be addressed now and the core decided with better information later.

Can the system be divided? Inventory everything that reads or writes the database directly, including other agencies' systems, reporting tools, and scheduled scripts. If most access bypasses the application, the strangler pattern is not available until that access is mediated, and the first increment is building that mediation rather than replacing a function.

Where are the business rules written down? Pick one rule that matters and try to produce both the written authority for it and the code that implements it. If neither the program nor IT can do that for a representative sample, rule extraction is a project in its own right, and it belongs before a replacement rather than inside one.

Who is the product owner, and what can they decide? Name a person on the program side who can approve process changes without escalating each one, and get their committed time in writing. Replacement demands the most from this role and incremental modernization nearly as much, while re-platforming and an API layer demand the least. If the role cannot be filled, choose the option that depends on it least.

What condition is the data in? Profile it before committing: completeness of required fields, duplicates, values that no longer match current code lists, records that would fail today's validation rules. Poor data does not rule out any option, but it changes the sequence and the estimate, because migration effort usually tracks data quality more closely than record volume.

Can you afford to run both systems at once? Estimate the old system's operating and support cost across the full transition and check it against the budget alongside the new work. If the budget does not cover both, any option that creates a long overlap carries more risk than its schedule suggests.

What is left if the money stops partway through? Incremental work leaves completed functions running in production. A single cutover can leave a partly built system and the old one still in service. Ask this question about each option at its worst plausible stopping point, not at its planned end.

What obligations follow the data? Records retention schedules and public records requirements apply to the new system and often to the migration itself. Depending on what the system holds, additional security or privacy requirements may apply, such as those covering criminal justice information, protected health information, federal tax information, or payment card data, and accessibility requirements commonly apply to public-facing interfaces. Confirm with your records officer, security officer, and counsel which of these apply in your jurisdiction rather than assuming.

What this means for your solicitation

Consider buying an assessment first, as a small separate procurement: data profiling, business rule extraction, and an options analysis with cost ranges. State clearly whether that vendor may compete for the implementation.
Describe the current environment accurately, including interfaces, record volumes, and known data problems. Proposers price uncertainty, and undisclosed problems tend to surface later as change orders.
Ask proposers to price a defined sequence of increments and to state what the agency owns and can operate after each one.
Require documented data export throughout the contract, not only at termination, along with ownership of configuration and documentation.
Budget the old system's operation and support across the whole transition. Underfunding the overlap is a common reason incremental plans collapse.

HQT provides legacy system assessment, incremental modernization, integration, and custom software development services.

Frequently asked questions

Is full replacement always more expensive than modernizing incrementally?

Not necessarily, and the comparison is often made on uneven terms. Replacement estimates frequently leave out the cost of operating the old system through the transition, agency staff hours for configuration and testing, and data remediation, while incremental plans carry those costs visibly from the start. Incremental work has its own cost problem, because two environments run in parallel for longer and the total can exceed a single replacement. Compare the options over the same period and include operations of both systems during any overlap.

How do we know whether the strangler pattern is possible for our system?

Look at how data moves rather than at the code. If other systems, reports, and scripts read and write the legacy database directly, every function you move has to keep that database consistent, which can be more work than the function itself. If access already goes through defined interfaces or a service layer, separating functions one at a time is far more practical. Where it is not practical yet, mediating that data access can become the first increment.

Does moving to the cloud count as modernization?

Moving unchanged software to cloud infrastructure is re-platforming. It can remove hardware and hosting risk and make later work easier, but it does not improve the application, and costs can rise if the system is never adjusted to the new environment. Treat it as one step with a defined benefit rather than as the end of a modernization program.

The vendor announced end of support and we cannot finish a replacement in time. What do we do?

Separate the security problem from the functionality problem. Where the vendor offers them, extended support agreements can buy defined time, and network segmentation, tighter access control, and increased monitoring can reduce exposure while a longer effort proceeds. Document the compensating controls and the date each one expires, because auditors, insurers, and oversight bodies will ask what the plan is.

Who should own this decision, IT or the program?

The program owns the outcome, IT owns feasibility and technical risk, and neither can decide alone. A workable arrangement names a program-side sponsor who can commit staff time and approve process changes, with IT accountable for assessment, security, and integration. If no one on the program side will take that role, a replacement is unlikely to succeed this cycle, and a smaller step is usually the better choice.