Cloud Engineering & Optimization

A commercial migration moves a workload. A federal one moves an authorization boundary with it. The landing zone needs its own authorization before anything can operate inside it, and the data categorization decides which regions and impact levels are permissible before any target architecture gets drawn.

Acquisition adds friction of its own. GAO reported in 2026 that the Federal Acquisition Regulation still contains no definition of cloud computing, that its definition of information technology is twenty years old, and that its definition of a commercial product or service does not align with cloud at all, despite significant FAR revisions between April and October 2025.

Fifteen of the 24 CFO Act agencies told GAO that outdated acquisition regulations impede cloud procurements, and a further fifteen reported difficulty obtaining authorized cloud solutions.

Lift and shift preserves the cost profile it was meant to improve. Moving a monolith onto larger instances relocates the system without changing how it behaves or what it consumes, and the bill arrives either way.

Consumption billing then exposes that in a way fixed hosting never did. A system that cost a predictable amount each year now costs whatever it uses, which moves with demand, configuration, and whatever somebody left running.

Most agencies cannot see it clearly enough to respond. Twenty-two of the 24 agencies told GAO they rely mainly on historical procurement data to understand cloud spending, and the federal procurement data system itself was not precise enough to determine aggregate cloud spend. Several larger agencies running multiple cloud vendors reported new interoperability problems on top of that.

Rehost, replatform, or refactor is a question about how long a system will live and what it will be asked to do, not about which option is most modern. A workload with five years left and no expected change does not earn a refactor; one that will carry new capability for the next decade rarely survives a rehost.

Placement follows the same logic. Container orchestration suits long-running stateful workloads, serverless suits bursty event-driven ones, and managed services suit anything where running the component yourself provides no advantage.

Right-sizing against observed use rather than a provisioned peak, scheduled scaling for predictable cycles, and storage lifecycle policies close most of the gap between budgeted and actual spend once a workload is running.

At OCH we start with the inventory and the data categorization, because the impact level and the boundary determine what is permissible before any target architecture is worth drawing.

We sequence the work so the landing zone is authorized before workloads move into it, rather than discovering the accreditation gap at cutover with a program waiting on it.

We decide rehost, replatform, or refactor per workload against its remaining life and its running cost, and we record the reasoning so the decision can be revisited when either changes.

We move workloads one at a time with a tested path back, and validate each one in the new environment against its behavior in the old before anything is retired.

We build every environment to be reproducible from version control and hand that code over with the runbooks, so the team that inherits it can operate and change it without us. Console changes introduce drift that is recorded nowhere and tends to surface during an assessment.

We report cost against the program baseline on a regular cadence and tag it to the system and program that incurred it, so the number reaches someone with the authority to change the configuration.