Ticketing system migration

The district's technology team was running support out of an outdated ticketing tool that nobody liked using. It had no reliable way to track parts or the purchase orders behind them, so knowing what was in stock, what was on order, and where it was going came down to guesswork. Device records were scattered across separate systems, with no single, trusted view of what the district owned or who had it.

A move to a modern ticketing platform, set up around how the department works. Devices from Jamf, Azure, and Google now live in one record with clear ownership, and parts are organized by the models they fit. New queues, Google sign-on, and email-to-ticket keep requests flowing, while a custom script pulls in purchase orders so parts orders sit right next to inventory.

After hearing the department's frustrations, I recommended a platform I'd seen work at another district, and the team shaped what it needed to do. The work ran in stages: setup, devices, workflows, then parts. Most of it was data cleanup in SQL, Python, and JavaScript, and the parts catalog, full of duplicates and inconsistent names, was the trickiest piece.

A parts catalog of roughly 1,100 entries, full of duplicates, was cleaned down to about 500 accurate ones. The team now knows exactly what parts they have, sees when items are running low and where, and can check the status of parts orders at a glance. Day to day, ticketing is simpler to work in, and reporting finally reflects what's actually happening.