Assessing permit software features, vendor selection, implementation planning, and training. Covers data migration and system integration.
2
hours
0.2
CEUs
Administrative, Legal & Management
1.7.4
Assessing permit software features, vendor selection, implementation planning, and training. Covers data migration and system integration.
Format
On-Demand Online
Delivery
Self-Paced
Access
24/7 After Enrollment
Certification
Certificate of Completion
Have questions about this course or our platform?
Contact our support teamEvaluate permit software based on jurisdiction requirements
Selecting a permit-management system is one of the most consequential administrative decisions a building official will make. A permitting platform is not a routine purchase like a vehicle or a plotter: once a department's records, workflows, fee schedules, and public-facing services are built into a system, the department typically lives with that choice for a decade or more. Every permit issued, every inspection result posted, and every plan-review comment recorded becomes data locked into the vendor's structure, and every staff habit forms around the software's screens. Switching later means another migration, another training cycle, and another period of degraded service. The evaluation phase is therefore where most of the long-term value—or long-term pain—is determined.
The ICC's Building Department Administration textbook frames the purpose of these systems plainly: information technology should automate and streamline the permit process—reducing permitting time, eliminating paper handling, allowing customers to apply online, and improving both customer service and staff efficiency. The same text stresses that the first step is never shopping for software; it is evaluating the current situation. Departments that have implemented technology successfully first went through a deliberate process of self-evaluation and streamlining. Automating a broken workflow simply produces a faster broken workflow.
A disciplined needs assessment starts by mapping how work actually moves through the department today: how an application arrives, who routes it, how plan review is assigned and tracked, how inspections are scheduled, how results get back to the contractor, how fees are calculated and reconciled, and how records are stored and retrieved. Diagnostic questions drawn from the administration text are useful prompts: Are customers expecting a higher level of service than the department currently provides? Do plan review, permitting, and inspections fail to work together in a coordinated way? Is staff unable to keep up with the workload? Are workflows hard to track? Is the department running out of space for property records? Can staff access the system and work remotely? A "yes" to any of these points toward a specific requirement, not just a general desire for "new software."
The assessment must include every user group, not just office staff. Field inspectors need to know whether they can pull approved plans, record results, attach photos, and work where cellular coverage is unreliable. Plan reviewers need markup, versioning, and comment-tracking capability. Permit technicians need intake screens that match the department's actual application types and fee schedule. Finance needs reconciliation and reporting. And the public—applicants, contractors, design professionals—needs a portal for applying, paying, scheduling, and checking status without visiting the counter. Requirements should be sorted explicitly into must-have and nice-to-have categories before any vendor demonstration, because a polished demo has a way of turning optional features into imagined necessities.
Modern systems generally fall into three configurations described in the administration text: stand-alone function-specific tools that solve one problem (scheduling, electronic plan review, payment processing) but are difficult and expensive to integrate; independent integrated solutions built around a community-development hub that connects related functions through application programming interfaces; and enterprise platform solutions in which one vendor's platform serves building, planning, zoning, public works, and finance together. Each carries trade-offs—patchwork tools are cheap but fragile, integrated solutions balance fit and connection cost, and enterprise platforms promise coordination at a high price and long, phased implementations.
A core capability checklist for evaluation should cover, at minimum: full permit lifecycle management from application through certificate of occupancy; electronic plan review with markups, digital stamps, versioning, and simultaneous multi-reviewer access; inspection scheduling and mobile results entry from the field, including offline capture that synchronizes when connectivity returns; automated fee calculation and payment processing; management and statistical reporting; a public portal; and records retention with a reliable path to export the department's own data.
A mid-size department begins its evaluation by convening a task force—permit technicians, a plan reviewer, two field inspectors, an IT representative, a finance staffer, and a local contractor. Before contacting a single vendor, the group charts the current permit workflow on a whiteboard and discovers that inspection results are entered twice: once on paper in the field and again into the tracking spreadsheet at the office. That duplication becomes a documented must-have requirement—single-entry mobile results—that later disqualifies a vendor whose "mobile solution" was merely a read-only viewer. Because the requirement was written down before the demos, the flashy interface could not obscure the functional gap.
The most common evaluation errors are skipping the internal workflow analysis and letting vendor marketing define the requirements; excluding front-line users—especially field inspectors and counter staff—from the requirements process; treating price as the dominant criterion when the administration text warns that a low bid may cloak a need for significant additional services or change orders; and buying capability the department will never configure or use. The corrections are procedural: document workflows first, involve every user group, weight operational fit above sticker price, and require that every must-have be demonstrated—not promised—before selection.
Plan phased implementation and staff training
Once requirements are documented, the formal procurement and implementation process begins. The administration text recommends a request for proposals that includes a short statement of purpose, a glossary of terms to tame technology jargon, a description of expected results, and clearly stated technical and functional requirements. The RFP should be announced broadly—vendors from across the country will respond—and vendors need adequate time to prepare serious proposals; haste at this stage costs more later.
Bid evaluation is where departments most need discipline. The text's advice is blunt: do not accept "vaporware" claims—capabilities that are just over the horizon. Every finalist should give an oral presentation and answer direct questions from the task force. Critically, demonstrations should run the department's own scenarios, not the vendor's rehearsed script. A scripted demo built from the department's real permit types, real fee schedule, and real inspection sequences—including the awkward cases like partial inspections, phased permits, permit extensions, refunds, and re-inspections after failed results—exposes gaps that a vendor-controlled walkthrough is designed to hide. Where logistics permit, finalists should demonstrate their system live in a jurisdiction where it is already running, and evaluators should ask colleagues there candid questions about customization, implementation, training, and support. Reference checks are most useful with departments of similar size and permit volume, since a system that thrives in a large metro agency may overwhelm a five-person department, and vice versa. A sandbox or hands-on pilot period, which the administration text recommends requesting before a final decision, lets staff test drive the software with real data rather than judging it from a projector screen.
Cost evaluation must extend well beyond the license quote. The full picture includes implementation and configuration services, data migration, hardware or hosting, initial and ongoing training, annual maintenance and support agreements, per-user or per-module fees, payment-processing arrangements, and the cost of future upgrades. Support models differ: in-house IT staff can manage a purchased system if they genuinely have the time and expertise; vendor service contracts can bundle technical support, upgrades, and backup arrangements; and hosted or application-service-provider models shift infrastructure to the vendor for a recurring fee—an attractive option for departments without IT depth, provided the contract confirms the jurisdiction owns its hosted data and can obtain copies. Redundancy, backup schedules, and security arrangements belong in the contract discussion, not as afterthoughts.
After award, the work shifts to an implementation team distinct from the selection task force, working directly with the vendor. The administration text describes six overlapping implementation steps: install and connect hardware; install software; define system integration; migrate the database; test thoroughly; and train. Some customization is inevitable—forms, fee tables, workflow routing, and notification templates all need configuration to match department procedures—and the schedule must allow real time for it. Testing should simulate complete sample projects through plan review, permitting, and inspections under realistic conditions, and going live should occur only when the system is completely tested. Training deserves particular respect: the text calls it among the most important and most easily mismanaged aspects of implementation. Many vendors use a train-the-trainer approach in which team leaders receive deep training and then teach their coworkers; whatever the model, training must be role-specific, scheduled in advance, and repeated as the system evolves. Phasing matters too—many departments go live with core permitting first, then add the public portal, electronic plan review, or mobile inspections in later phases so staff are not absorbing everything at once.
Where a selected vendor cannot yet meet a mandatory requirement—for example, a state-mandated report format—the gap should be handled contractually, with specific deliverables, deadlines, and consequences, plus an interim plan for meeting the obligation until the customization arrives. Verbal assurances are not a compliance strategy.
A department narrows its search to two finalists. Vendor One's demonstration is polished and impressive. The department, however, insists both vendors run its scripted scenario set, which includes a foundation permit with partial inspections on a phased commercial project. Vendor One's system, it turns out, can only record an inspection as passed or failed—there is no way to approve a portion of the footing and hold the remainder, a workflow the department uses weekly. Vendor Two handles the partial-result workflow natively. The scripted demo, built from the department's real work rather than the vendor's script, surfaces in one afternoon a limitation that would otherwise have been discovered after go-live, when it would have been a crisis instead of a data point.
Frequent errors in this phase include accepting vendor-scripted demonstrations at face value; skipping reference checks or calling only the references the vendor hand-picks; comparing license prices while ignoring implementation, migration, training, and recurring support costs; accepting promised future features without contractual commitments; and compressing training into a single pre-launch session. The corrections: script the demos around the department's own scenarios, seek out comparable jurisdictions independently, evaluate total cost of ownership over the expected system life, put every promised capability into the contract with deadlines, and treat training as a phased, ongoing program with refreshers after go-live.
Integrate permit software with other municipal systems
A permitting system rarely stands alone. Building departments coordinate with planning and zoning, code enforcement, fire safety, public works, utilities, finance, and geographic information system services, and the value of a modern platform multiplies when data flows among them. The administration text notes that integrated configurations depend on software that exposes an application programming interface, and that enterprise systems can coordinate activities across building safety, planning, development, GIS, finance, and public health. GIS integration is particularly valuable for a building department: tying permits to parcels supports address verification, inspection routing by geography, and visualization of permit activity across the jurisdiction. Integration carries a maintenance cost, however—when each vendor upgrades independently, the connections between systems can break and must be rebuilt, so integration responsibilities and upgrade coordination belong in the contracts.
Data migration deserves its own plan, because the administration text identifies migrating data from existing databases as potentially the biggest and most difficult part of implementation—an arduous task that is easily underestimated and often rushed. Legacy records must be checked, corrected, standardized, and synchronized before transfer, and departments with decades of paper files need a phased strategy: migrate active permits and recent records first so daily operations continue uninterrupted, digitize historical records over time or on demand when a property sees new activity, and keep the legacy filing system accessible during the transition. Records retention obligations do not pause for a software project; whatever the platform, the department must be able to produce its records for the retention periods the jurisdiction requires and export its data in usable formats if it ever changes vendors. Data ownership language in the contract is the safeguard that keeps a hosted vendor relationship from becoming a hostage situation.
The recurring failure modes in permit-software projects are organizational, not technical. Departments buy feature-rich platforms and use a fraction of the capability because nobody was assigned to configure the rest. Front-line staff are excluded from selection, and the system fights the way work actually happens at the counter and in the field. Configuration effort is underestimated—fee tables, workflow rules, correction-letter templates, and notification settings all take sustained staff time that must be protected from daily workload. Duplicate data entry survives the transition because a paper habit was never formally retired. The remedy in each case is management attention: assign ownership, involve users, schedule configuration work realistically, and audit the workflow after go-live to confirm the old shadow processes actually ended.
Evaluation should also look forward. The administration text highlights several directions worth weighing in any selection today: hosted software-as-a-service solutions that expand online permitting and project tracking for jurisdictions of every size; remote virtual inspections, which use live video to complete routine inspections such as simple equipment replacements—supported by the ICC's published recommended practices for remote virtual inspections—with newer platforms adding geo-tagging, photo and video capture, scheduling, and checklist access directly in the inspection record; and performance analytics, where data compiled across departments supports planning and targeted enforcement. A system chosen now should not foreclose these capabilities later, which is another argument for open interfaces and exportable data.
A department implementing a new platform inventories its integration points before configuration begins: parcel data from the county GIS, cash receipts to the city finance system, contractor license verification with the state, and address records shared with the fire department. The GIS link is scoped into phase one because address validation touches every permit; the finance interface is scheduled for phase two with a documented manual reconciliation procedure in the interim. Meanwhile, the records supervisor runs the migration workstream: active permits are cleaned and migrated before go-live, the previous five years follow in monthly batches, and older files are scanned on demand. Because each integration and migration phase has an owner and a date, the project survives the departure of the IT lead mid-project without losing scope.
Typical integration-phase mistakes include assuming systems will "talk to each other" without verifying interfaces and assigning responsibility for building and maintaining them; rushing data migration and discovering corrupted or unmapped records after the legacy system is retired; failing to secure contractual data ownership and export rights from a hosted vendor; and declaring victory at go-live without retiring duplicate paper processes. Corrections: inventory and contract for every integration explicitly, treat migration as a managed workstream with cleaning and verification steps, insist on data ownership and export language before signing, and follow through after launch until old workflows are formally decommissioned.
This course provides comprehensive professional development in permit software evaluation and implementation. Assessing permit software features, vendor selection, implementation planning, and training. Covers data migration and system integration. A permitting platform is a decade-scale commitment, so the work begins with self-evaluation and workflow mapping, proceeds through requirements gathered from every user group, and tests vendors against the department's own scripted scenarios rather than rehearsed demonstrations. Sound selection weighs total cost of ownership, verifies claims through reference checks and pilots, and converts every promised capability into a contractual obligation. Implementation succeeds through a dedicated team, realistic configuration schedules, thorough testing, phased rollout, role-specific training, and a managed data-migration workstream—while integration planning, data ownership protections, and attention to emerging capabilities such as remote virtual inspections keep the investment serving the department and its community for the life of the system.