Moving public-safety data without leaving the records behind.

A practical data-conversion guide for agencies replacing an RMS, CAD, jail, court, or other public-safety system.

Changing software should not mean starting over. Years of incidents, cases, bookings, payments, and documents still matter after the new system goes live.

Data conversion is not copying rows from one database to another. It is preserving the meaning of the agency's historical record in a new system.

Migration moves information from one environment to another. Conversion transforms that information so it works correctly in the new system. Validation demonstrates that the result still preserves the information and relationships the agency intended to keep.

A conversion can technically succeed and still be operationally poor: reports without attachments, people disconnected from incidents, new case numbers that bury the old ones, balances without payment history, evidence without chain-of-custody history, or restricted records that become broadly visible.

Inventory before anyone promises “everything”

The first conversion decision is not technical. Identify what actually exists in the legacy system, then decide which parts are included.

What will not be converted?

Inventory at the dataset level—incidents, people, vehicles, cases, bookings, attachments, financials, evidence—not as a product-feature list. CAD history is its own dataset when the agency still depends on it.

The visible application is not necessarily the complete data source. Legacy data may live in relational or proprietary databases, DBF or FoxPro-style files, CSV or text exports, document folders, image repositories, separate modules, or archive databases.

A locally hosted system may yield a database, backup, or file snapshot. A cloud-hosted system often requires the outgoing vendor to prepare an export—sometimes with a fee, a wait, missing attachments, or a proprietary format. Ask before the old contract ends.

Once the source data arrives, keep an untouched copy. That snapshot may become important later.

Map meaning, not just columns

Legacy field → new field is only the simplest case. Real mapping has to interpret code values, relationships, identifiers, status meanings, dates, defaults, obsolete values, one-to-many or many-to-one transforms, and local or custom fields.

A legacy case status of C is meaningless until someone knows whether C meant Closed, Complete, Cleared, Cancelled, or something else in that particular system.

Schema tells you how data is stored. It does not necessarily tell you what the data means.

Keep lookup tables, configuration files, and any available database documentation. Raw values such as A, ACT, 99, or UNK are often unusable without them.

Historical records also refer to people through internal IDs. If OFFICER_ID = 27, the conversion has to know who Officer 27 was. That employee may still work for the agency, have changed badge numbers, be retired, or no longer have a user account. Historical authorship should not disappear because the person no longer logs into the new system. The same mapping applies to agencies, courts, judges, dispatchers, and jail staff.

Preserve what makes a record usable

Public-safety records are relational. Importing 20,000 people, 15,000 incidents, and 5,000 vehicles is not success if the correct people, vehicles, property, offenses, documents, payments, and evidence are no longer attached to the correct incidents or cases.

Keep the identifiers staff already use

Legacy case, incident, citation, warrant, booking, receipt, and evidence numbers often remain operationally important after go-live. If the new system creates its own identifiers, the old ones should remain searchable. A clerk looking for Incident 2019-004217 should still be able to find it.

Treat documents as records

Do not convert only structured rows. Identify reports, scans, photographs, signed orders, warrants, receipts, evidence images, attachments, and generated historical documents.

Treat restriction as conversion data

A record that was restricted in the old system must not become broadly visible merely because it was converted. Ask how the conversion handles restricted, confidential, sealed, juvenile, and internal investigative records, including role-based and document-level restrictions where they exist.

Visibility and restriction can be part of the meaning that must survive conversion.

Court financials need the history, not only the balance

For court conversions, distinguish original assessments, fines, costs, payments, allocations, adjustments, refunds, outstanding balances, dispositions, and historical receipts where the source supports them. The converted ending balance should be explainable from that activity.

A correct balance with an incorrect history is not necessarily a correct conversion.

Evidence conversion should preserve accountability

An evidence or property conversion should preserve item identity, the associated case, current location, status, transfers, disposition, attachments, and chain-of-custody history where it exists. Do not reduce that history to the item’s current shelf location.

Do not silently fix the past

Historical databases often contain duplicates, incomplete records, invalid codes, inconsistent dates, orphans, test data, obsolete values, malformed identifiers, and missing relationships. Some of that comes from years of operational use, local configuration, earlier migrations, or incomplete source data—not from a defect in the previous product.

Conversion should not silently “fix” ambiguous historical data.

When the correct interpretation is uncertain, log the exception and make an explicit decision.

The same person may appear several ways in legacy data. Importing every duplicate reproduces the old problem; merging similar-looking records can create a worse one. If the available data cannot establish that two records represent the same person, keeping them separate is safer.

Texas offense data needs the same restraint. Legacy systems may contain obsolete statutes, historical versions, local descriptions, DPS/UCR codes, and free-text variations. A more current catalog does not mean a 2016 incident should be rewritten to match today’s statute. Clean the current catalog for new records independently.

Historical conversion and NIBRS transition are related projects, not the same project. Texas DPS certification procedures specifically address agencies recertifying because of a vendor or vendor-product change. Converted incidents should not become a flood of false new NIBRS records.

For Texas NIBRS workflows, certification, and what happens to historical reporting data, read the Texas NIBRS Reporting Guide.

Make exceptions visible and deliberate

A useful exception path is detect → classify → investigate → decide → correct or map → re-run → validate. Typical cases include an unknown offense code, a person reference with no matching person, a payment with no case, an attachment whose parent cannot be identified, an invalid date, or a duplicate identifier.

A serious conversion is iterative. Not magical.

Validate until the history is explainable

Do not validate a conversion by opening three records and saying it looks good. Establish the forms of validation once, then use them:

