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.

A public-safety agency may use the same records system for ten, fifteen, or even twenty years. Over that time, the system can accumulate thousands of incidents, people, vehicles, calls for service, citations, bookings, warrants, court cases, payments, documents, attachments, and other pieces of operational history.

That history still matters after the new system goes live.

A successful data conversion is not simply about getting information out of the old database.

It is about turning that information into usable records in the new system, preserving the relationships that make those records meaningful, cleaning up problems where it is safe to do so, and giving the agency a way to verify the result.

The goal of a conversion is not to move a database. It is to preserve the agency's operational history.

This guide explains what agencies should ask before changing systems, what to request from an outgoing vendor, how conversion can fit around go-live, and how to validate the records once they arrive.

Start talking about conversion before you choose the new system

Data conversion should not be an implementation detail discussed after the contract is signed.

Make it part of the software evaluation.

Ask prospective vendors:

• What historical data can you convert?
• What source formats can you work with?
• Who actually performs the conversion?
• Is conversion included in the proposal?
• How are source fields mapped into the new system?
• What happens when the two systems represent the same concept differently?
• Are documents and attachments converted?
• How are people, addresses, vehicles, organizations, and other master records handled?
• How are relationships between records preserved?
• How do you handle duplicates?
• What happens when a legacy value cannot be mapped cleanly?
• How will our agency validate the conversion?
• Can conversion occur before go-live?
• Can historical data be backfilled after go-live?
• What will we need from our outgoing vendor?

Don't settle for:

“Yes, we convert data.”

Ask the vendor to explain the process.

Know what you can actually get from the old system

Before building a conversion plan, determine what the agency can obtain from the outgoing system.

For a locally hosted system, that may mean direct access to:

• SQL Server databases or backups
• DBF or other legacy database files
• application data directories
• documents and attachment folders
• exported CSV files
• XML or other structured exports
• images
• configuration files
• lookup/code tables

Cloud-hosted systems are often different.

The agency may not have access to the underlying database at all. Instead, the outgoing vendor may need to prepare and deliver a data export.

Ask for that early.

Do not wait until the week before the old contract ends to discover that the export:

• requires a formal request
• has an additional fee
• takes several weeks to prepare
• excludes attachments
• uses a proprietary format
• or requires a separate professional-services engagement

Ask the outgoing vendor for

• A complete data export
• The format of the export
• Database/schema documentation, if available
• A data dictionary, if available
• Lookup and code tables
• Documents and attachments
• Information showing how attachments relate to parent records
• Employee/user identifiers where relevant
• A description of anything that will not be included

Once you receive the source data, keep an untouched copy.

That source snapshot may become extremely important later.

Inventory the records that need to survive

“Convert the RMS” is too broad.

Create an actual inventory.

RMS / law-enforcement records

Depending on the system, that may include:

• master people
• organizations
• addresses/locations
• vehicles
• incidents
• offenses
• arrests
• supplements
• investigations
• warrants
• citations
• field interviews
• property
• evidence
• crash-related records
• officer/personnel records
• documents
• attachments
• notes
• historical statuses and dispositions

CAD records

Possible records include:

• calls for service
• call numbers
• call types
• caller information
• locations
• assigned units
• unit statuses
• call notes
• dispositions
• timestamps
• related incidents
• historical unit activity

Jail records

A jail conversion may include:

• master people
• bookings
• arrest/charge information
• booking numbers
• custody dates
• housing history
• classification
• restrictions/alerts
• movements
• releases
• bonds
• inmate property
• booking photographs
• custody notes
• historical booking records

Court records

A court conversion may include:

• defendants
• citations
• cases
• violations
• pleas
• judgments
• dispositions
• balances
• fines
• court costs
• payments
• adjustments
• refunds
• warrants
• bonds
• collections
• docket history
• compliance activity
• notes
• documents
• case-status history

The exact list will depend on the old system and the agency's needs.

The important part is agreeing on the scope before conversion begins.

A conversion is not just a database import

An old system and a new system almost never represent information in exactly the same way.

Suppose an old RMS contains:

INCIDENT
PERSON
INCIDENT_PERSON
OFFENSE
VEHICLE
PROPERTY
ATTACHMENT

The new RMS may represent those same concepts differently.

That means conversion requires mapping.

At its simplest:

Source table
    ↓
Source field
    ↓
Interpret / transform
    ↓
Destination record
    ↓
