How Local Governments Can Retire Legacy Systems Without Losing Access to Historical Records

How Local Governments Can Retire Legacy Systems Without Losing Access to Historical Records

Local governments have a technology problem that doesn't always look like a technology problem.

A city replaces its financial system.

A county moves to a new permitting platform.

A clerk's office implements a modern records system.

The new application goes live. Employees move over. The implementation is finished.

But the old system stays.

Sometimes for years.

The reason can be surprisingly simple: it still contains records people need.

An employee may need a permit issued 12 years ago. Finance may need an old payment or invoice. A records request may involve information that predates the current system. An auditor may ask for transactions from a prior fiscal year.

The application isn't really running the department anymore, but nobody feels comfortable turning it off.

That's one of the strongest signs a legacy system may be ready for retirement. The application itself has lost much of its operational value, but the information inside it hasn't.

For local government IT teams, that creates a difficult question: how do you complete a legacy system retirement without losing practical access to the records and institutional history stored inside it?

The answer starts by separating the system from the information it holds.

The application and its records don't have the same lifespan

Think about how many systems can exist across a city or county.

Finance, utility billing, permitting, business licensing, code enforcement, planning and zoning, public works, courts, public safety, human resources, parks and recreation, document management, property and assessment systems.

Eventually, some of those applications will be replaced.

The information inside them doesn't necessarily follow the same lifecycle.

A permitting application may be obsolete while historical permit records remain useful. A financial system may be replaced while prior transactions still need to be available for audits or research. A utility billing platform may reach end of life while years of account history remain relevant.

That's why retirement can't be treated only as an IT decision about whether the software is still useful.

There's a separate records question:

What information still needs to exist after the application is gone?

Once those two decisions are separated, there are more options than simply keeping the old system running.

Start with what actually needs to be retained

Before deciding where historical data should go, determine what needs to remain in the first place.

Not every record should be kept forever.

And retiring an application doesn't automatically mean the records inside it can be deleted.

The rules vary by state, jurisdiction, record type, and circumstance. Cities and counties need to work from the retention schedules and records-management requirements that actually apply to them rather than assuming there's a universal government retention period.

The federal government follows the same basic principle, although its requirements are different from those governing local agencies. The National Archives and Records Administration uses formal records schedules to establish how long federal records should be maintained and when they may be disposed of. NARA describes approved records schedules as the legal authority for disposition of covered federal records.

For a city or county, the practical exercise is similar even though the governing authority will be different.

Which records must be retained?

How long do they need to remain?

Which records are eligible for disposition?

Are any subject to a legal hold or another preservation requirement?

Do some have permanent historical value?

Which records will employees continue using after the source application is gone?

Those decisions should happen before the migration architecture is finalized.

The new system doesn't necessarily need every old record

One of the easiest assumptions to make during modernization is that all historical information should move into the replacement application.

Sometimes it should.

But decades of history can add significant complexity to a legacy data migration.

The old and new applications may use completely different data models. Fields don't always line up. Codes change. Historical records may contain structures the replacement system was never designed to support.

A migration team can end up spending significant time mapping and transforming 20 years of information that users may access only occasionally.

A more useful question is:

What historical information does the new operational system actually need?

Current accounts, active permits, open cases, and information required for today's processes probably belong in the replacement application.

A closed permit from 2004 may not.

That doesn't mean the permit disappears.

It means there can be a difference between information that needs to be migrated into the new operational system and information that needs to remain available historically.

For a city trying to replace an aging application, that distinction can change the scope of the project considerably.

But don't keep everything just because storage is cheap

The opposite approach creates its own problem.

Exporting the entire database and keeping it forever isn't much of a records strategy either.

If records have satisfied their required retention period and are eligible for lawful disposition, continuing to preserve them can create unnecessary cost, security exposure, and governance responsibility.

The retirement process should determine what should move, what should remain available somewhere else, and what can be disposed of through the organization's approved process.

That work usually crosses organizational boundaries.

IT understands the system.

Departmental owners understand the information and how it's used.

Records staff understand retention.

Legal may need to address holds or other requirements.

Security understands the risks around continued access.

Getting those people involved before the old application disappears is much easier than trying to reconstruct those decisions years later.

Then ask what happens when someone needs an old record

This is where a technically successful retirement can still leave a practical problem.

Suppose a city exports 15 years of information from an old permitting system.

The export is validated and moved into secure cloud storage. The old application is shut down.

Three months later, someone in planning needs a permit from 2013.

Now what?

If IT can retrieve it from storage and these requests happen twice a year, that may be completely reasonable.

Not every historical dataset needs another user-facing application.

But imagine the department needs old permits every week. Employees search by address, permit number, property owner, or date. They need to inspect related records and occasionally export what they find.

Now asking IT to retrieve every historical record isn't really an archive strategy.

It's a manual access system.

This is why retaining information and providing historical data access aren't always the same requirement.

For rarely accessed information, archival storage may be enough.

For historical information that remains part of normal government work, access needs to be designed into the retirement plan.

Leaving the old system running has a cost

Keeping the application online can feel like the safest choice because nothing has to change.

It also has a way of becoming permanent.

Another annual renewal gets approved. The server stays online. IT continues supporting it. Accounts remain active. Backups continue. Security teams keep accounting for it.

Someone maintains enough institutional knowledge to keep the system usable.

A temporary legacy environment quietly becomes “that old system we've had forever.”

