Public cloud migration for CUI workloads: a five-gate playbook
Most public cloud migration guides treat the move as an IT project: inventory, replatform, cut over, celebrate. When Controlled Unclassified Information (CUI) is in the workload, that framing fails, because what you are actually moving is a set of obligations. DFARS 252.204-7012 and NIST SP 800-171 apply in the target environment from the first byte, not after a stabilization period, and the evidence you generate during the move is the evidence you will stand on later. This playbook runs the migration as five gates, each one a point where the project either stays assessable or quietly stops being so.
What makes a public cloud migration different when CUI is involved?
The obligations travel with the data, and they do not pause for the project plan. DFARS 252.204-7012 requires that an external cloud service provider used to store, process, or transmit covered defense information meet security requirements equivalent to the FedRAMP Moderate baseline, and its rapid incident reporting requirement applies during the migration window, which is often when data is most exposed. NIST SP 800-171 Rev 2 applies to the target environment the day CUI arrives in it.
The practical consequence is that security architecture and evidence generation are migration workstreams, not post-migration cleanup. A migration plan with no evidence column is a plan to reconstruct that evidence later, from memory, at several times the cost.
Gate one: scope the data before you scope the migration
The first deliverable of a CUI migration is a data inventory and flow map, not a server list. Establish where CUI enters, where it is stored and processed, who touches it, and where it leaves. That map drives every downstream decision: which environment you are migrating into, which workloads travel in which wave, and which systems get decommissioned rather than moved.
A workable map fits on a page: the systems that hold CUI, the interfaces between them, the people and roles with access, and the external parties, primes, and portals the data arrives from and returns to. Skipping this gate is how migrations discover, three waves in, that a system classified as non-CUI syncs a CUI repository nightly. The readiness questions worth answering before anything else are covered in our migration readiness checklist (https://vso-inc.com/migration-readiness-12-questions-before-moving-cui/).
Gates two and three: design the landing zone, then prove it before anything moves
Identity, segmentation, encryption, and logging exist and are verified before the first workload arrives. In Azure Government or AWS GovCloud (US), that means the identity and access design settled, including who administers the environment, from where, and with what multifactor authentication; a network layout with controlled ingress and egress; FIPS-validated encryption configuration for CUI at rest and in transit; and centralized audit logging switched on from the first account or subscription, not retrofitted.
Two design decisions deserve extra scrutiny at this gate because they are expensive to reverse: the account and subscription structure, which becomes the skeleton of logging and access control for years, and the identity model, because every workload that lands will inherit it.
Update the system security plan (SSP) for the target architecture now. An SSP that still describes the old data center while CUI lives in the cloud is a finding waiting to be written. Then run a pilot with a non-CUI workload to shake out connectivity, operations, and cost behavior before regulated data moves.
Gate four: migrate in waves, and generate evidence as you go
Wave design is mostly dependency reading: file services travel with the applications that mount them, the quality system that reads engineering data follows the engineering data, and anything with a hardware tie, license servers and shop-floor integrations included, gets planned last and tested twice.
Move workloads in dependency groups, and close each wave with evidence rather than a status update: encryption verified in transit and at rest, access reviewed against the design, logs confirmed flowing to the central store, change records complete, rollback documented and tested at least once. Each closed wave becomes a package an assessor can read.
This is cheaper than it sounds, because everything in that list is work the wave requires anyway. The only added discipline is capturing it while it happens instead of reconstructing it afterward.
Gate five: cutover is not the finish line
Decommission the source environment deliberately. NIST SP 800-171 requires that system media containing CUI be sanitized or destroyed before disposal or release for reuse (requirement 3.8.3), and the storage left behind in a private environment is where that requirement most often dies quietly.
Then the operating model takes over: patching, configuration drift, monitoring, logging, and cost management in a government region. That is its own discipline, and it is where environments that migrated cleanly still degrade.
Treat the SSP as the migration's living record. If it accurately describes the environment at every gate, the migration is assessable by construction, and the document you finish with is the document you would have needed anyway.
VSO's cloud services team plans and runs CUI migrations into Azure Government and AWS GovCloud for Defense Industrial Base contractors. If your migration plan is currently a server list without a data map, that is a fixable problem.