Destination field

For example:

Some fields map directly.

Others need transformation.

Some require a lookup table.

Some cannot safely be translated and may need to remain as legacy information.

That's why data conversion is an engineering and records problem—not simply an import task.

Preserve the agency's historical identifiers

When practical, converted records should preserve the identifiers agency staff already know.

That may include:

• incident number
• call number
• citation number
• case number
• booking number
• warrant number
• property/evidence number
• historical internal identifier

The new system may also generate its own database identifiers.

That is fine.

But a records clerk searching for:

Incident 2019-004217

should still be able to find Incident 2019-004217.

Historical record numbers are part of the agency's institutional memory.

Master records need special attention

One of the most valuable parts of a conversion can happen after the source records are technically imported.

Legacy systems often accumulate duplicate master records.

The same person might exist as:

SMITH, ROBERT J
ROBERT JAMES SMITH
SMITH, ROBERT
BOB SMITH

One record might contain the correct driver's-license number.

Another may have a current address.

Another may have a DOB.

Another may contain historical incident relationships.

Simply importing all four records reproduces the old database's problem.

Thin Line's conversion process can include post-conversion cleanup to identify and merge duplicate master records when the available information supports a reliable match.

That may apply to:

• people
• organizations
• addresses
• vehicles
• other shared master data

Deduplication should be conservative

Two records with the same name are not automatically the same person.

Matching may consider combinations such as:

• name
• date of birth
• driver's-license number
• state ID
• address
• phone
• other available identifiers

If there is not enough information to confidently determine that two records represent the same entity, keeping them separate is safer than incorrectly merging them.

Good conversion removes obvious duplication without inventing certainty that the source data does not support.

Clean the data without rewriting history

A conversion creates opportunities to improve old data.

Examples can include:

• merging confirmed duplicate master records
• normalizing malformed dates
• standardizing address or phone formats
• reconnecting reliable historical relationships
• translating obsolete lookup values
• correcting structural inconsistencies
• consolidating duplicated agency or personnel references

But cleanup has a boundary.

Historical facts should not silently change just because the new system would prefer a different value.

If an old incident recorded:

• a particular address
• a particular officer
• a particular status
• a particular offense description
• a historical disposition

then that historical meaning matters.

The objective is:

Improve the structure and usability of the converted records without manufacturing a cleaner history than actually existed.

Conversion can happen before go-live

When the legacy system is hosted on premises, Thin Line can often receive a usable source database or export before cutover.

A typical process may look like:

Legacy system
      ↓
Source snapshot
      ↓
Initial conversion
      ↓
Mapping / cleanup
      ↓
Agency validation
      ↓
Final conversion / cutover
      ↓
Go-live

The advantage is straightforward:

Users begin working in the new system with historical information already available.

But the conversion plan also needs to address records entered into the legacy system between the first source snapshot and final cutover.

That may require:

• a new final snapshot
• a delta conversion
• a short freeze window
• or another agreed cutover process

The exact approach depends on the source system.

Cloud data can be backfilled after go-live

A cloud-hosted legacy system can create a different problem.

The agency may be ready to begin using the new system while still waiting for the outgoing vendor to deliver historical data.

In those situations, historical conversion does not necessarily need to delay the entire project.

A sequence can look like:

Thin Line goes live
      ↓
New production records begin
      ↓
Outgoing vendor provides export
      ↓
Historical conversion
      ↓
Historical records backfilled

This can allow the agency to move forward without making the old vendor's export timeline the critical path to go-live.

The backfill process still requires care.

Historical records need to coexist correctly with records already being created in production, and identifiers or master records need to be handled in a way that prevents unintended duplication.

A delayed cloud export does not always have to mean a delayed go-live.

Ask prospective vendors how they would handle that scenario.

Relationships matter as much as records

Suppose the old RMS contains:

• 40,000 incidents
• 75,000 people
• 12,000 vehicles
• 5,000 arrests

Moving each row into the new system is not enough.

An incident may relate to:

Incident
  ├── People
  ├── Vehicles
  ├── Offenses
  ├── Officers
  ├── Arrests
  ├── Property
  ├── Supplements
  └── Attachments

A call may relate to an incident.

A booking may relate to a person, arrest, charges, bonds, and release.

A court case may relate to a defendant, citation, violations, warrants, payments, judgments, and documents.

If those relationships disappear, the agency may technically possess all of the original records while still losing much of the history's usefulness.

