{"slug": "what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud", "title": "What Should an IT Head Check Before Moving Critical Workloads to the Cloud?", "summary": "NS3 outlines a pre-migration checklist for IT leaders moving critical workloads to the cloud, arguing that the decision should hinge on workload readiness rather than the choice between AWS, Azure, or Google Cloud. The guidance cites Gartner's forecast that Indian public cloud spending will reach $17.5 billion in 2026 and Mandiant research finding identity issues were the initial access vector in 83% of major cloud and SaaS incidents in the second half of 2025. NS3 recommends starting with application dependency mapping and security assessment before any infrastructure procurement.", "body_md": "tl;dr: Moving a critical application to the cloud is not simply a matter of choosing AWS, Microsoft Azure, or Google Cloud and shifting servers.\n\nBefore migration, an IT Head needs to answer much harder questions:\n\nWhat data is moving? Who can access it? What systems does the application depend on? What happens if the cloud service becomes unavailable? How will the organization meet regulatory requirements? What will the migration actually cost? And, most importantly, how will security be maintained after the migration?\n\nThe questions are becoming more important in India as cloud adoption accelerates. Gartner forecasts that end-user spending on public cloud services in India will reach $17.5 billion in 2026, a 28.1% increase from 2025. Gartner identifies demand for AI-ready infrastructure, application modernization, digital sovereignty and scalable IT models as major drivers.\n\nAt the same time, the risk environment is getting harder to ignore. CERT-In recorded 29,44,248 cyber security incidents in India during 2025, up from 20,41,360 in 2024. IBM reported that the average total cost of a data breach in India reached ₹22 crore in 2025, 13% higher than the previous year.\n\nFor an IT Head, the real question is therefore not:\n\n\"Should we move to the cloud?\"\n\nIt is: _\n\n*\"Are we ready to move this particular workload to the cloud without creating a security, compliance, cost or business-continuity problem?\"* \n\nCloud has changed the way enterprises build and operate IT infrastructure.\n\nApplications no longer sit inside one data centre behind one network perimeter. A modern business application may depend on cloud databases, APIs, identity providers, SaaS platforms, third-party integrations, remote users, endpoint devices, backup environments and multiple network paths.\n\nThat makes migration less about moving infrastructure and more about understanding relationships.\n\nA server can be migrated successfully while the business application still fails because an old API was missed, a DNS dependency was overlooked, a firewall rule was not recreated, an identity service was unavailable, or a backup process was never tested in the new environment.\n\nThis is one reason recent cloud security research is focusing heavily on identity and configuration rather than the simple question of where the workload is hosted.\n\nGoogle Cloud's M-Trends 2025 research found that exploits were the most common initial infection vector at 33%, followed by stolen credentials at 16%. Mandiant also specifically highlighted risks introduced during cloud migrations and attacks targeting unsecured data repositories.\n\nIts Cloud Threat Horizons research for the second half of 2025 found that 83% of incidents involving major cloud and SaaS-hosted environments involved identity issues as an initial access vector, while data theft was the objective in 73% of cloud-related incidents reviewed.\n\nThat changes the migration conversation.\n\nA cloud project should be treated as an IT transformation and security project at the same time.\n\nOne of the most common migration mistakes is starting with the question:\n\nAWS, Azure or Google Cloud?\n\nThe better first question is:\n\nWhich workloads should actually move, and why?\n\nEvery critical workload should be assessed before a migration decision is made.\n\nAt minimum, an IT team should document:\n\nAn application inventory is useful, but an application dependency map is even more important.\n\n`For example, an ERP system may appear to be one application. In reality, it may depend on an identity platform, database cluster, DNS, file storage, payment gateway, backup infrastructure, email services, internal APIs and third-party applications.`\n\nIf even one critical dependency is ignored, a migration can create downtime.\n\n```\nA practical NS3 approach\n```\n\nAt NS3, the right way to approach a cloud migration is not to begin with infrastructure procurement. The first step should be understanding the current IT environment, identifying dependencies and determining which workloads are suitable for migration.\n\nThat assessment creates the basis for the migration architecture instead of forcing the business into a technology choice too early.\n\nNot every piece of data carries the same level of risk.\n\nAn enterprise may have:\n\nBefore migration, the IT team needs to know exactly where sensitive information exists and where it will be stored after migration.\n\nThis is particularly important because India's data protection environment has changed significantly.\n\nThe Government of India notified the Digital Personal Data Protection Rules, 2025 in November 2025. The rules establish requirements around reasonable security safeguards, including encryption or masking, access controls, logging and monitoring, data backups, security provisions in contracts with Data Processors, and measures for detecting and responding to unauthorized access. The rules also require specified information about a personal data breach to be provided to the Data Protection Board within 72 hours, subject to the framework and applicable timelines.\n\nThe important point for an IT Head is simple:\n\n`Putting personal data in the cloud does not transfer responsibility for protecting that data to the cloud provider.`\n\nThe organization still has to understand how the data is collected, accessed, processed, retained, monitored and deleted.\n\nOne of the most dangerous assumptions in cloud adoption is:\n\n\"The cloud provider handles security.\"\n\nIt does not work that way.\n\nAWS, for example, explicitly describes cloud security as a shared responsibility. The provider secures the infrastructure of the cloud, while customers remain responsible for security within the cloud, depending on the services they use.\n\nThat means an enterprise can still create a serious security problem through:\n\nIncorrect IAM permissions \n\nExposed storage \n\nWeak passwords \n\nMissing MFA \n\nInsecure APIs \n\nPoor network segmentation \n\nUnpatched workloads \n\nPublicly accessible management interfaces \n\nMisconfigured security groups \n\nExcessive administrator privileges \n\nInadequate logging \n\nPoor key management \n\nUnprotected backup environments \n\nThe cloud can provide excellent security controls, but those controls need to be correctly designed and operated.\n\nTraditional IT security was built heavily around network boundaries.\n\nCloud changes that model.\n\nUsers, administrators, applications, APIs and machines may all need access to cloud resources from different locations.\n\nNIST's cloud and zero trust guidance therefore places much stronger emphasis on identity, authentication, authorization and continuous verification. In cloud-native environments, security policies need to consider both network and identity layers.\n\nBefore migration, an IT Head should ask:\n\nWho needs access? \n\nWhat exactly do they need to access? \n\nWhy do they need that access? \n\nHow often should the access be reviewed? \n\nWhat happens when the employee leaves or changes roles? \n\nA strong cloud migration plan should include:\n\nThis area deserves particular attention because identity remains one of the major paths into cloud environments.\n\nGoogle Cloud's M-Trends 2025 research reported stolen credentials as the second most common initial infection vector in its investigations, while its later cloud threat research found identity issues in 83% of cloud and SaaS incidents reviewed for H2 2025.\n\nA cloud migration changes network traffic.\n\nTraffic that previously moved between servers inside a data centre may now move between:\n\nThe architecture therefore needs to be redesigned rather than simply copied.\n\nAn IT Head should review:\n\nConnectivity \n\nHow will the office and data centre connect to the cloud? \n\nWill the organization use dedicated connectivity, VPN, SD-WAN or a combination? \n\nSegmentation \n\nWhich systems should be isolated? \n\nShould production, development and testing environments communicate with one another? \n\nInternet exposure \n\nWhich applications actually need to be public? \n\nWhich services should remain private? \n\nEast-west traffic \n\nHow will traffic between cloud workloads be controlled? \n\nDNS and routing \n\nWhat changes will occur when applications move? \n\nRemote access \n\nHow will employees, vendors and administrators access the environment securely? \n\nMonitoring \n\nCan the security team see traffic across both cloud and on-premises environments? \n\nNetwork architecture needs to be designed with security, performance and resilience together.\n\nCloud migration creates a period where old and new environments coexist.\n\nThis is often one of the weakest stages of the project.\n\nAn enterprise might have:\n\nData centre → VPN → cloud → SaaS → third-party API \n\nwith different security controls at every point. \n\nBefore moving a critical workload, organizations should assess: \n\nVulnerabilities \n\nCERT-In has specifically warned that data breach and data leak incidents can result from compromised or misconfigured cloud instances, including AWS S3, Azure Blob and Google Cloud storage. Its advisory recommends checking public accessibility, securing cloud access tokens, separating production from testing and backup environments, and encrypting data at rest and in transit.\n\nFor critical workloads, security testing should happen before migration, during migration and after the environment becomes operational.\n\nCloud breaches are useful lessons because many of them do not happen because the underlying cloud platform was \"hacked.\"\n\nThey happen because something around the platform was poorly configured, over-permissioned, exposed, or insufficiently monitored.\n\n`Case Study: Angel One's AWS security incident` \n\nIn February 2025, Indian stockbroker Angel One disclosed that some of its AWS resources had been compromised. \n\nThe company said an external forensic partner was engaged to investigate the incident and that its client securities, funds and credentials were not affected. It also said it immediately changed credentials associated with its AWS cloud environment and other applications after being alerted by its dark-web monitoring partner.\n\nThe incident is important for IT leaders because it highlights a practical reality:\n\nCloud security does not end when the migration is complete.\n\nCredentials need to be managed. Environments need to be monitored. Unusual access needs to be investigated. Incident response needs to exist before an incident happens.\n\n`Case Study: Capital One` \n\nA more widely studied example is the 2019 Capital One breach. \n\nCapital One disclosed that approximately 100 million people in the United States and around 6 million in Canada were affected. The company estimated incremental costs of roughly $100 million to $150 million in 2019 related to customer notification, credit monitoring, technology and legal support.\n\nTechnical analysis of the incident identified a chain involving a misconfigured firewall, access to an EC2 instance, IAM permissions and S3 data.\n\nCapital One itself also made an important point: the vulnerability was not inherently a \"cloud problem.\" The infrastructure involved could have existed in other environments as well.\n\nThat is an important lesson for enterprises considering migration.\n\nMoving to the cloud does not create security risk by itself. Poor architecture, configuration, and governance create the risk.\n\nAn organization should never discover its recovery strategy during an outage.\n\nBefore migrating a critical application, define:\n\nThe cloud can improve resilience, but only when resilience is deliberately designed.\n\nA backup that exists but has never been restored is not a recovery strategy.\n\nFor critical applications, IT teams should conduct actual recovery exercises and document:\n\nThese questions should be answered before production migration.\n\nCompliance needs to be treated as an architecture requirement, not a document that gets reviewed at the end.\n\nThe relevant requirements depend on the industry.\n\nFor example, India's financial sector has specific technology outsourcing requirements. RBI's Outsourcing of IT Services Directions, 2023 include requirements around cloud computing services and require regulated entities to maintain a clear exit strategy for outsourced IT activities. The exit strategy is expected to address continuity and alternatives if the relationship with the service provider ends.\n\nSEBI's Cybersecurity and Cyber Resilience Framework for regulated entities also addresses areas including asset inventory, classification of critical systems, vulnerability assessment, audits, outsourcing, cloud service providers, log management and data security.\n\nThis leads to an important migration question:\n\nIf we have to leave this cloud provider, can we actually get our data and workloads out safely?\n\nThat is where exit strategy becomes important.\n\nVendor lock-in does not always happen because an organization signs a long contract.\n\nIt can happen technically.\n\nOnce applications begin depending heavily on proprietary databases, cloud-specific APIs, managed services and custom architectures, moving to another platform may become expensive and difficult.\n\nBefore choosing a cloud architecture, ask:\n\nNot every organization needs a multi-cloud architecture. \n\nBut every organization should understand its exit risk.\n\nCloud can reduce capital expenditure, but that does not automatically mean it will reduce the total cost of IT.\n\nA migration budget should include:\n\nBefore migration\n\nDuring migration\n\nAfter migration\n\nA workload that is poorly sized can create unnecessary recurring costs.\n\nThe organization therefore needs a baseline: \n\nWhat does this workload cost today? \n\nThen compare it with:\n\nWhat will the same business service cost in the cloud?\n\nThe answer should not be based only on virtual machine pricing. \n\nA cloud environment can work perfectly in a test environment and still perform poorly at production scale.\n\nCritical workloads should be evaluated for:\n\nPerformance testing should use realistic business workloads.\n\nA finance application, ERP system or customer-facing platform should not be considered migration-ready simply because the application successfully starts in the cloud.\n\nThe question is:\n\nDoes it perform at the level the business requires?\n\nThere is a temptation to change everything at once.\n\nThat can turn a manageable migration into a high-risk transformation.\n\nA better approach is to decide whether each workload should be:\n\nA stable legacy application may only need a controlled rehosting strategy.\n\nAnother application may benefit from modernization.\n\nThe correct choice depends on business value, technical debt, security requirements and expected lifecycle.\n\nOnce an application enters the cloud, the IT team needs visibility into:\n\nLogging should be useful, centralized and monitored.\n\nIndia's regulatory environment makes this especially relevant. CERT-In's directions require specified cyber incidents to be reported within six hours of noticing or being informed of them, and CERT-In's guidance also emphasizes log management and retention.\n\nThe Digital Personal Data Protection Rules, 2025 also include visibility through logs and monitoring, along with retention of relevant logs and personal data for specified security purposes.\n\nThat means an organization should know before migration:\n\nWhat will we log? \n\nWhere will those logs go? \n\nWho will monitor them? \n\nHow long will they be retained? \n\nCan we investigate an incident from those logs? \n\nA cloud incident should not become a meeting where everyone asks:\n\n\"Who has access to the console?\"\n\nBefore production migration, document the response process.\n\nThe response plan should involve IT, cybersecurity, business owners, legal and management where required.\n\nThis is particularly important because incident response timelines can be short. CERT-In's six-hour reporting requirement and the DPDP framework's breach notification obligations mean organizations need operational readiness, not just policies sitting in a folder.\n\nLarge migrations demonstrate why cloud transformation should begin with understanding the existing environment.\n\nIn a September 2026 account published by Express Computer, Providence India described a healthcare transformation involving 51 hospitals and more than 1,000 clinics, with over 32,000 servers decommissioned, 2,000+ applications retired and 650+ applications migrated to the cloud. The teams emphasized understanding dependencies between applications, identity services, devices and clinical services rather than treating migration as a simple server-movement exercise.\n\nHealthcare is a particularly demanding environment, but the underlying lesson applies across industries:\n\nA workload does not exist in isolation.\n\nIts dependencies are part of the workload.\n\n`How NS3 can help organizations approach cloud migration` \n\nFor an enterprise, cloud migration should not be treated as a one-time infrastructure project. \n\nIt connects IT infrastructure, networking, cybersecurity, business continuity, compliance and ongoing support.\n\nThis is where an experienced technology partner can add value. \n\nNS3's approach should be centered around understanding the existing environment first, then designing the target infrastructure around business requirements.\n\nThat can include:\n\nAssessment \n\nReview the current infrastructure, applications, dependencies, security posture and business requirements. \n\nArchitecture \n\nDesign the appropriate cloud or hybrid architecture based on workload requirements, connectivity, identity, security and resilience. \n\nSecurity \n\nBuild security into the architecture through access controls, network segmentation, endpoint and workload protection, monitoring and governance. \n\nMigration \n\nPlan workload movement in controlled phases with testing, validation and rollback options. \n\nBusiness Continuity \n\nDesign backup, disaster recovery and recovery processes around actual business requirements. \n\nManaged Support \n\nContinue monitoring and supporting the environment after migration instead of treating the project as finished once the workload is live. \n\nFor organizations operating a hybrid environment, this integrated approach is especially important because cloud and on-premises infrastructure will often continue to coexist.\n\nCloud adoption in India is growing quickly. Gartner expects public-cloud spending in the country to reach $17.5 billion in 2026, driven in part by AI infrastructure, modernization and the need for more scalable IT models.\n\nBut growth in cloud adoption does not remove the fundamentals of IT.\n\nBusinesses still need:\n\nThe organizations that benefit most from clouds are not necessarily those that migrate the fastest.\n\nThey are the ones that understand what they are moving, why they are moving it, what could go wrong, and how they will operate the environment after the migration.\n\nFor an IT Head, the right cloud migration question is therefore not:\n\n\"Can we move this workload to the cloud?\"\n\nIt is:\n\n\"Can we move this workload to the cloud while keeping the business secure, compliant, available and financially sustainable?\"\n\nThat is the standard a critical workload should meet before migration.\n\nFollow [Ns3TechSolutions](https://ns3techsolutions.com/) for more information.", "url": "https://wpnews.pro/news/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud", "canonical_source": "https://dev.to/shalu_shrotiya_0fd9a86183/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud-1b5l", "published_at": "2026-09-11 10:13:37+00:00", "updated_at": "2026-09-11 10:33:23.454307+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-policy"], "entities": ["NS3", "Gartner", "Google Cloud", "Mandiant", "CERT-In", "IBM", "AWS", "Microsoft Azure"], "alternates": {"html": "https://wpnews.pro/news/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud", "markdown": "https://wpnews.pro/news/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud.md", "text": "https://wpnews.pro/news/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud.txt", "jsonld": "https://wpnews.pro/news/what-should-an-it-head-check-before-moving-critical-workloads-to-the-cloud.jsonld"}}