Public Safety Platform Rewrite - FoxPro to .NET
Multi-year program. CAD, RMS, MCT for a customer base of 2,500+ public safety agencies.
The system
The product suite was three connected applications that public safety agencies depended on for day-to-day operations:
- CAD (Computer Aided Dispatch): 911 call intake, dispatch, and unit tracking. Used by dispatchers in 911 centers, 24/7.
- RMS (Records Management System): criminal justice records: incident reports, arrests, evidence, case management.
- MCT (Mobile Computer Terminal): the application running on the laptops in patrol cars, sending and receiving dispatch information from the vehicles.
The codebase had grown up in FoxPro over many years. It worked, customers depended on it, and replacing it without disrupting the agencies in production was the constraint that drove every architectural decision.
What the program actually was
It is easy to describe this as "we rewrote it in .NET." That undersells the operational complexity. The real program was:
Deciding what to rewrite and what to leave. Not everything in FoxPro needed to move. Some modules were stable, low-touch, and would have been a waste of capacity to touch. We made an explicit list of what was in scope, and we were deliberate about what was not.
Running both versions in production for years. Agencies could not migrate on the same date. We supported customers on the existing version while shipping the new one, which meant data compatibility, dual operational models, and disciplined feature parity for a long stretch.
Coordinating with customer agencies. 911 centers and police departments do not take downtime windows the way most B2B SaaS customers do. Cutovers had to be planned around shift changes, with rollback paths and customer-side training built in.
Hiring and growing the team to do it. A rewrite of this size needs people who can hold the existing domain in their heads while writing the new system. I spent a lot of those years hiring college graduates and growing them into senior engineers.
What I worked on
I came in as a senior engineer and grew into engineering management while the program was running. Over the course of it I:
- Took on architecture responsibilities for parts of the rewrite, including schema design and the data path between the new .NET services and the existing FoxPro-era data.
- Moved into engineering management: recruiting, mentoring, performance management, and agile coaching.
- Owned the operating model for production support across the suite.
- Contributed to the company-wide agile transformation, both in my own teams and at the org level.
What I would want someone to take away
You do not rewrite a system. You replace it in segments, with the old one running. The teams I have seen fail at modernization are the ones that try to rewrite in a parallel branch and cut over once. The teams that succeed run both versions for years and migrate customers in waves.
Customer cutover is engineering work, not Customer Success work. The runbooks, rollback procedures, data verification scripts, and on-call coverage during cutover are all engineering deliverables. Treating them as a downstream handoff is one of the most common ways migrations go wrong.
Domain knowledge compounds. Hiring for the capability to hold two systems in your head, and growing it through real responsibility, paid off more than any framework choice we made.
Recognition
I was selected for the company's FAB50 leadership group during this period - a CEO-level recognition program for the top 50 leaders across a 2,000+ person organization.