Assess before you modernize

An old system can be difficult to use and still do something your organization cannot afford to lose. A newer system can look better and make the actual service worse.

That is why we start modernization with an assessment. Before choosing a platform or drawing replacement screens, we want to understand what the current service does, where it fails, and what people depend on it to preserve.

For a government agency, that means looking beyond the application. The service includes residents, staff, records, approvals, phone calls, and work that happens after someone closes the browser. The same is true for an organization whose internal system keeps daily operations moving.

A wholesale rebuild is a possible conclusion. It should not be the starting assumption.

Start with the service people need

Describe the result someone is trying to get. A resident needs to submit a request and learn what happens next. A staff member needs to review it, resolve missing information, and record a decision. Those needs matter more than the age of the software.

Watch people complete ordinary tasks. Include people who need assistance, use assistive technology, or cannot finish online. Ask staff where they have to explain the screen, enter information again, or take the work somewhere else.

Useful questions include:

• Who uses this service, and who has trouble reaching or completing it?
• Where does a request wait, and what is it waiting for?
• Which errors can users correct themselves?
• What happens to someone whose situation does not fit the form?

Separate a software limitation from an unclear policy or an approval nobody owns. Rebuilding a queue will not resolve a disagreement about who should act on it.

Follow the work beyond the screen

Trace a request from arrival through completion, including corrections, appeals, and later questions about the record. Compare the written procedure with what staff actually do.

A spreadsheet beside the application may fill a reporting gap. A printed checklist may carry an exception the software cannot represent. A repeated phone call may be the only way another department learns that work is ready.

Do not assume every workaround should become a feature. Ask why it exists, who relies on it, and whether the underlying step still serves a purpose.

Then map the dependencies. Identify the systems that send or receive information, scheduled transfers, shared sign-in services, reports, and outside providers. Find out who owns each connection. Ask what happens when it is late, unavailable, or changed without notice.

An integration that runs quietly in the background is still part of the service. It needs a place in the assessment even if nobody wants it in the new interface.

Understand the records and the obligations

Before planning a migration, establish which records are authoritative. Check how identifiers, attachments, status changes, and decision history fit together. Find out where duplicates and conflicting values come from.

Can you explain what a field means without asking the person who created it? Can you export a record with enough context for someone else to understand it? What would demonstrate that a transfer preserved the information correctly?

Bring the people responsible for security, accessibility, privacy, and records into this work. Ask them to identify the requirements that apply and the evidence needed to review a change. The assessment should document those requirements rather than guess at them.

Examine who can view, change, export, and delete information. Ask how access is removed when responsibilities change. Identify sensitive material, retention needs, audit history, and the boundaries on where data may be stored or processed.

A new interface does not establish that these needs have been met. They belong in the decision and in the eventual acceptance criteria.

Name the owner and the failure modes

Find the person accountable for the service, as well as the people who maintain the software. These may be different roles. Make clear who can approve a change, respond to an incident, and decide whether the service is ready to resume.

Look at support arrangements, documentation, deployment access, backups, and recovery procedures. Ask whether someone other than the usual maintainer can follow the instructions. A backup that exists is different from a recovery process someone has tested.

Consider failures that interrupt the work or quietly damage it:

• A submission appears successful but never reaches a reviewer.
• A transfer runs twice and creates duplicate records.
• A dependency goes offline while a request is being processed.
• An incorrect permission exposes information to the wrong person.

For each relevant failure, ask how it would be detected, who would respond, and how affected work would be reconciled. Include any temporary manual process and how its records would return to the system.

Replacement does not remove the need for operational ownership. It can add another system to operate during the transition.

Write down what must survive

Make preservation explicit before discussing removal.

That might include familiar terms, stable record identifiers, accessible paths, useful exports, decision history, or an exception staff handle correctly today. It may include the ability to keep accepting requests during an outage.

Preserving a behavior does not require preserving its current implementation. It requires knowing why that behavior matters and how you will check it after a change.

Keep a short list of what works, what fails, and what remains uncertain. Tie each proposed change to an observed problem. If the reason is only that the current technology looks dated, the case needs more work.

Choose a response for each part

The assessment should support a decision your service owner can explain. Different parts of the same system may deserve different answers.

Repair when the problem is bounded and the underlying system remains supportable. A confusing form, failed transfer, or missing alert may warrant a focused change. Check that the repair addresses the cause and can be maintained.

Replace when essential needs cannot reasonably be met within the current system. Unsupported dependencies, constraints on access controls, or workflows the system cannot handle may support that choice. Include data migration, staff preparation, parallel operation where needed, and a tested way to recover if the transition fails.

Retire when a function no longer serves a needed purpose or duplicates a service that can take over. Confirm that no users, reports, or downstream processes still depend on it. Assign responsibility for retained records and explain where unfinished work will go.

Leave alone when a component meets current needs, has acceptable risks, and has a clear support owner. Record why it stays and what would trigger another review. Leaving it alone still includes routine maintenance and monitoring.

For each option, compare the service benefit, disruption, dependencies, ongoing support burden, and uncertainty. Where evidence is missing, define a small investigation before committing to the larger change.

End with a decision you can test

A useful assessment leaves you with a service map, named owners, documented risks, preservation requirements, and a recommended next step. It also says what you still do not know.

The next step might be a repair, a recovery exercise, or a narrow test of a replacement workflow. Give it a concrete question and a clear way to judge the result before expanding the work.

If the project is a fit, we can build a working prototype before you pay. That can help test an uncertain workflow. It does not substitute for security review, migration testing, or the approvals your organization requires.

Modernization should leave your service easier to use and easier to run. Start by understanding what you have, then change what the evidence supports.