When Is a Public-Safety Software Implementation Actually Finished?

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

On September 17, 2018, Lubbock County Commissioners Court approved a professional-services agreement with Tyler Technologies for an integrated justice and information-management system. Odyssey went live on August 1, 2021. In the weeks that followed, local reporting documented confidential records becoming publicly visible, discovery and attorney-access difficulties, delayed justice-system processes, and temporary workarounds. County budget materials later listed completion of the Tyler/Odyssey transition as an ongoing goal. Commissioners Court continued receiving software-conversion status reports in 2022. Public online court-record access remained restricted for years after go-live.

Those events are specific to Lubbock County. They are not a verdict on Tyler Technologies, and they are not a finding that Lubbock County failed. County employees repeatedly developed workarounds, continued remediation, and worked across departments to keep the operation moving. The county also continued to buy additional Tyler products and services after go-live.

The useful question is broader:

Go-live is not the same thing as done.

A public-safety software implementation should not be considered complete merely because users can log into the new system. Completion should mean operational workflows work, converted data is trustworthy, confidential and public access behave correctly, integrations work, users are trained, reporting works, known issues have owners, workarounds are not becoming permanent, downstream users can perform their jobs, and acceptance criteria have been met.

What evidence will tell us this implementation is actually complete?

Why this case matters

The county is also not one monolithic user. Different departments experienced the transition differently. The District Clerk's FY2022 budget listed "Complete transition/conversion to Tyler/Odyssey" as a 2022 goal and anticipated working through transition issues. Justice of the Peace Precinct 4 later wrote that it had "made it through" the conversion and could function with the system, while noting more manual keying for citations. The District Clerk's FY2024 material still described 2023 work as continuing toward completion of the Tyler/Odyssey transition/conversion, including Jury Manager issues. Implementation success can vary by workflow and department inside one organization.

Go-live does not define implementation success:

DEFINE SUCCESS
    ->  UNDERSTAND THE OPERATION
    ->  VALIDATE THE DATA
    ->  VALIDATE THE WORKFLOWS
    ->  VALIDATE ACCESS / SECURITY
    ->  TRAIN THE PEOPLE
    ->  CUT OVER
    ->  STABILIZE
    ->  ACCEPT THE IMPLEMENTATION

The recurring question at every phase is the same: what evidence tells us this phase is complete?

Define "done" before the project begins

Vague completion language creates risk. If the only agreed definition of done is "the system is live," the project can technically succeed while the operation is still carrying unresolved conversion, access, workflow, training, or reporting work.

A better definition is operational. Agreed workflows function. Required records are converted. Balances and counts reconcile, or the differences are explained. Permissions are validated. Integrations are tested. Reports are validated. Users are trained. Known exceptions are accepted and 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.

That distinction does not require a particular contractual methodology. It is implementation guidance. A calendar date can start production use. It cannot, by itself, prove that the work the agency bought is finished.

Lubbock County's own FY2022 District Clerk material listed "Complete transition/conversion to Tyler/Odyssey" as a 2022 goal after the August 2021 go-live and said the office would work through anticipated issues that occurred during transition. That is not a finding that every department was unfinished. It is evidence that the county itself treated completion as work that continued after users were in the new system.

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?

If those answers are missing, the project will tend to move forward because the calendar says it is time. That is how an agency can reach go-live with unresolved conversion exceptions, untested public access, or workflows that still depend on paper.

Treat data conversion as preservation, not import

A technically successful import can still produce an operationally incorrect result. Data migration has to preserve more than record content. Confidentiality, suppression, expungement or non-disclosure status, historical relationships, documents, permissions, and metadata can matter as much as basic field values.

In September 2021, the Lubbock County Defense Lawyers Association warned that records that should have been expunged, sealed, or otherwise inaccessible had become publicly available after the Odyssey transition. The county confirmed that some records which should not have been public were visible, temporarily shut down the public portal, and declined to classify the incident as a cybersecurity "data breach."

In 2025, IT Director Isaac Badu told Lubbock Lights that the 2021 conversion exposed inconsistent handling of confidential information in older records. Confidential information has to be marked in the system. Older records did not always carry that marking, or different departments had not marked it the same way. Badu said IT or a programmer cannot later determine what is confidential if the clerk did not mark it. Judge Curtis Parrish separately said he believed some issues, especially the public portal, were "not fundamental to Tyler." Tyler Technologies, answering later questions, said its case-management software had "functioned as designed and according to the processes, procedures, and workflows determined by Lubbock County during the implementation."

Those statements can all be true at the same time. Legacy confidentiality flags can be missing or inconsistent. A new portal cannot infer a restriction the source data does not contain. A product can function as configured and still expose the wrong records if conversion did not preserve meaning. The lesson is not that one party caused every visibility error. The lesson is that conversion validation has to test meaning, permissions, and edge cases—not only whether the records loaded.

Validate more than counts

Record counts answer one question: did records move? They do not automatically answer whether the records still mean the same thing.

• 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 the records most likely to break the assumptions.

Where source records are ambiguous, identify the exceptions, establish manual review, document remediation, and delay public exposure when appropriate. Do not assume the new system can reconstruct a confidentiality rule the old system never stored consistently.

Test real workflows—not just screens

A feature can technically exist while the operational workflow still fails. 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.

After the August 2021 go-live, defense attorneys told KTTZ, KCBD, and other local outlets that it had become harder to obtain discovery and case information, that attorney-assignment and referral processes required temporary paper workarounds, and that some defendants remained in jail longer than necessary because communications between attorneys, court administration, and the jail were delayed. KCBD reported that county officials admitted the software transition delayed communications and that several low-level offenders were held longer than legally necessary. Court administrators said the attorney-referral option was unavailable at go-live and that they temporarily assigned attorneys on paper.

