When Is a Public-Safety Software Implementation Actually Finished?

Lessons for Texas public-safety agencies from Lubbock County's multi-year Tyler Technologies transition.

Go-live is not the same thing as done.

Completion means operational workflows work, converted data is trustworthy, confidential and public access behave correctly, integrations and reporting work, users are trained, known issues have owners, workarounds are not becoming permanent, and acceptance criteria have been met.

What evidence will tell us this implementation is actually complete?

Why this case matters

Lubbock's public record spans procurement, go-live, conversion, confidentiality and public access, training, and years of post-go-live work. It is not an assessment of Lubbock County staff. Implementation success can vary by workflow and department inside one organization.

Define "done" before the project begins

If the only agreed definition of done is "the system is live," the project can succeed on the calendar while conversion, access, workflow, training, or reporting work remains unfinished.

Write an operational definition: agreed workflows function; required records are converted; balances and counts reconcile or the differences are explained; permissions, integrations, and reports are validated; users are trained; exceptions are documented; go-live criteria are met; post-go-live issues stay below agreed thresholds; the customer accepts the implementation.

Go-live is a milestone. Acceptance is a decision.

Use measurable exit criteria

For every phase, write down five questions before the work starts:

• What must be true?
• What evidence proves it?
• Who approves it?
• What can be deferred?
• What would block progression?

Treat data conversion as preservation, not import

A successful conversion preserves the meaning and relationships in historical records—not merely the records themselves. Lubbock's experience illustrates why confidentiality, restrictions, permissions, documents, and metadata must be validated alongside field values.

Validate more than counts

• Counts
• Identifiers
• Relationships
• Confidentiality and restriction flags
• Documents and attachments
• Balances
• Statuses
• Record history
• Public versus private visibility
• Search
• Permissions

For exports, mapping, attachments, and conversion validation, read the Public Safety Data Conversion Guide.

Include difficult historical records

Do not only test recent, clean cases. Sample the records most likely to break the assumptions:

• Old cases
• Expunged or non-disclosed matters
• Sealed or confidential records
• Records with many documents
• Complex relationships
• Inactive users
• Unusual dispositions
• Legacy code values

Test real workflows—not just screens

Screen-level testing asks whether a user can open a page. Operational testing asks whether the work can still move from one role to the next.

Use end-to-end scenarios

ARREST  ->  BOOKING  ->  CHARGE  ->  ATTORNEY ASSIGNMENT  ->  COURT  ->  RELEASE

CASE FILED  ->  DOCUMENT  ->  DISCOVERY  ->  ATTORNEY ACCESS  ->  COURT ACTION

RECORD CREATED  ->  CONFIDENTIALITY APPLIED  ->  SEARCH  ->  PUBLIC PORTAL  ->  AUTHORIZED ACCESS

Include every stakeholder

A system can pass an IT test and still fail an operational one. If defense users, jail staff, or a partner agency cannot complete their part of the work, that workflow is not finished—even if the login screen works.

Treat permissions and public access as go-live features

Public and internal access are separate workflows. Before cutover, test both what each role can see and what it cannot—especially against converted historical records.

Create personas that match the actual operation, then test what should be visible and what should not:

• Public user
• Clerk
• District clerk
• Prosecutor
• Defense user
• Judge
• Jail user
• Records staff
• Administrator

For each role, test documents, images, confidential flags, sealed or expunged records, and historical records.

Test denial, not only access

Don't test only whether authorized users can find a record; verify that unauthorized users cannot find it.

Test legacy confidentiality

Do not assume a new portal can infer that a record is confidential if the legacy data does not contain enough information. Where the source is ambiguous, identify exceptions, establish manual review, document remediation, and delay public exposure when appropriate. Verify current legal requirements with counsel and the records custodian before deciding what may be published.

Build training and workarounds into the implementation plan

If staff are inventing extensive workarounds after go-live, decide whether the cause is training, configuration, workflow design, missing functionality, integration, data, permissions, or process change. The answer is not automatically "training failed."

Track workaround debt

A temporary process becomes dangerous when everyone forgets it was supposed to be temporary. Keep a simple register:

If a workaround survives the stabilization period, formally accept it as a process change or treat it as unfinished implementation work.

Train around work

Train how this employee performs the actual job—not only how to open the Cases menu. Role-specific training should follow real workflows: the citation that has to be entered, the discovery that has to be produced, the booking that has to result in a release, the report that has to be submitted.

Treat go-live as the beginning of stabilization

Go-live should trigger a defined hypercare period, not "good luck." Users will find the gaps that sample testing missed. The question is whether the project still has ownership, severity, and a way to tell a defect from a training gap, a conversion exception, or an accepted limitation.

Define hypercare

At minimum, hypercare should include:

• Daily issue triage at the start
• Severity
• Ownership
• Known workarounds
• Affected users
• Expected resolution
• Escalation
• Customer and vendor communication

