Cloud migration is safer when the operating foundation exists before workloads arrive. Identity, account structure, network, logging, security, information governance, recovery, cost, support, and ownership should be reusable controls—not improvised for each cutover.
Publication boundary: This article provides general educational and operational guidance. Publishing it does not mean ITECS or any specialist approved a reader’s organization-specific implementation, measured its results, made a legal or compliance determination, or verified a vendor’s configured capability.
Current as of 2026-08-15
CISA’s cloud architecture hub covers shared services, migration, data protection, and cloud security posture management. NIST SP 800-145 defines the service and deployment models that clarify responsibility.
Decision summary
- Assign cloud platform, workload, information, security, finance, and support owners.
- Create reusable identity, network, logging, configuration, and recovery controls.
- Establish allocation, budgets, lifecycle, and provider-management practices.
- Pilot the foundation and keep portability and exit visible.
Define the cloud operating model
Name decision rights for account creation, identity, network, security, information, cost, architecture, exceptions, incidents, backup, restoration, support, and decommissioning. Clarify provider, platform team, workload team, managed provider, and business-owner responsibilities.
Build reusable landing controls
- Organization and account structure, federated identity, least privilege, and emergency access.
- Network, DNS, egress, segmentation, encryption, keys, secrets, and certificates.
- Logging, monitoring, configuration baselines, policy, patching, and incident response.
- Approved regions, information classes, retention, backup, restoration, and deletion.
- Tags, allocation, budgets, alerts, quotas, support, and lifecycle automation.
Test the foundation with a real workload
Choose a representative but bounded workload. Test deployment, identity, information, integrations, observability, support, security, failure, recovery, cost allocation, and decommissioning. Record exceptions and update reusable patterns before scaling.
Operate for value and exit
Review ownership gaps, configuration drift, privilege, cost anomalies, unsupported services, backup evidence, provider changes, and incidents. Maintain architecture, exports, procedures, and skills needed to move or retire services in proportion to concentration and business risk.
Next step for your environment
Pilot the landing foundation with one bounded workload and prove deployment, security, support, recovery, cost allocation, and decommissioning.
Record the accountable owner, baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.
If you need an independent baseline before changing production systems, start with an ITECS technology and security assessment and keep the resulting evidence with the decision record.
Sources and update trigger
- CISA — Cloud Security Technical Reference Architecture hub
- NIST — SP 800-145: Definition of Cloud Computing
- FinOps Foundation — FinOps Framework
Review trigger: Review after provider, account, identity, network, information, region, cost, recovery, policy, workload, or exit changes.
continue reading
More ITECS blog articles
About ITECS Team
The ITECS team consists of experienced IT professionals dedicated to delivering enterprise-grade technology solutions and insights to businesses in Dallas and beyond.
View full profile and articles