• Count — did the expected records move?
• Field — did important values move correctly?
• Relationship — are associated records still connected?
• Financial — do balances and transaction histories reconcile?
• Document — are expected files present, associated, and readable?
• Permission — can the right people see the record, and the wrong people not?
• Usability — can staff find and use converted history in the new system?

Source 10,000 incidents and target 10,000 incidents does not prove success. The records could have incorrect relationships, missing documents, wrong statuses, broken identifiers, or improper permissions. Conversely, a count difference is not automatically a failure if records were excluded, deduplicated, archived, or transformed under an approved rule. Validation should explain differences rather than demand identical totals.

Combine automated counts, exception reports, high-risk samples, random samples, and difficult cases supplied by agency staff. High-value samples include an old case, a recent case, a complex case, a case with many attachments, a restricted record, a record involving multiple people or vehicles, a court case with substantial financial history, and an evidence item with multiple transfers.

The developer understands the database. The records clerk, dispatcher, jail administrator, and court clerk understand whether a converted record still makes sense. Use both.

Define acceptance before conversion begins

Agree in advance that required datasets are included, count differences are explained, critical fields and relationships are validated, documents open, financials reconcile, restrictions still apply, remaining exceptions are resolved or formally accepted, and the agency has signed off.

For go-live methodology, training, hypercare, and implementation acceptance beyond conversion, read the Public Safety Software Implementation Readiness Guide.

Say what is available on day one

Go-live conversion is the information required for operational cutover. Historical backfill is additional history converted after go-live. Staged conversion can reduce risk when the outgoing export is slow, but the contract should identify what staff will have on day one and what arrives later.

Records entered between the first snapshot and cutover still need a final snapshot, a delta conversion, or a short freeze—the exact approach depends on the source system. Do not terminate access to the old system until the agency has the export it is entitled to and the conversion has been appropriately validated.

Plan the next conversion before you sign

The best time to plan the next conversion is before signing the current contract. Ask whether the agency can obtain a complete export, in what format, whether attachments, relationships, and identifiers are included and documented, whether a data dictionary is available, whether export assistance is included or separately priced, and what happens at contract termination.

Thin Line has performed RMS, CAD, Jail, and Court conversions from legacy systems including Xpediter Technology / Xpediter Patrol C/S, CrimeStar, COPsync, Cardinal Tracking Badge, Tyler Technologies systems, FUNDVIEW, and ASYST by USTI / CentralSquare Govasyst. Prior experience with a product does not mean the next conversion will be identical: versions, configurations, custom fields, attachment structures, history volumes, and data quality differ. Ask a prospective vendor about both its relevant experience and the process it uses when the source data behaves differently than expected.

A conversion inventory

Force an explicit decision for each dataset. Do not imply “convert everything.”

Questions to ask before you sign—and before you accept

Before contract

1. What exactly will you convert?
2. What will you not convert?
3. Who extracts the legacy data, and what source formats can you work with?
4. Are documents and attachments included, and how do they stay tied to the right records?
5. How are relationships and historical identifiers preserved?
6. How are conversion exceptions handled?
7. Who validates the converted result, and what constitutes acceptance?
8. What costs are not included?
9. Can historical data be backfilled if the outgoing export arrives after go-live?
10. What systems have you actually converted before, and what did those conversions teach you?

Before go-live

1. What remains unresolved?
2. Which datasets have been validated?
3. What exceptions remain, and who accepted them?
4. What historical information will not be available on day one?
5. Who has signed off?

A pre-conversion checklist

Before selecting the new vendor

• Define the records that need to be converted
• Ask exactly what the vendor can convert
• Identify conversion cost and who performs the work
• Ask how attachments, master records, and relationships are handled
• Ask how validation and acceptance work
• Ask whether historical data can be backfilled later
• Confirm export rights, format, attachments, and termination terms for the new contract

Before requesting the old data

• Determine who owns or controls the source data
• Ask the outgoing vendor about export lead time and fees
• Request database documentation and lookup/code tables
• Request attachments and how they relate to parent records
• Ask what is excluded

Once the export arrives

• Preserve an untouched source copy
• Verify that the files can be opened
• Inventory source tables and files
• Confirm attachments and lookup tables are present
• Document source version where possible

During conversion

• Map major record types and preserve historical identifiers
• Map employee and user identities
• Translate known lookup values
• Preserve record relationships
• Track conversion exceptions
• Review duplicate masters conservatively

Before giving up the old system

• Final export received and readable
• Documents and attachments received
• Major record counts reviewed and differences explained
• Complicated samples validated
• Relationships, search, restrictions, and financials tested where applicable
• Known exceptions documented or accepted
• Operational users reviewed the data
• Agency sign-off completed
• Source snapshot preserved appropriately

A conversion-validation checklist

• Required datasets are in scope or formally excluded
• Count differences are explained, not merely matched or ignored
• Legacy identifiers remain searchable
• Critical fields on sampled records match the source meaning
• People, vehicles, property, offenses, and documents remain attached to the correct parent
• Sample attachments open and belong to the right record
• Court balances are explainable from payment history where the source supports it
• Evidence items retain associated case, location, and custody history where available
• Restricted records remain restricted
• Staff can find a known old record and a known recent record in the new system
• Remaining exceptions are listed, decided, and owned
• Acceptance is signed against the criteria agreed before conversion began

A simple conversion-validation worksheet

Use this to keep counts, samples, and exceptions in one place.

Sample records checked

Known conversion exceptions

Your records should outlive your software

Software changes. The agency’s history should not disappear with it.

Moving the data is not enough. Preserve what it means.

Considering a move from another RMS?

If you are replacing a current system, conversion is only part of the evaluation. Compare how the new vendor handles Texas reporting, implementation, support, and the products around CAD and RMS.

Compare Thin Line with CentralSquare Public Safety Pro for small Texas agencies.