During early hypercare, someone should be able to say what is broken, who owns it, and whether operations can continue.

Measure stabilization

Thresholds belong to the agency and the contract. The categories usually do not:

• Critical defects
• High-priority defects
• Unresolved conversion exceptions
• Manual workarounds
• Support volume
• Reporting failures
• User-blocking issues
• Integration failures

Keep leadership visibility

During stabilization, stakeholders should know what is broken, what is inconvenient, what is still incomplete, what is being fixed, and what has been accepted or deferred.

Don't confuse support with unfinished implementation

Later training, modules, amendments, and support do not by themselves show that the original implementation failed. The stronger evidence is whether original conversion, required workflows, access, validation, or go-live defects remain unresolved.

Define final acceptance

Implementation acceptance should answer:

• Have the agreed deliverables been completed?
• Have exceptions been documented?
• Has the agency accepted any deferred items?
• Are blocking defects resolved?
• Is operational ownership transferred?
• Is ongoing work now ordinary support or product-lifecycle work?

If nobody can say when implementation ended, the project may never have had a real definition of done.

Make implementation readiness visible

A successful implementation should progress through explicit gates rather than moving forward because the calendar says it is time. A practical lifecycle looks like this:

DISCOVERY
    ->  PLAN
    ->  CONVERT
    ->  CONFIGURE
    ->  INTEGRATE
    ->  TRAIN
    ->  VALIDATE
    ->  GO LIVE
    ->  HYPERCARE
    ->  ACCEPT

Each gate needs evidence, an owner, and a decision. The checklist below turns those gates into a printable working document. It is vendor-neutral. It does not score a product.

Public Safety Software Implementation Readiness Checklist

Use this during a software project to keep discovery, conversion, configuration, validation, training, go-live, hypercare, and acceptance visible. An unchecked box is a prompt to look closer. Completing every box is not a determination that the implementation succeeded, an unchecked box is not a finding that a vendor failed, and the checklist does not replace a contract, statement of work, or acceptance document.

Discovery

• Operational stakeholders identified.
• Current workflows documented.
• Required integrations identified.
• Required reports identified.
• Required public and internal access identified.
• Hardware and device requirements identified.
• Product gaps identified.
• Owners assigned to open questions.
• Success criteria documented.

Data conversion

• Source systems identified.
• Export and access confirmed.
• Conversion scope agreed.
• Historical identifiers preserved as required.
• Confidential, sealed, and restricted data identified.
• Attachments included where required.
• Relationships validated.
• Financial balances validated where applicable.
• Converted data sampled by operational users.
• Exceptions documented.
• Final and delta conversion plan approved.

Configuration and integration

• Agency configuration complete.
• Roles and permissions configured.
• Interfaces connected.
• Devices tested.
• External integrations tested.
• Reports configured.
• Public-facing access configured.
• Environment and settings documented.

Operational validation

• Real end-to-end scenarios completed.
• Patrol workflow tested.
• Dispatch workflow tested where applicable.
• Records workflow tested.
• Jail workflow tested where applicable.
• Court workflow tested where applicable.
• External and downstream users tested where applicable.
• Negative permissions tested.
• Confidential-record handling tested.
• Reporting tested.
• Exceptions documented.

Training

• User roles identified.
• Role-specific training completed.
• Supervisors trained.
• Administrators trained.
• Workarounds documented.
• Training gaps identified.
• Attendance and completion recorded.
• Users know where to obtain support.

Go-live readiness

• Blocking issues resolved.
• Conversion accepted.
• Integrations operational.
• Required users trained.
• Support contacts known.
• Cutover plan approved.
• Rollback or contingency plan documented.
• Customer and vendor authorize go-live.

Hypercare

• Issue register active.
• Critical issues reviewed daily.
• Workarounds tracked.
• Owners assigned.
• Users know the escalation process.
• Reporting and integrations monitored.
• Conversion exceptions monitored.
• Progress communicated to stakeholders.

Final acceptance

• Original implementation scope reviewed.
• Required workflows operating.
• Required access restored or working.
• Remaining defects documented.
• Deferred items explicitly accepted.
• Temporary workarounds resolved or accepted.
• Operational ownership transferred.
• Final implementation decision recorded.
• Project formally transitioned to normal support.

Implementation Acceptance Scorecard

Use this as a decision record, not a product rating. Status values are Not ready, Ready for validation, Accepted, or Deferred.

Go-live is a date. Done is an outcome.

Go-live is a date. Done is an outcome.

Related Thin Line resources

This guide asks how an agency knows an implementation is actually finished. The resources below answer deeper questions about particular parts of that work. They are not repeated here.

Public Safety Data Conversion Guide

Texas Police RMS Evaluation Guide

Texas Municipal & Justice Court Software Guide

Texas NIBRS Reporting Guide

Texas CJIS Audit Readiness Checklist