Government cloud migration presents unique challenges, including security, the protection of valuable documents, compliance with legal frameworks, and the decoupling of decades-old infrastructure (such as COBOL-based mainframes). Yet, we’ve seen most guides and consulting engagements treat it the same way, using the same steps of assess, plan, lift, test, and cut over.
When that happens, the problems that could have been prevented if they were discovered before the migration force stakeholders into one of two outcomes:
- Live with the architectural debt the migration created. This includes workloads that should have been replaced and dependencies that should have been left behind, all of which sit within the ATO (authority to operate) boundary and generate compliance work indefinitely.
- Or return to the budget cycle months later to request funding to rework what the migration just delivered.
Both options are expensive. But, judging from government cloud migrations we’ve handled, they could have been avoided if the migration had been approached as a series of architectural decisions rather than a sequence of execution steps.
Below, we explain the decision framework we use for every government cloud migration decision, to ensure the eventual workload migration is successful and doesn’t unravel in year two.
The Three-Question Government Cloud Migration Framework
To maximise the benefits of your migration and avoid leaving unresolved problems that cause issues later, we use these questions (which we cover in detail later) for government cloud migrations:
Decision 1: Should this workload move at all?
Migrating your infrastructure to the cloud might seem like the obvious thing to do when you need to modernize your system, meet a new compliance mandate, or get out from under the operating cost of an aging data center. Just set up the environment, lift everything across, and go live, right?
However, doing so neglects the fact that some workloads are best:
- Lifted to the cloud as they are
- Replatformed for the way modern cloud systems actually work
- Retired and replaced with a service that does the same job and is already FedRAMP-authorized.
Which option fits depends on what each workload actually is, what shape it's in, and how long it's going to be around. The criteria below help you make the call.
1. Commodity vs mission workloads
A commodity workload handles mundane tasks which apply to every organization. Tasks such as document storage, email, identity management, ticketing, video conferencing, project management, helpdesk, and case management. For such tasks, there’s usually a market solution, which is FedRAMP-authorized.
Conversely, a mission-distinguishing workload does something specific to your agency's mandate. Examples include the IRS's tax processing system, a defense agency's mission planning software, and a health agency's disease surveillance system. For such tasks, there’s no commercial vendor that sells them, as the solution is built in-house.
Commodity workloads are usually the right candidates for replacement. That’s because there’s usually already a competent and authorized version running at scale. There’s no need to migrate an outdated workload to your own ATO boundary when you can use what already exists and spare your team the hassle of continuous monitoring and patching.
On the other hand, in most cases, replatforming wins for mission-distinguishing workloads. Since they're going to live inside your boundary for years, change often, and carry real mission weight, they're worth building right. Lift is the right call only in certain situations, as determined by the other criteria below.
2. Lifespan
If a system is temporary, project-bound, or already scheduled for retirement within the next year or two, there’s no need to replatform it. What’s the need to extend your migration timeline to migrate or replatform a workload you're sunsetting in 18 months?
On the other hand, any workload that’s core to your agency's operations and will be running through multiple reauthorization cycles is better rebuilt for the cloud or lifted (if the configurations are right).
Essentially, the longer the system will live within your ATO boundary, the stronger the case for replatforming or lifting it.
Note: if the answer to whether this move at all is “we haven't seriously asked”, the rest of the decisions in this framework are premature.
Decision 2: If the workload moves, what shape should it take?
Decision 1 settled which workloads are moving and which aren't. For those that are moving, the second question is: do you lift them in their current shape, or replatform them onto a modern runtime?
Most agencies choose lift by default, just because that’s what the brief says, without thinking twice.
That could be right in some situations, as seen in the framework's first decision. However, in most cases, the state of the infrastructure makes lifting not ideal.
A large share of agency infrastructure still runs on COBOL-based mainframes, in-house systems built decades ago, and applications maintained by engineers who’d left a long time ago. Environments like these typically lack current documentation, were built in ways that few engineers can navigate today, and don't produce the kind of observability data you need for authorizations.
If the system doesn’t align with such a description, it can be lifted or replaced (depending on the other criteria below). But if it describes the workload in front of you, lift is never the right answer unless you don’t mind paying extra to replace it later; it’s better to replatform.
The case for replatforming the workloads onto a Kubernetes system with a modern runtime grows stronger when you consider the benefits:
- Audit evidence: A modern declarative platform automatically records every change to the system. That record is what a FedRAMP control assessment asks for under configuration management, change management, and audit and accountability. So, your ConMon team will no longer need to manually assemble this evidence before every readout. It's already there.
- Reduces compliance overhead from routine changes: In a lifted system, every change is a separate compliance event requiring manual documentation, review, and validation. In a replatformed system, the deployment pipeline includes documentation, review, and validation. Every change ships through the machinery that the assessor has already approved.
- Limits system outages: A replatformed system recovers from common failures without human intervention. If a service fails, the platform restarts it. Or if a node goes unhealthy, the workload moves to another.
From the outside looking in, lifting an infrastructure seems economical since it costs less. It’s probably why it’s the most advocated for by government cloud migration vendors.
However, the continuous monitoring labor, per-change documentation, POA&M maintenance, and the eventual rebuild when the architecture stops scaling all accumulate as recurring costs. None of these appears as line items in the migration budget, but they show up in the work hours that operations and security teams spend on it going forward.
Conversely, replatforming is expensive in month one, but the recurring costs are substantially lower than the lifted equivalent due to the benefits mentioned above.
For any workload that survived Decision 1 as a move candidate, replatform is the default. Lift is only an exception for workloads justified by a short lifespan, temporary scope, intractable dependencies, or (less commonly) workloads that are already modern enough that replatforming would add no real value.
You should ask yourself: since this workload will live within our boundary for years, are we accepting the recurring cost of a lifted architecture, or should we pay once to replatform it?
Decision 3: Which compliance environment are you buying into?
After Decisions 1 and 2, the workload is either being lifted, replatformed, or replaced. Now, decision 3 is specifically which compliance environment it goes into. This is largely determined by the FISMA rating of the data you’ll be migrating.
Under the Federal Information Security Modernization Act (FISMA), every federal system receives a classification based on how much damage a security failure would cause: Low, Moderate, or High. That classification determines how many security controls the system must implement, how strict each must be, and the compliance boundary you can choose.
Most workloads moving to the cloud fall into the moderate or low categories, as those ranked high typically require air-gapped environments with no connection to the cloud. However, a small share of workloads (specifically those handling more sensitive material) fall into FISMA High.
Based on the rating of your data infrastructure, there are three options to pick from, which we’ve visually represented in the image below:
Let’s take a closer look at how we decide which option would be the best fit:
1. Government Cloud suppliers Like GovCloud and its equivalents
AWS GovCloud, Azure Government, and Google Public Sector are cloud regions built specifically for federal workloads. They're physically separated from the commercial cloud and come with extra controls baked in: only US persons can operate them, they're ITAR-eligible (can handle defense-related traffic), and their networks are isolated.
GovCloud and its equivalents are the right choice when your data classification (based on FISMA high, moderate, or low) or agency policy specifically requires them. This includes workloads handling certain categories of Controlled Unclassified Information or ITAR-regulated data.
If the workload's data classification doesn't meet those guidelines, then a FedRAMP Moderate authorization in a commercial cloud region could suffice.
2. FedRAMP-authorized commercial regions
Standard cloud regions like AWS US-East, Azure East US 2, and Google us-central1 hold FedRAMP authorizations covering Low, Moderate, and (for many regions) High. For most agency workloads (which fall under FISMA Moderate), these regions are a viable home. They cost less than GovCloud and come with far fewer operational restrictions.
The catch is that FedRAMP authorization doesn’t directly mean it’s a suitable home for all workloads. Specifically, three things can override what FedRAMP technically permits:
- Your workload's data type: CUI categories like CUI//SP-LEI or CUI//SP-PROP often carry agency-specific handling rules that mandate GovCloud regardless of impact level.
- Your agency's internal policy: Most government agencies publish directives requiring GovCloud for entire categories of mission systems, regardless of FISMA classification.
- Your contract terms: If you're operating a system on behalf of another agency (through an Interagency Agreement, an MOU, or a federal contract), that agency's security requirements apply to you. If they require GovCloud for their data, you're using GovCloud, even when FedRAMP would have allowed the workload in a commercial region.
When a moderate-rated workload isn’t subject to one of these three GovCloud requirements, we usually recommend the commercial path. Compute and storage pricing is lower; foreign-national engineers, contractors, and integration partners can work directly on the system; and the staffing costs associated with US-person restrictions don't apply.
3. Inheriting from a parent agency's P-ATO
A P-ATO (Provisional Authority to Operate) is an authorization issued by the FedRAMP Joint Authorization Board for a specific cloud service or platform. A separate but similar instrument, the agency ATO, is issued by individual federal agencies for the same purpose.
Both let you inherit platform-layer control assessments already completed, including controls for compute, storage, networking, identity, and monitoring. What stays on your side are the controls your workload creates, such as how your application authenticates users, logs sensitive actions, and handles the data it processes.
The most well-known example is Cloud.gov. It's a GSA-run platform-as-a-service holding a FedRAMP Moderate P-ATO, and GSA built it specifically so other agencies could deploy applications on it. This compresses timelines and shaves off the extra time teams spend on compliance monitoring.
So, before standing up a new authorization boundary, we always check whether an existing P-ATO or agency ATO already covers what your workload needs. This could mean checking with other agencies and surveying the FedRAMP marketplace, which lists all rated cloud platforms or services that support tenant inheritance.
If one does, we suggest the inheritance route, which costs less and leaves your team with a smaller permanent compliance workload than authorizing your own environment would.
How to choose the right cloud migration partner
The framework above is a way of thinking about the migration process. Once the decisions you need to make become clearer, the next step is getting a partner that gets it and approaches government cloud migrations the same way.
Given how hard it is to distinguish a partner who will work the framework with you from one who simply wants to execute whatever directives you give, here are four criteria you can use:
Diagnostic posture
This is the most important criterion, as it determines whether the entire set of architectural decisions is well thought out or simply ignored.
A diagnostic partner treats your migration brief as a starting point instead of it being a scope of work. If you arrive saying migrate these twelve workloads to GovCloud, they ask which of the twelve should actually move, whether GovCloud is the right boundary for the ones that do, and what the operational shape should be on the other side.
On the other hand, a non-diagnostic partner takes the brief as given. They may execute it well, but still end up creating more issues down the road.
To test for this during the sales call, describe a system you're planning to migrate and pay close attention to what they ask. A vendor or federal SI (systems integrator) that takes a diagnostic posture will ask what the workload does, who depends on it, and whether you've considered replacing it, while others will go straight to planning execution steps.
Architecture-first thinking
Most federal SIs respond to a migration RFP with a phased execution plan: discovery, planning, lift, validation, and cutover. What's missing is any discussion of what the workloads will look like on the other side.
An architecture-first partner inverts the order. They show you each workload's compliance boundary, the inheritance picture under each boundary option, and what the operating model implies for your team's day-to-day work. Then, the migration plan becomes a consequence of those choices.
US-person personnel and US-soil delivery
Federal cloud migration work imposes personnel and location constraints from several overlapping sources: ITAR for export-controlled data, agency-specific personnel security policies, GovCloud's US-person operational restrictions, and federal supply chain rules. The practical effect is that any vendor that offshores engineering work (to non-US locations, to subcontractors that employ non-US persons, or to tooling pipelines that route through non-US infrastructure) creates compliance risk for your agency.
A vendor with clean delivery commits in the contract to where the work happens and who performs it. They name the locations their engineers operate from, the citizenship status of everyone with access to your systems, and the subcontractor arrangements that will affect the engagement.
On the contrary, a vendor without clean delivery treats this as a topic for the master services agreement boilerplate rather than the sales conversation. The boilerplate sometimes contains language permitting offshore work under conditions the agency would never knowingly approve. The vendor's day-to-day staffing then drifts toward those arrangements because they're cheaper, and the compliance question surfaces only when an audit asks where the work was actually performed.
So, before signing the contract, ask the service provider these three questions:
- Where will the engineers performing this work be physically located?
- What is the citizenship status of every person who will have access to our systems?
- Will any portion of the work (including development tooling, build infrastructure, or support) be performed outside the United States?
Seniority on the team
Federal cloud migration is full of decisions that depend on judgment rather than playbooks. Whether a workload can inherit from a particular P-ATO, where exactly the boundary should fall for a system with mixed data classifications, and how to architect the parallel commercial environment for foreign-national contributors, are calls that require someone who's made them before and can defend the decision when the assessor pushes back.
A vendor with real seniority on your engagement helps ensure that the right thing is done. Their experience earns them the right to disagree with the project's direction when the engagement reveals something the brief didn't anticipate, and to recommend changes. You wouldn’t want to rely on the suggestions from a junior engineer who hasn’t gained enough experience to know the best direction to take.
However, you should also be wary of vendors who sign the contract, staff the engagement with consultants whose hands have never been on a system at your level of impact, and escalate to the senior team only after something has already gone wrong.
The engineer on the sales call should also be highly involved in the migration, so no context is lost between when a salesperson collects the client’s requirements and when it’s executed.
Ask three questions before contracting:
- Who specifically will be doing this work, by name, by title, by years of experience on systems at our impact level?
- What percentage of their time will be on our engagement versus other clients?
- What is your firm's rule for when senior team members can be reassigned during an active engagement?
How Pelotech Approaches Government Cloud Migration Decisions
At Pelotech, we’ve used the same framework above to successfully handle government cloud migrations. And it’s one reason we earn the trust of our clients, who still come to us for other services such as refactoring, devops automation, deployment pipeline work, or longer-term operational support.
Pelotech’s diagnostic approach is unique in that we combine strategic advice, like that of big consulting firms (such as McKinsey, BCG, and Bain), with engineering expertise and years of experience to implement our recommendations.
That’s why we always treat every brief as a starting point. A team that arrives asking for help migrating a workload to GovCloud might leave the first conversation with a better understanding of what they actually need. Half the workloads might be replaced with already-authorised services, a third replatformed for audit defensibility, the remainder split across boundaries depending on data classification, and one or two retired entirely.
This produces smaller ATO boundaries, lower year-two operating costs, and migrations that don't unravel during reauthorization.
However, making such suggestions isn’t for the sake of being contrarian. Rather, our engineers are all highly advanced in their field, have seen various failure modes, and can therefore predict the issues a specific deployment strategy or approach might create in advance. That way, they act as truly informed partners.
For example, UKi came to us to help deploy OD360 in a GovCloud environment that could achieve ATO approval for federal clients. But from our pre-engagement assessment, we found that OD360, in its current form, would not pass a FedRAMP assessment, regardless of which cloud region it ran in.
So, instead of migrating the workload straight away, we refactored OD360 to reduce interdependencies between services and shift the operational model toward self-healing. We then applied the deployment patterns and security automation stack we'd already used in previous successful projects.
Finally, we architected a parallel commercial AWS environment that mirrors the GovCloud setup, so UKi's foreign-national integration partners could continue contributing to the platform without ever touching GovCloud-restricted infrastructure.
By the time the GovCloud deployment was in place, the system had moved from zero self-healing services to all of them, with a cost per environment per month roughly 80% lower. Dr Scott Wells, Co-Founder at UKi, had this to say:
Pelotech are experts in their field. They are plugged into modern approaches, while not being tied to a specific technology to solve a problem. They look at the challenge and consider a wider landscape of what can be applied, while asking the question “what are we actually trying to achieve?” They’ve proposed sound approaches to our challenges and have been able to navigate the, at times, strong opinions that arise when smart people from different teams are working together.”
Need a partner that adopts the same approach for your government cloud migration project? Talk to our engineers today, so they can help you assess your current infrastructure through the lens of the architectural decisions we’ve laid out here.
Avoid Year-Two Infrastructure Remediations Caused By Poor Migrations
Government cloud migration is typically sold as a project. The vendors who sell it that way succeed by their own metrics.
However, the system may begin generating compliance work months after the migration, just because the right option wasn’t followed, and they simply followed your brief. The four decisions in this framework (what moves, in what shape, into which boundary, with what obligations) ensure that it doesn’t happen.
If you're looking for a vendor that follows the decision framework to ensure the migration is tailored to your setup's unique needs, book a free assessment.
