RMS Data Migration & Integration

Every legacy vendor story is a consolidation story — and most are actively sunsetting on-prem products, which is exactly what's forcing agencies to Axon right now.

ETL vs. ELT vs. CDC

ETL (transform before loading) fits RMS migration best — the target has a rigid schema and needs heavy business-rule transformation. ELT suits analytics/data-lake modernization more than a structured RMS target. Change Data Capture (CDC) streams source changes to keep old and new systems synced for near-zero-downtime cutover.

Choosing a cutover strategy

Best practice: a hybrid — big bang for low-risk data, phased/parallel for the mission-critical core. Always pilot with a low-complexity workload first.

Mapping, cleansing, and validation

• Field-level crosswalks: agency/state offense codes ↔ NIBRS Group A/B codes; charge codes ↔ state DOJ/CJIS codes.
• Dedup: profile data quality first, then run entity resolution (name + DOB + address + phone) to collapse duplicates into golden records — records staff should adjudicate ambiguous merges.
• Unstructured data: carry free text and scans across as attachments with preserved metadata even when they can't be parsed into fields.
• Reconciliation: row counts and control totals at every checkpoint, plus cryptographic hash comparison (SHA-256) to prove files transferred intact.

Rollback planning

Define go/no-go criteria and rollback triggers before cutover. Keep the legacy system as the system of record until reconciliation passes fully.

Every RMS migration starts here: a database nobody currently at the agency fully understands. This is a repeatable, provable workflow rather than guesswork — treat it as an investigation, not a reading exercise.

The workflow, in order

1. Pull the metadata first. Every RDBMS exposes its own schema via system catalogs before you touch a single row of data: INFORMATION_SCHEMA, sys.tables, sys.columns, sys.foreign_keys on SQL Server; ALL_TABLES, ALL_TAB_COLUMNS, ALL_CONSTRAINTS, DBA_DEPENDENCIES on Oracle; information_schema, pg_constraint, pg_depend on Postgres. Extract full DDL for every table, view, procedure, and trigger. Even where foreign keys were never enforced — extremely common in old systems, where devs skipped FK constraints for performance — naming conventions (cust_id, CustomerID, fk_customer) give a first-pass relationship map.
2. Generate a visual ER diagram automatically. Don't hand-draw this. SchemaSpy, DBeaver's built-in ER view, or ER/Studio crawl catalog metadata and produce a diagram in minutes, including inferred relationships from naming patterns even where constraints don't exist. This gives a skeleton to correct rather than a blank page.
3. Profile the data to infer relationships that aren't declared. Run cardinality and value-containment checks — does orders.customer_id actually contain a subset of values from customers.id? That's a strong FK signal even without a constraint. Null rates and distinct counts reveal whether a column is a real foreign key, a denormalized cache, or dead legacy cruft. This turns "I think these tables are related" into "I can prove these tables are related."
4. Instrument live traffic, not just structure. Static schema shows what could relate; it doesn't show what actually happens. Turn on SQL Server Extended Events/Profiler, Oracle SQL Trace/AWR/ASH, or general query logging for a day or two of normal operation. Watching real SELECT/JOIN/UPDATE statements fire is often the fastest way to find true data flow.
5. Grep the application layer, not just the database. Business logic usually lives half in the database (stored procs, triggers, views) and half in application code (ORM models, embedded SQL, config files). Search the codebase for table names once you have them. DBA_DEPENDENCIES / sys.sql_expression_dependencies shows which procs/views touch which tables — a fast dependency graph without reading every line of code.
6. Work backward from known outputs. Rather than mapping the whole database forward, pick a report, dashboard, or screen the business actually relies on and trace it backward — what view feeds it, what tables that view joins, what those tables' upstream sources are. This is usually faster than mapping everything, and it naturally prioritizes the tables that matter for the migration instead of the dead weight most legacy systems accumulate.
7. Talk to the humans who touch the data. The person with the most institutional knowledge on an old system is rarely IT — it's the records clerk or power user who's run the same report for 15 years and knows exactly which field is unreliable and why. A 20-minute conversation can save days of forensic SQL work.
8. Document incrementally, as a living artifact. Build a data dictionary/lineage doc as you go — table → purpose → key relationships → known quirks — even if it's rough. The documentation becomes a deliverable in its own right and keeps you from re-discovering the same table three times.

This is the part most likely to get quizzed directly — get these facts precisely right.

For objective (2) — the agency keeps its on-prem RMS, and you connect it to Axon's cloud.

iPaaS vs. ESB — a likely whiteboard question

• ESB — on-prem hub-and-spoke (IBM MQ, TIBCO, Oracle Service Bus). Strong for legacy SOAP/JMS, high-throughput on-prem messaging. Heavy, slow to change.
• iPaaS — cloud-native, API-first, elastic, webhook-ready (MuleSoft Anypoint, Boomi, Workato). The right default for connecting cloud SaaS to on-prem via secure tunneling agents.

Senior framing: recommend iPaaS/API-led for new work; retain/wrap the ESB only for legacy SOAP/MQ constraints, and run it in parallel during a 60–90 day decommission window.

Messaging, connectivity, and data strategy

• Queues for reliable async sync with dead-letter handling; webhooks for event-driven push; batch/SFTP still valid for bulk historical loads.
• Private connectivity: site-to-site VPN, or Direct Connect/ExpressRoute-style private circuits — all must satisfy CJIS FIPS-validated encryption.
• Replication vs. federation: replication copies data to the cloud (supports analytics, raises duplication concerns); federation queries in place (less duplication, latency depends on source). For "connect without migrating," federation plus selective replication of what Axon needs is often the sweet spot.
• CAD-to-RMS: must be low-latency — Axon's own CFS feed lands in Records within 3–5 minutes.

Note: a competitor blog claims Evidence is "exclusively AWS" — Axon's own current statement describes a mixed Azure + AWS model. Describe it as multi-cloud if asked, rather than committing to one.

Likely question themes

• How do you decide big-bang vs. phased vs. parallel? (→ function of agency size, downtime tolerance, data risk)
• Design a connection where the agency keeps its on-prem RMS. (→ API-led/iPaaS + event-driven sync over private connectivity; replication vs. federation per data domain)
• How do you guarantee data integrity and chain of custody? (→ SHA-256 hashing end to end, reconciliation checkpoints, immutable audit logs)
• How do you handle CJIS during migration? (→ FIPS-validated encryption, MFA, audit logging, signed Security Addendum, least privilege)
• How do you handle resistance from records staff and officers? (→ involve them early as SMEs, especially for dedup adjudication; train heavily; pilot; create champions)

STAR framing with your background

Translate "enterprise Oracle migration" into "mission-critical, 24/7, regulated data" — the constraints map directly. Prepare 3–4 reusable stories: a downtime-minimizing cutover, a data-integrity save, a difficult stakeholder you converted, and a build-vs-integrate architecture decision. Quantify results wherever you can: records migrated, reconciliation accuracy, downtime achieved, adoption rate.

• Cloud-hosting sources conflict — treat Axon's own "mix of Azure and AWS" statement as authoritative.
• Exact Partner API endpoint schemas are behind login; don't overclaim specific paths.
• Market-size and vendor-share figures vary by research firm — use directionally.
• This is a no-coding interview — prioritize architecture, methodology, and standards over syntax.