The broader government experience shows why this deserves attention. GAO reported in 2025 that federal agencies have historically directed roughly 80% of annual IT and cyber-related investment toward operating and maintaining existing systems.

That spending includes much more than legacy technology, and federal IT spending isn't a direct benchmark for a city or county. But GAO continues to identify aging systems as part of the government's modernization challenge.

The local calculation is simpler.

What does this particular application cost to keep running, and what is it still doing for us?

Licensing is part of it.

So are infrastructure, database costs, backups, security, vendor support, internal IT time, and the knowledge required to keep an aging application usable.

Those costs may be completely justified when the system continues providing meaningful operational value.

They're harder to justify when its primary job has become showing someone a record from 2011.

There's a security cost too

Local government IT teams rarely have unlimited cybersecurity resources.

Every application that stays operational remains part of the environment they have to protect.

CISA's cybersecurity guidance for state, local, tribal, and territorial governments recommends replacing legacy systems and devices where possible, while isolating and closely monitoring legacy technology that cannot yet be replaced.

That doesn't make every old application insecure.

It does mean continued operation comes with responsibilities.

The system needs appropriate access controls. Supporting operating systems, databases, and infrastructure need to remain supportable. Vulnerabilities have to be managed. Accounts need to be maintained. Monitoring may need to continue.

For a system delivering an essential public service, those responsibilities can be completely justified.

For an application that's only being kept alive because someone might need an old record, it's reasonable to ask whether there's a better way to provide that access.

Don't start with the technology

It's tempting to jump straight to the destination.

Move it to the cloud.

Put it in an archive.

Move everything into the new system.

Keep the database.

But the right destination depends on what people still need from the information.

Start with the legacy environment as it exists today.

Who owns it?

Which departments still use it?

What integrations depend on it?

What does it cost to operate?

What information does it contain?

Then work through the records.

Determine what needs to remain under the government's applicable requirements, what's eligible for disposition, and whether any records have special preservation or access requirements.

From there, separate current operational needs from historical ones.

Some data needs to move into the replacement application because today's processes depend on it.

Some needs to be preserved but may rarely be accessed.

Some may be eligible for disposition.

And some may need to remain regularly searchable even though it doesn't belong in the new operational system.

That's when the technology decision gets easier.

Figure out how the history will actually be used

Once you've identified the historical information that will remain, ask what happens after retirement.

Who will need it?

How often?

What do they typically search for?

Do they need individual records or larger exports?

Do they need attachments?

Can retrieval reasonably go through IT, or does the department need self-service?

A city that needs an old dataset twice a year has a very different requirement from a planning department that searches historical permits every day.

Both may need to preserve information.

They don't necessarily need the same solution.

This is an important distinction because it's easy to overbuild historical access just as it's easy to underbuild it.

If raw or archival storage satisfies the actual requirement, use it.

If employees regularly need to interact with the information, design for that instead.

Historical access doesn't require preserving the old application

This is the architectural idea behind a Historical Access Layer.

The new operational system handles today's work.

Appropriate storage preserves the underlying historical information.

The access layer gives authorized employees a structured way to find and use the historical records that still matter.

It doesn't recreate the old application.

If you're retiring a 20-year-old financial system, you don't need to rebuild its workflows, transaction processing, or every screen users once saw.

Those capabilities belonged to an operational application.

Historical access is a narrower requirement.

Preserve the right information, keep enough context that people can understand it, control who can see it, and give authorized employees a practical way to retrieve it.

Then let the original application go.

What that might look like for a city

Imagine a city replacing a legacy financial system.

During planning, the city determines that recent financial history should move into the new ERP because employees use it regularly as part of current operations.

Older transactions still need to be retained according to the city's applicable requirements, but they don't need to live inside the new ERP.

Instead of forcing decades of history into the replacement system or keeping the old financial application running indefinitely, the older records are preserved separately.

Finance employees can still find the retired system's historical datasets, search for transactions, inspect records, and export information when necessary.

The new ERP isn't carrying decades of information it doesn't need to perform today's work.

The old ERP doesn't have to remain operational for occasional historical lookups.

And IT doesn't become the permanent help desk every time someone needs an old transaction.

That's the gap a Historical Access Layer is intended to fill.

The right answer may still be to keep the system

Legacy system retirement shouldn't become a goal by itself.

Local governments operate under real constraints. Budgets are limited. IT teams are often small. Procurement can be slow. Departments have competing priorities. Some older applications support critical public services and can't be replaced casually.

If a legacy system is still doing an important job and replacing it would introduce more cost or risk than continuing to operate it, keeping it may be the right decision.

The question is whether the application is still earning that investment.

Sometimes modernization means replacing it.

Sometimes it means consolidating systems.

Sometimes it means moving workloads to supported infrastructure.

Sometimes raw archival storage is enough for the historical records.

And sometimes the only thing preventing retirement is that employees still need practical access to the data.

That's a much narrower problem than replacing an entire operational system.

Separate the system decision from the data decision

A city or county shouldn't have to choose between maintaining an obsolete application forever and losing access to its institutional history.

Treat them as separate decisions.

Does the application still need to run?

What information still needs to survive?

Where should that information live?

How often will people need it?

Who should be able to access it?

What should happen when its retention period ends?

Once those questions have answers, the retirement path becomes much clearer.

The system can reach the end of its life without the useful history inside it reaching the end of its own.

That's ultimately what a good retirement plan should accomplish:

Retire what no longer needs to run.

Preserve what still needs to exist.

And make sure the people who legitimately need the history can still use it.