Public sources do not establish that Tyler software independently caused every detention or every delayed assignment. District Attorney Sunshine Stanek said her office had heard speculation about wrongful-jail cases but could not speak to where the issue occurred. County Judge Parrish described some early problems as isolated. Tyler said the software was functioning as designed according to county-determined workflows and that learning a new system can take time. Court Administration later said an internal criminal-justice stakeholder group was meeting weekly to troubleshoot process issues.

Cross-department workflows—attorney assignment, discovery, jail release, case visibility—have to be tested with the people who actually perform them. If those workflows are only validated inside IT or inside one office, the first production week becomes the real test.

Use end-to-end scenarios

Have the agency test realistic work, adapted to its own operation:

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

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

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

The exact path changes by agency. The method does not. Follow a real piece of work from the first entry to the last downstream user.

Include every stakeholder

Implementation validation should involve the people who actually perform the work:

• Patrol
• Dispatch
• Jail
• Prosecutors
• Clerks
• Judges
• Records
• IT
• Administrators
• Downstream partner agencies
• Public-facing users where relevant

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

Treat permissions and public access as go-live features

Public access and authorized internal access are distinct workflows. Both deserve explicit validation before cutover. They are not optional portals to finish later if the agency has promised the public, attorneys, or partner agencies a way to see records.

Lubbock County shut down public portal access in September 2021 after confidential records became visible. In March 2022, Badu told Commissioners Court the portal was still not live to the public and that he was waiting for county leadership to instruct him to restore it. Judge Parrish said he wanted the District Attorney's office to confirm that expunged cases had been removed before reopening the portal. In June 2025, County Clerk Kelly Pinion told Commissioners Court that public access had been "nonexistent" since the 2021 go-live: staff could search, but the public could not look records up for themselves online or on a courthouse terminal. Officials then tested restoration specifically to make sure confidential information would not be exposed again.

As of September 2026, the county's official public-access page advertises a registered-user portal for certain case-index information—general case details, parties, attorneys, and scheduling—without document images. It also lists courthouse terminals that can search records and view documents, including some documents restricted from online viewing. That is restoration. It is still not the same thing as full online document access. 2025 reporting describes the years when even that limited access was unavailable.

Test what each user can see

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. Do not assume a permission that works on a new case will behave the same way on a converted one.

Test denial, not only access

Most testing asks whether the user can get to the record. Also ask whether a user who should not see it can get to the record. That is the relevant implementation lesson from the confidential-record exposure. A search that returns the wrong historical case is a go-live defect, even if the correct users can also find the correct cases.

Test legacy confidentiality

Migration can expose weak or inconsistent historical classification. 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
• Delay public exposure when appropriate

This is operational guidance, not a statement of a specific Texas public-information rule. 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, the implementation team needs a process for deciding whether the cause is training, configuration, workflow design, missing functionality, integration, data, permissions, or process change. The lesson is not automatically "training failed."

After go-live, Lubbock County staff used paper attorney assignments, circulated a PDF jail roster twice daily while the online roster stayed tied to the closed portal, and formed recurring stakeholder meetings to troubleshoot process issues. In May 2023, Commissioners Court approved additional Tyler Enterprise Training Credits and onsite and remote implementation. Justice of the Peace Precinct 4 later said it could function in Odyssey while still requesting overtime because citation entry required more keystrokes. Those facts show continued operational adaptation. They do not, by themselves, prove that the original training plan was inadequate or that later training purchases were remediation rather than ordinary expansion.

Track workaround debt

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

Review the register during hypercare. If a workaround is still in use after the agreed stabilization window, it is no longer an emergency bridge. It is either accepted process change or unfinished implementation work.

Train around work

Avoid training that only shows the Cases menu. Prefer training that shows how this employee performs the actual job. 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. It should not trigger "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 the difference between a defect, a training gap, a conversion exception, and an accepted limitation.

Lubbock County continued reporting software-conversion status to Commissioners Court months after go-live. In March 2022, Badu reported that a December update had shown 1,871 active transition work orders and that about 8 percent remained outstanding. The public portal was still offline. That visibility is useful. It is also evidence that go-live did not end the implementation conversation.

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

The exact duration is project-specific. The requirement is that someone can answer, every day at first, what is broken, who owns it, and whether the operation can still perform the work.

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. A status report that only says "the system is live" hides the difference between ordinary support and unfinished implementation.

Don't confuse years of support with an unfinished implementation

Ordinary product-lifecycle work and unfinished implementation work can look similar from a distance. Both produce later invoices, later training, and later amendments. They are not the same thing.

Lubbock County continued expanding its Tyler relationship after the troubled rollout. Commissioners approved additional Tyler work in 2020 and 2021, including document conversion, a risk-management module, Tyler Jury, and Tyler Supervision. In May 2023 they approved more training, implementation services, and LERMS property and document conversion. In August 2023 they amended the jury contract again. Those later purchases are not, by themselves, proof that the implementation failed, and they are not evidence that the county rejected Tyler. A customer buying additional modules is normal.

District Clerk budget material still described transition and conversion work as incomplete in 2022 and again when reporting 2023 accomplishments. Public online access remained unrestored for years after the 2021 shutdown. Some departments, including at least one Justice of the Peace office, later described their Odyssey conversion as completed and functioning.

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, and an unchecked box is not a finding that a vendor failed.

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.

Lubbock County's experience is useful not because every implementation will look like Lubbock County's. It is useful because it demonstrates how much can remain unresolved after a system technically goes live. Some departments later described their conversion as completed and functioning. Other county records continued to describe transition work, and public access remained limited for years. Those facts can sit together.

A successful implementation is not defined by the first production login. It is defined by whether the organization can reliably perform its work, trust its historical data, control access, complete reporting, and move forward without depending on unresolved implementation work.

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