Cloud & Enterprise IT for State Agencies
Cloud and Enterprise IT for State Agencies
Migration sequencing, landing zones, identity, and cost governance for state agencies moving large legacy portfolios under central IT standards.
A state agency rarely gets to make a clean cloud decision. The application portfolio was assembled over decades, and much of it runs somewhere the agency does not fully control: a consolidated state data center, a hosting arrangement inherited from an earlier contract, or equipment in a building the agency has since given up. Central IT publishes standards saying new workloads belong on an approved cloud platform under an approved security baseline. The project approval process wants an architecture and a cost estimate before the design work that would produce them. Appropriations are written for equipment purchases in a budget cycle, while cloud is billed monthly by consumption. Meanwhile a program area has already bought a SaaS product and opened its own subscription.
The engineering is not usually the hard part. The hard part is sequencing: which systems can move as they are, which need re-platforming first, which are tied to a mainframe batch interface or a network path shared with other departments, and how each of those decisions is explained in an approval package, a federal cost allocation plan, and a budget request. Work that skips that framing tends to stall at a gate rather than in a console.
What these environments look like
- A consolidated state data center or hosting provider shared with other departments, with change windows, network paths, and refresh schedules the agency does not set
- Mainframe or midrange systems carrying statutory logic, exchanging batch files with newer applications and with county, contractor, or federal partners
- Statewide systems whose users include county staff, licensed professionals, providers, and the public, so downtime has to be negotiated across many organizations
- Central IT standards for cloud platform, security baseline, identity, and network connectivity, usually with a review or approval step before a workload moves
- Active Directory forests and trust relationships grown through reorganizations, with service accounts nobody is willing to disable
- District offices, field staff, and laboratories across the state on a network designed around a data center in the capital
- Disaster recovery described in a continuity of operations plan in more detail than it has recently been tested
Where HQT helps
- Portfolio assessment and migration sequencing, with a disposition for each application, dependency and interface mapping, and a written rationale that works in both an engineering review and an approval submission
- Landing zone design on the platform the state has standardized on: account and subscription structure, connectivity back to the state network, centralized logging, and a security baseline mapped to the control catalog the state policy is built on, together with whatever cloud service authorization the state expects of its providers
- Infrastructure as code and deployment pipelines, so environments are rebuildable, changes are reviewable, and the evidence oversight bodies ask for comes out of the work rather than being assembled afterward
- Identity and access design: directory consolidation, single sign-on for staff and external partner users, privileged access controls, and access reviews that program managers can realistically complete
- Network and segmentation design, including separation for workloads under stricter regimes such as federal tax information, criminal justice data, or protected health information, so those controls apply where required rather than everywhere at uniform cost
- End-user computing: device management, remote and virtual desktop access for field and case-carrying staff, and the tenant, mailbox, and file share work that comes with a consolidation
- Cost governance and disaster recovery: tagging and account structure that support chargeback and cost allocation, committed capacity where usage is stable, budget alerts and right-sizing reviews after migration, and recovery objectives agreed with program owners, exercised rather than assumed
How an engagement usually starts
Work of this kind usually begins with a date or a finding. A data center exit, a hardware refresh the agency would rather not repeat, an operating system or database version leaving support, a central IT directive on cloud adoption, an audit finding about untested recovery, or a cloud bill that grew past what the program budgeted after a subscription was opened without structure. Any of these creates a need for a plan that can survive review.
The realistic first step is a bounded assessment of a defined slice of the portfolio rather than the whole estate. That produces application dispositions, a target architecture consistent with central IT standards, a cost model comparing current hosting to consumption pricing across a full budget cycle, and the supporting material the agency needs for its project approval submission. Our people work with agency engineers and central IT staff rather than around them, and we scope the assessment so it can be procured without a lengthy solicitation, whether under delegated authority or through an arrangement the agency already uses.