I first worked with Shiraz at Thrasys, where he built the release and deployment infrastructure behind our social health information exchange behavioral health platform from scratch, along with the engineering process that ran on it. Years later he came back to modernize that same infrastructure for the county that runs it. The platform has been reliably up and serving residents the whole time. That is the whole recommendation. I have worked with him twice, years apart, and I would do it again.
Applications Director, UpHealth Inc.
Read the case study: a county behavioral-health system
Build and release infrastructure, modernization and handoff
Core infrastructure I originally built years ago, still running, moved onto a supported stack without an outage and handed back documented.
The situation
The build and release system behind a county care-coordination platform was running on an operating system that had reached end of life. No security patches were coming. The platform serves vulnerable residents and the county's own teams depend on it daily, so the migration had to happen without disrupting service, inside a locked-down government environment I did not control.
What I did
I ran discovery before committing to a date, then wrote the cutover as a sequence of gates, each with a predecessor and an explicit exit criterion, so nobody had to guess whether a step was safe to start. A weekly status meeting with the agency and the infrastructure team ran for the length of the project. We rehearsed the restore before we needed it, on a snapshot, with one of their own engineers watching, so the rollback path was proven rather than assumed.
On cutover day the machine was paused and backed up before any data moved. The first staging deployment failed on a single database variable, which is the kind of thing you want to find in staging, so we held and fixed it rather than pushing into the production window.
The real constraint turned out to be the environment rather than the migration. A good share of the hours went to clearing bastion and virtual desktop access, expired local administrator credentials on the production hosts, and a private network path that had to exist before an anonymized database restore could be validated at all. I raised the resulting overage in writing, with the reasons itemized, before it arrived as a surprise on an invoice.
The results
- Migrated off an end-of-life operating system onto a current supported release, in place, on the planned date
- Rollback path proven on a snapshot with one of their engineers watching, ahead of cutover
- Production soak closed with no P1 or P2 issues and nothing left open
- Signed off by the agency and the infrastructure department together
- Handed over an operational runbook and a full project history so the county's own team runs it without me
- Knowledge transfer completed to the server team before the engagement closed
Why this matters
Continuity is the point. I built this infrastructure years ago in a prior role, and I am the one who came back to modernize it. Public technology that serves vulnerable people needs someone who stays accountable to a system long after it ships, and who leaves the operators able to run it alone.