Moving workloads to the cloud is often presented as a way to get security "for free". Cloud providers invest enormously in physical security and platform hardening, and that is real. But the shared responsibility model means that how you configure and connect your workloads remains your job. A poorly designed on-premises system moved unchanged into a cloud account is still a poorly designed system, now with a public API for its management plane.

For Indian organisations, migration decisions also intersect with data protection law, sector rules and customer expectations. A pre-migration architecture review is the cheapest moment to get these right.

The shared responsibility reality

Providers secure the underlying infrastructure. You are responsible for identity and access, network configuration, data protection settings, workload hardening, application security, and monitoring, to varying degrees depending on whether you use infrastructure, platform or software services. Most publicised cloud breaches trace to customer-side misconfiguration: storage left open, excessive permissions, exposed management ports, leaked access keys.

Why lift-and-shift is risky

Lift-and-shift means moving applications with minimal change. It is fast, which explains its appeal, but it carries forward every weakness of the original design and adds cloud-specific risks:

  • Flat network designs recreated in virtual networks with permissive security groups.
  • Legacy authentication methods and shared accounts migrated without modernisation.
  • Hardcoded credentials in application configuration moving into cloud images.
  • Administrative access paths that were once internal becoming internet-reachable through error.
  • Backup and logging approaches that do not match cloud-native capabilities, leaving gaps.

What to review before migrating

Landing zone design. How will accounts, subscriptions or projects be structured? A well-designed landing zone separates environments, applies baseline guardrails, centralises logging and enforces policy from day one. Retrofitting this later is painful.

Identity and access. Plan federation with your corporate identity provider, enforce multi-factor authentication, apply least-privilege roles, avoid long-lived access keys, and separate administrative duties. Define break-glass procedures.

Network architecture. Design virtual networks with segmentation, private connectivity for sensitive services, controlled ingress and egress, and web application protection for public endpoints.

Data classification and protection. Identify which data is being moved, how sensitive it is, and what rules apply. Decide on encryption, key management and data residency before migrating.

Regional and legal considerations. Consider where data will be stored and processed. Sector regulators may impose expectations on outsourcing and data localisation, and the Digital Personal Data Protection Act introduces obligations around personal data processing and security safeguards. Involve legal and compliance early.

Logging, monitoring and response. Ensure cloud audit logs, network flow logs and workload telemetry are enabled and flow to your monitoring platform. Align incident response playbooks with cloud capabilities. Remember that CERT-In expects log retention within India and rapid incident reporting.

Secure configuration baselines. Use hardened images, infrastructure-as-code with security checks, and policy-as-code to prevent drift.

Resilience and recovery. Design backups to be isolated from production credentials, test restoration, and consider multi-zone or multi-region architecture according to business impact.

Cost and governance interplay. Tagging, budgets and ownership models help prevent orphaned, unmonitored resources, which are a frequent source of exposure.

Re-platform selectively

You do not have to rebuild every application before moving. A pragmatic approach is to categorise workloads:

  • Rehost with remediation: move quickly, but fix the highest-risk design issues first, such as exposed management interfaces and shared credentials.
  • Replatform: adopt managed services, such as managed databases, where doing so reduces your security burden.
  • Refactor: redesign critical or high-risk applications to use cloud-native identity, secrets management and segmentation.
  • Retire or retain: some systems are better decommissioned or kept on-premises.

A review helps assign workloads to the right path based on risk and value.

Third-party and outsourcing considerations

If you are a regulated financial institution, expect close attention to how cloud services are governed under outsourcing and IT governance rules: due diligence on providers, contractual rights to audit and access data, exit strategies, and concentration risk. Even if you are not regulated, enterprise customers may ask for similar assurance.

A pre-migration checklist

  • Landing zone and account structure agreed and documented.
  • Identity federation, MFA and least-privilege roles designed.
  • Network segmentation and ingress controls defined.
  • Data classification complete, with encryption and key management decisions made.
  • Legal and regulatory review of data location and processing completed.
  • Logging and monitoring requirements specified, including retention.
  • Backup, recovery and incident response aligned to the new environment.
  • Security testing planned before and after cutover.

After migration

Treat the move as the start of continuous cloud security management. Use cloud security posture management tools to detect misconfiguration, review permissions regularly, scan infrastructure code, and test the environment through penetration testing once live.

Get a pre-migration review

F9 Infotech reviews cloud migration designs for security, compliance and resilience before you commit, helping you avoid costly rework and exposure. Get a pre-migration architecture review. Message us to discuss your plans.

This article is general information; consult your legal and compliance advisers on regulatory requirements.