--- title: On-Premises to Cloud Shift description: Explain how security and compliance responsibilities, controls, and operating models change when moving from on-premises to cloud. sidebar: label: On-Premises to Cloud Shift order: 14 source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/security-and-compliance/onpremises-to-cloud-shift/" source_file: "docs/migration/design-and-mobilize/security-and-compliance/onpremises-to-cloud-shift.mdx" --- ## Purpose This module clarifies which security assumptions remain valid from on-premises operations and which must be redesigned for cloud delivery. Compliance obligations remain in force during migration; the main change is the implementation model in cloud operations. ## Key transition differences - **Boundary model**: On-premises often relies on static perimeters, while cloud requires dynamic boundaries. - **Control implementation**: On-premises controls are often manual, while cloud controls should be automated. - **Responsibility model**: Cloud strengthens shared-responsibility patterns across platform and teams. - **Change velocity**: Cloud delivery cycles require controls testable in CI and CD. ## Compliance continuity and adaptation - **Same requirement, different mechanism**: A requirement keeps its intent, but cloud implementation shifts toward policy-based controls and automation. - **Same audit objective, different evidence model**: Evidence shifts from periodic collection to continuous generation from telemetry and audit trails. - **Same accountability, revised operating split**: Enterprise accountability stays unchanged, while responsibilities are redistributed across shared-responsibility boundaries. Typical adaptation patterns by compliance category: - **Data protection and location**: Move from static infrastructure mapping to service-level residency and access constraints. - **Identity and access**: Move from network trust assumptions to identity-first and policy-enforced authorization. - **Audit and evidence**: Move from manual documentation to automated evidence pipelines. - **Resilience and recovery**: Move from occasional testing to continuous monitoring and scheduled recovery validation. ## Practical use of certifications and attestations - **Use C5 intentionally**: Treat C5 reports as evidence inputs for core control domains and migration gap assessments. - **Differentiate Type 1 and Type 2**: For ongoing operating assurance, Type 2 is typically stronger than point-in-time evidence. - **Map requirement to evidence**: Link each internal compliance requirement to explicit evidence from audit logs, telemetry, or attestation artifacts. - **Plan customer responsibilities**: Keep customer-side responsibilities explicit for secure configuration, access governance, and protective controls. ## Migration recommendations - **Map control intent, redesign implementation**: Keep requirements stable and modernize controls. - **Prioritize identity and policy governance**: Reduce location-based trust assumptions. - **Use reusable secure templates**: Standardize onboarding for projects and workloads. - **Define transition exit criteria**: Avoid temporary hybrid exceptions becoming permanent. ## STACKIT references - **Customer accounts and resource structure**: Customer Accounts, Organizations Folders, and Projects - **Network and hybrid connectivity**: Concepts and Product Overview ## Anti-patterns to avoid - **Lift-and-shift security mindset**: Existing control mechanics are copied without cloud adaptation. - **Unmanaged hybrid state**: Transitional exceptions become permanent architecture. - **No ownership update**: Teams keep old mandates without cloud operating responsibilities.