Record counts do not prove relationship integrity.

Attachments need their own plan

Documents are easy to overlook during database conversion.

Ask specifically about:

• PDFs
• scanned reports
• photographs
• document images
• supplemental documents
• uploaded files
• historical attachments

Determine:

Where does the old system store them?

Does the database store the file itself or only the path?

Is the file path absolute or relative?

How does the old system know which record owns the attachment?

Will the vendor's export preserve that relationship?

An export containing 50,000 files is not particularly useful if nobody can determine which case each file belongs to.

Validate attachments separately

Don't just count them.

Open sample attachments from:

• recent cases
• old cases
• complex cases
• multiple document types

Make sure they are attached to the right destination records.

Lookup and code tables may be critical

Legacy databases often contain codes that only make sense because the application knows how to interpret them.

For example:

A
ACT
C
CLS
9
99
UNK

Those values might represent:

• disposition
• status
• offense
• property category
• relationship
• agency
• bond type
• location type
• employee
• other internal concepts

Without the corresponding lookup table or application logic, the raw value may be meaningless.

This is why supporting data such as:

• code tables
• lookup tables
• configuration files
• database documentation

can be just as important as the primary records.

Keep them.

Offenses deserve special care

For Texas law-enforcement and court conversions, offense data can be particularly important.

Legacy systems may contain:

• obsolete statutes
• historical statute versions
• local offense descriptions
• DPS/UCR codes
• free-text offenses
• manually entered variations
• outdated code tables

The new system may have a more current offense catalog.

That does not mean every historical offense should simply be replaced with the current version.

The conversion needs to distinguish between:

historical record preservation

and

current catalog cleanup.

A 2016 incident should still reflect what was recorded in 2016.

A current offense catalog can be cleaned up independently for new records.

Changing systems can also trigger NIBRS re-certification

Data 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. Historical records need to survive; new production records need to report correctly. 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.

Employee and agency identities also need mapping

Historical records often refer to users through internal IDs.

For example:

OFFICER_ID = 27

But who was Officer 27?

The source system may contain:

27 → SMITH, JOHN

The new system needs to map that historical employee appropriately.

That employee may:

• still work for the agency
• have changed rank
• have changed badge number
• be retired
• no longer have a user account

Historical authorship should not disappear simply because the employee no longer uses the new system.

The same principle applies to:

• agencies
• departments
• courts
• judges
• dispatch personnel
• jail staff

Validate the conversion quantitatively

Do not validate a conversion by opening three records and saying:

“Looks good.”

Start with counts.

For example:

A difference is not automatically wrong.

For example, if 1,400 confirmed duplicate people are merged into 950 master people, the resulting person count should not match the source.

But the difference should have an explanation.

Validate the conversion operationally

Counts tell you whether records exist.

They do not tell you whether those records make sense.

Select known records from:

• recent years
• older years
• normal cases
• complicated cases
• incidents with many people
• incidents with arrests
• cases with attachments
• calls connected to incidents
• jail bookings with several charges
• court cases with payments or warrants
• records staff already know are unusual

Then compare old and new.

Ask:

Are the people correct?

Are the relationships intact?

Is the officer correct?

Did the attachments arrive?

Is the balance correct?

Can I understand what happened?

Use the people who know the records

The developer performing the conversion understands the database.

The records clerk understands the records.

The dispatcher remembers how calls were organized.

The jail administrator knows what a booking history should contain.

The court clerk knows immediately when a balance or warrant status makes no sense.

Use those people.

A good validation process combines:

technical validation

with

operational validation.

Neither replaces the other.

Expect exceptions

Years-old operational databases contain strange data.

That's normal.

You may encounter:

• missing references
• invalid dates
• orphaned attachments
• obsolete codes
• duplicate master records
• inconsistent statuses
• malformed values
• records created by application bugs
• custom fields unique to one agency
• data that no longer matches the vendor's current schema

Ask:

What does the conversion team do when something doesn't fit?

The answer should involve some combination of:

1. identify
2. investigate
3. determine meaning
4. improve mapping
5. rerun affected conversion logic
6. document unresolved exceptions

A serious conversion is iterative.

Not magical.

Don't immediately give up the old data

Before terminating access to the old system, verify that the agency has received whatever data it is entitled to receive and that the new conversion has been appropriately validated.

At minimum, consider confirming:

• Final export received
• Export can be opened/read
• Documents and attachments received
• Lookup tables received where available
• Major record counts reviewed
• Historical identifiers preserved
• Complicated samples validated
• Relationships tested
• Known exceptions documented
• Operational users reviewed the data
• Source snapshot preserved appropriately

Whether the old application itself should remain available, and for how long, depends on the agency's contractual, records-retention, security, and operational requirements.

But don't make the old system disappear before confirming that the historical record safely made the trip.

Experience matters when you're moving years of records

Thin Line has performed data conversions involving RMS, CAD, Jail, and Court information from a range of legacy public-safety and local-government systems.

Previous conversion sources have included:

• Xpediter Technology / Xpediter Patrol C/S
• CrimeStar
• COPsync
• Cardinal Tracking Badge
• Tyler Technologies systems
• FUNDVIEW
• ASYST by USTI / CentralSquare Govasyst

Xpediter Technology publicly identified Xpediter Patrol C/S as its law-enforcement field-reporting product. CrimeStar remains publicly documented as an RMS product, Cardinal Tracking markets Badge as its records-management offering, Texas DPS identifies Kologik/COPsync and Tyler systems among NIBRS vendors/products, and FUNDVIEW currently offers municipal-court software as part of its local-government platform.

We've worked with both:

locally hosted source databases

and

exports delivered from cloud-hosted systems.

Depending on the source and implementation, Thin Line can convert historical records before go-live or backfill historical records after go-live once the agency's source data becomes available.

Conversion can also include cleanup after the initial import—for example, identifying and merging duplicate master records where the available information reliably shows that they represent the same person or entity.

Prior experience does not make every conversion identical

This is important.

If a vendor tells you:

We've converted CrimeStar before.

that is useful information.

It is not a guarantee that your CrimeStar conversion will be identical.

Different agencies may have:

• different software versions
• different database editions
• different configurations
• custom fields
• custom code values
• different amounts of history
• different attachment structures
• different data quality

CrimeStar itself, for example, publicly documents different product/database editions, which illustrates why two installations from the same vendor may still require different conversion work.

So ask about experience—but also ask about the vendor's process.

The process is what handles the unexpected.

10 questions to ask any vendor about conversion

Bring these to your next software demonstration.

1. Who actually performs the conversion?

Is the work done by the software company, a subcontractor, or the agency?

2. What source formats can you work with?

Database backup? DBF files? CSV? Vendor export? Attachments?

3. Which records will be converted?

Ask for a written list.

4. What will not be converted?

This is often more useful than asking what will.

5. How do you handle attachments?

Make them show how documents remain tied to the right records.

6. How do you handle duplicate master records?

Are duplicates simply imported, or is cleanup possible?

7. How do you preserve relationships?

A converted incident needs more than a case number and narrative.

8. How do we validate the result?

Ask about counts, samples, exceptions, and agency acceptance.

9. Can we go live before a cloud vendor delivers our historical export?

If that matters to your project, ask early.

10. What systems have you actually converted before?

Then ask what they learned from those conversions.

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
• Identify who performs the work
• Ask how attachments are handled
• Ask how master records are handled
• Ask how relationships are preserved
• Ask how validation works
• Ask whether historical data can be backfilled later

Before requesting the old data

• Determine who owns/controls the source data
• Ask the outgoing vendor about export lead time
• Ask about export fees
• Request database documentation
• Request lookup/code tables
• Request attachments
• Ask what is excluded

Once the export arrives

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

During conversion

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

After conversion

• Compare counts
• Explain expected differences
• Review recent records
• Review old records
• Review complicated records
• Test attachments
• Test search
• Test relationships
• Review financial balances where applicable
• Review warrants/statuses where applicable
• Have operational users validate
• Document known exceptions
• Preserve the source export appropriately

A simple conversion-validation worksheet

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

Sample records checked

Known conversion exceptions

This turns the article into something an agency can actually use during implementation.

Your records should outlive your software

Software changes.

The agency's history should not disappear with it.

A good conversion:

• preserves meaningful historical identifiers
• keeps relationships between records intact
• maintains access to documents and attachments
• identifies problems instead of hiding them
• improves duplicate master data where it can be done reliably
• allows the agency to validate what arrived
• and leaves a documented explanation for anything that could not be translated cleanly

The question is not simply:

Can the new vendor import our data?

A better question is:

Do they have a process for understanding it?