Reconcile permit data classes before a legacy-system cutover

Define the population before mapping fields

Clariti's guide supports a practical starting point: understand what kinds of legacy data exist, whether fields contain their intended meaning, how accurate the data is, and which sources must be migrated. A jurisdiction should turn that preparation into a signed population inventory. List every permitting, planning, licensing, inspection, enforcement, cashiering, document, GIS, email, spreadsheet, desktop database, and archive source; identify the owner, system version, date range, volume, format, access method, and disposition.

Define inclusion and exclusion before conversion begins. Open applications, issued permits, expired licenses, unresolved violations, scheduled inspections, payments, refunds, bonds, conditions, contacts, properties, contractors, attachments, audit events, and closed historical records can have different operational and retention needs. Record the cutover date, extraction window, late-arriving change rule, duplicate policy, legal-hold treatment, and accountable approver so a source total cannot be changed after reconciliation without a visible exception.

Preserve meaning, relationships, and retention decisions

A field crosswalk is not enough when identical labels carried different meanings by department, permit type, era, or workaround. For every mapped value, retain the source table and field, documented meaning, code list, null and default behavior, transformation, target object, owner, test case, and unresolved ambiguity. Do not turn unknown values into clean defaults or rewrite historical statuses using today's workflow. If cleansing changes a value, keep the original, reason, rule, reviewer, time, and affected records.

The guide specifically calls out parent-child relationships and retention questions. Test applications linked to permits, projects to phases, parcels to addresses, people to organizations and licensed roles, plan versions to review cycles, fees to payments and refunds, conditions to inspections, violations to hearings, and documents to the record and revision they evidence. Qualified records, legal, finance, and program owners should decide what migrates, remains accessible in an archive, or is defensibly disposed; the vendor workflow should implement rather than invent that decision.

Reconcile conversion before operational cutover

Acceptance should reconcile counts and control totals by record class, date range, department, status, permit or license type, and source. Add financial totals for assessed, waived, paid, refunded, transferred, and outstanding amounts; document counts and hashes where practical; relationship counts; geospatial exceptions; user and role assignments; open task queues; scheduled events; and audit-history coverage. Sample from source to target and target back to source, including records deliberately excluded or archived.

Run operational scenarios before cutover: reopen a migrated case, issue a correction, receive a payment against an old balance, reschedule an inspection, retrieve the exact approved plan revision, respond to a records request, amend a contact without changing history, and complete an open workflow that began in the legacy system. Record defects, affected populations, corrections, retests, residual exceptions, acceptance authority, rollback criteria, and the ownership of issues carried into hypercare. Go-live timing and migration acceptance remain separate decisions.

Read the buyer guide within its evidence boundary

Clariti's official guide establishes provider guidance about permitting-software procurement, implementation, data preparation, legacy sources, field usage, cleansing, retention, relationship sequencing, and post-go-live support. It does not establish the completeness of a jurisdiction's inventory, correctness of a conversion, records-law compliance, accounting accuracy, workflow fitness, security, accessibility, user adoption, operational continuity, or acceptance. Published timelines and customer outcomes remain provider statements rather than guarantees for another jurisdiction.

Civic Permit Review reviewed the guide on September 2, 2026. Its May 2026 update predates the September 1 publication cutoff and no exact post-cutoff material development was established, so this is durable implementation analysis rather than a current-intelligence event. A buyer test should trace one complex record family from legacy inventory and retention decision through extraction, mapping, transformation, relationship sequencing, reconciliation, scenario testing, exception, acceptance, cutover, and hypercare closure.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.