Cloud migration and external attack surface: what the data shows about lift-and-shift security debt
Julian ThorneApril 29, 2026
Key takeaways
In 63 Vulnox footprint assessments, organizations that completed a lift-and-shift cloud migration in the prior 18 months showed a 27% average increase in externally exposed attack surface compared to their pre-migration baseline. Finance sector clients showed a 39% increase.
The increase is not caused by the cloud environment being less secure — it is caused by the migration process leaving legacy infrastructure running alongside new cloud assets without decommissioning the old environment on the same timeline.
A regional bank suffered a ransomware attack traced to an abandoned marketing microsite built by a third-party vendor five years prior, running an unpatched file upload vulnerability. The organization had passed a compliance audit weeks before the incident. The microsite was not in scope.
The most dangerous post-migration exposure class is not misconfigured cloud services — it is the on-premises and legacy infrastructure that was supposed to be decommissioned and was not, now running without patching attention because the team assumed it was gone.
Finance sector organizations show higher post-migration attack surface increases than other sectors because compliance-driven change freezes on legacy systems extend the period during which both old and new infrastructure run simultaneously.
One action this week: list every on-premises or legacy system that was scheduled for decommission as part of your last cloud migration. For each one, confirm its current network status from outside — not from internal monitoring, from an external enumeration. Any that are still externally reachable are contributing to the post-migration attack surface increase.
TL;DR
Cloud migration is sold as an attack surface improvement. In practice, the lift-and-shift approach creates a temporary period where both the old environment and the new one are externally reachable simultaneously, and that temporary period frequently becomes permanent for the systems that were hardest to migrate. The attack surface does not shrink when the team finishes deploying to cloud. It shrinks when the legacy infrastructure is decommissioned — which happens later, incompletely, and often not at all for the systems that were already causing operational friction.
The ransomware attack that started on a site nobody remembered
A regional bank suffered a ransomware attack that took down internal systems and customer-facing applications across a three-day weekend. Initial incident response pointed toward a supply chain compromise — the attacker's lateral movement was sophisticated enough that the entry point was not immediately apparent. The root cause, when it was traced, was simpler than anyone expected. An abandoned marketing microsite, built by a third-party vendor five years prior and hosted on a server that the bank's IT team had not touched since the vendor relationship ended, contained a vulnerable file upload form. The server was running an unpatched web framework version with a publicly available exploit. The bank's security team did not know the server existed. It did not appear in their asset inventory. It was not in scope for their vulnerability management program.
The bank had passed a compliance audit six weeks before the incident. The audit reviewed vulnerability management processes, asset inventory completeness, and patch management SLAs — all of which were satisfied for the assets the security team knew about. The microsite was not in the asset inventory, so it was not in the audit scope, so the audit produced no finding about it. The audit confirmed the security posture of the declared scope. The declared scope did not include the asset that enabled the breach. That gap is not an audit failure — it is a consequence of treating asset inventory completeness as an assumption rather than something that requires external verification.
Cloud migration increases external attack surface before it reduces it — and for many organizations, the increase never fully reverses
Common belief
Migrating to cloud reduces external attack surface by replacing unmanaged on-premises infrastructure with managed cloud services that benefit from provider security controls, automatic patching, and centralized configuration management.
What we found
Finance sector clients in the assessment set showed a 39% increase rather than the 27% average, driven by a specific dynamic: regulatory compliance requirements create formal change management processes that slow infrastructure decommissioning. A legacy system under a compliance change freeze cannot be decommissioned until the freeze period ends and a change approval is obtained. During that period, it continues running externally, receiving less patching attention than before the migration because the team's focus has shifted. The compliance process that was designed to protect the organization extends the window of exposure on the infrastructure the organization is trying to retire.
This is true for the workloads that are fully migrated and the legacy infrastructure that is fully decommissioned. The problem is that lift-and-shift migrations are rarely complete in the way the project plan describes. The systems that migrate cleanly are the ones with modern architecture and clear ownership. The systems that do not migrate cleanly — legacy applications with dependencies that do not translate to cloud, infrastructure managed by teams that have since been reorganized, systems under compliance change freezes — remain in the original environment. During the migration, both environments run simultaneously. After the declared migration completion date, the legacy environment continues running for the systems that were not successfully migrated, often without the patching and monitoring attention they received before the migration began, because the team's focus has moved to the new cloud environment.
The net effect is an expanded attack surface: the new cloud environment plus the legacy environment that was supposed to be retired. In 63 Vulnox footprint assessments of organizations in the 18 months post-migration, the average increase in externally exposed attack surface was 27% compared to the pre-migration baseline. The increase was not in the cloud environment — it was in the legacy infrastructure that persisted after the declared migration completion.
Why lift-and-shift migrations generate the specific exposure patterns they do
The attack surface increase from cloud migration is not random — it follows predictable patterns based on how migrations are sequenced and what gets left behind. Understanding the mechanism clarifies where to look for post-migration exposure and why internal monitoring misses it.
The first pattern is decommission lag. Migration projects are scoped and resourced around the build phase: moving workloads to cloud. Decommissioning the old infrastructure is a separate project that is typically lower priority and lower budget because it produces no new capability. In environments where migration took 12 to 18 months, decommissioning often begins after the migration is declared complete and frequently stalls on the systems that were hardest to migrate — which are also the systems most likely to have unpatched vulnerabilities, because their complexity made them candidates for deferral throughout the migration project.
The second pattern is monitoring gap creation. Before migration, legacy infrastructure was within the internal security team's visibility. During and after migration, the team's tooling and monitoring focus shifts to the new cloud environment. The legacy infrastructure that remains running receives less monitoring attention than it did before, because the team does not expect it to be there and because the cloud-native monitoring tools do not cover on-premises systems by default.
The third pattern is shadow cloud creation. During migration, developers and project teams create cloud resources to facilitate the transition — temporary environments, data transfer buckets, integration test infrastructure. These resources are created with migration-phase credentials and permissions, often with broader access than production standards would permit, and are not consistently decommissioned when the migration phase ends.
Example
In one finance sector assessment, we found a migration project that had been declared complete 14 months prior. The declared scope of the migration covered 340 production workloads. Of these, 312 had been successfully migrated and the on-premises versions decommissioned. The remaining 28 workloads were still running on-premises, all of them legacy applications with dependencies that had not been resolved during the migration project. These 28 systems were not in the cloud environment's monitoring scope. They were not in the active patching program because the patching team had been reallocated to cloud operations. They were externally reachable. The most recent patch dates on these systems averaged 16 months prior to our assessment.
External enumeration of post-migration environments consistently finds a pattern that internal monitoring does not: the on-premises IP ranges that hosted pre-migration infrastructure still have live hosts, because decommissioning was incomplete. Certificate transparency logs show certificates issued for subdomains that now resolve to on-premises IP addresses rather than cloud addresses — a signal that the subdomain was migrated but the original server was not decommissioned. Port scanning those IP ranges finds services that the cloud migration project assumed were gone.
What 63 post-migration assessments show
Assessment base: Vulnox assessment data, 2024-2025, 63 digital footprint assessments of organizations in the 18 months following a lift-and-shift cloud migration, across finance, SaaS, healthcare, and logistics sectors
27% average increase in external attack surface post lift-and-shift migration
Across 63 footprint assessments of organizations in the 18 months following a lift-and-shift cloud migration, external attack surface — measured as the count of externally reachable hosts and services — was 27% higher on average than the pre-migration baseline documented at assessment start. The increase was concentrated in two areas: legacy on-premises infrastructure that had not been decommissioned, and shadow cloud resources created during the migration project that had not been cleaned up after migration completion.
The standard expectation entering a cloud migration is that the cloud environment will be more secure than the on-premises environment it replaces. This is often true for the cloud environment itself. The overall external attack surface calculation includes the legacy environment that was supposed to be replaced, and that environment does not shrink on the migration project timeline — it shrinks on the decommissioning project timeline, which is typically slower and less resourced.
Finance sector showed 39% increase versus 27% average
Finance sector organizations in the assessment set showed a 39% post-migration attack surface increase, compared to the 27% average across all sectors. The driver was not more aggressive cloud adoption or less competent security teams — it was the interaction between compliance change management processes and infrastructure decommissioning timelines. Change freezes associated with regulatory examination periods, quarterly reporting cycles, and core banking system maintenance windows extended the period during which legacy infrastructure ran alongside new cloud infrastructure without active patching.
Compliance-driven change management, designed to protect production systems, creates a predictable side effect in migration projects: it extends the window during which legacy infrastructure is externally reachable and below current patch standards. This is a structural consequence of applying change management processes designed for production stability to an infrastructure retirement activity. The processes slow the decommissioning without providing commensurate security benefit for systems that are being retired rather than maintained.
Shadow cloud resources from migration projects persisted in 71% of assessed environments
In 71% of the 63 assessed environments, we found cloud resources — storage buckets, compute instances, IAM roles, or network configurations — that had been created during the migration project and not decommissioned after migration completion. These resources were characterized by migration-phase naming conventions, broader permissions than production standards, and no active ownership assignment. In several cases, migration-phase service accounts with broad cloud permissions had not been rotated or disabled after the migration project closed.
Migration projects create resources at a higher rate than production operations because the build phase requires temporary infrastructure, test environments, and integration scaffolding. The project plan that accounts for deploying these resources rarely accounts for decommissioning them with the same rigor. The result is a class of cloud assets that are broadly permissioned, loosely monitored, and outside the scope of ongoing vulnerability management — which is a description of the assets attackers prefer.
The three post-migration exposure classes that internal monitoring consistently misses
On-premises infrastructure that was declared decommissioned but is still running
Migration project completion reports document the workloads that were successfully migrated. They do not document the status of the on-premises infrastructure that was supposed to be retired. In the absence of a formal decommissioning verification process — which most migration projects do not include — systems that were not fully migrated continue running on-premises without appearing in migration completion documentation. Internal monitoring tools that were reconfigured for the cloud environment stop seeing these systems. External enumeration finds them because they are still reachable.
Subdomains that were migrated in DNS but not in infrastructure
During migration, DNS records for subdomains are updated to point to cloud infrastructure. In some cases, the update was partial: the subdomain DNS record was changed, but the original on-premises server was not decommissioned. Certificate transparency logs show certificates for subdomains that may now have split resolution — cloud infrastructure in some network paths, on-premises infrastructure in others depending on DNS propagation state. The on-premises server, no longer receiving DNS traffic as the primary target, may not be monitored for availability or security.
Third-party and vendor-managed assets outside migration scope
Cloud migration projects are typically scoped to internally managed infrastructure. Assets managed by third parties — marketing microsites, integration endpoints, vendor-hosted portals operating under the organization's domain — are often outside the migration scope because they are not in the organization's direct control. These assets continue operating under pre-migration conditions, including pre-migration patch levels and pre-migration monitoring arrangements, without the security attention that the internally managed assets receive during and after migration.
Post-migration attack surface postures: what the different approaches produce
Lift-and-shift with decommission deferred
The most common approach. Cloud resources are built alongside on-premises infrastructure. Migration is declared complete when the cloud environment is operational. On-premises decommissioning is addressed as a separate project with lower priority and typically lower resourcing. The period between migration completion and decommissioning completion — which averages 9 to 14 months in our assessment data — is the window of maximum attack surface expansion.
Organizations in this posture show the 27% to 39% attack surface increase in our assessment data. The increase is temporary in principle but frequently persists longer than planned because decommissioning stalls on complex dependencies. Security investment in the cloud environment does not reduce exposure from the legacy environment during this window.
Lift-and-shift with parallel decommissioning
Decommissioning is resourced and tracked as part of the migration project, with completion milestones tied to migration milestones. Each workload migration includes a decommissioning verification step before the workload is considered complete. Shadow cloud resource cleanup is included in project scope. This approach requires more project management overhead and typically extends the migration timeline by 15 to 20%.
Attack surface expansion is contained to the active migration period rather than extending into a post-migration decommissioning lag. Net external attack surface at migration completion is closer to or below the pre-migration baseline. Requires explicit scoping decisions and resource allocation that most migration projects do not include by default.
Refactor-first migration with external validation
Application architecture is updated before migration to remove legacy dependencies, reducing the population of systems that cannot be cleanly migrated. External attack surface validation is conducted at migration completion to verify that the declared scope matches the actual external footprint. More expensive and slower than lift-and-shift but produces a cleaner post-migration security posture.
Rarely adopted at full scale due to cost and timeline. Elements of this approach — particularly external validation at migration completion — can be applied selectively to the highest-risk workloads without requiring full architectural refactoring across the migration scope.
Where post-migration attack surface risk is going
Cyber insurance underwriters will add post-migration external attack surface validation as a standard policy condition within two years, requiring organizations to demonstrate external enumeration at migration completion rather than relying on project documentation of decommissioned assets.
Ransomware attacks traced to legacy infrastructure that was supposed to be decommissioned are well-documented in breach disclosures. As insurers analyze breach causation data and correlate it with migration project timelines, the post-migration decommissioning gap will appear as a predictable risk factor. The insurer response to predictable risk factors is to add them to underwriting criteria. The migration completion certificate that satisfies an insurer today will not satisfy the same insurer in two years once the underwriting team understands what 'lift and shift with deferred decommissioning' produces in practice.
Confidence: highReview cyber insurance policy renewal questionnaires from major carriers between 2025 and 2027 for specific questions about cloud migration decommissioning verification and external attack surface validation at migration completion. If these questions do not appear by 2027, the underwriting shift is slower than predicted.AI-assisted external reconnaissance will make legacy infrastructure discovery faster than decommissioning timelines, creating a window where attackers systematically target post-migration on-premises remnants before organizations have closed them.
Automated scanning of IP ranges associated with organizations' historical cloud providers and hosting environments is already possible with current tooling. AI-assisted tooling that correlates certificate transparency logs, historical DNS records, and IP range ownership to identify post-migration on-premises remnants can be built from publicly available data. The decommissioning lag that currently averages 9 to 14 months provides a window that automated attacker tooling will exploit systematically as the tooling matures.
Confidence: mediumLook for threat intelligence reports published between 2025 and 2027 documenting attacker campaigns specifically targeting post-migration legacy infrastructure, identifiable by the correlation between breach entry points and migration project timelines. If no such campaign is publicly documented by 2027, the systematic targeting has not yet emerged at scale.
The migration security claim that vendors and project teams should stop making
The claim that cloud migration improves security posture should be followed by a required qualifier: compared to what, measured how, and at what point in the migration and decommissioning lifecycle. The claim is true for the cloud environment measured against the cloud environment's predecessors, at a point in time after both migration and decommissioning are complete. It is not true during the decommissioning lag period, which is when most post-migration assessments occur. Security teams that inherit the aftermath of a migration project and then present the cloud security improvements to leadership while the legacy infrastructure continues running are presenting an accurate picture of one part of the environment while a more exposed part goes unexamined. The conversation that should happen at migration completion is not 'we are more secure now' — it is 'we will be more secure when decommissioning is complete, and here is the current status of that work.'
Counterargument
The counterargument is that migration projects are already difficult to complete on time and budget, and adding decommissioning verification requirements to migration completion criteria extends timelines and increases costs in ways that may cause organizations to defer migration entirely. If the choice is between a lift-and-shift migration with a decommissioning lag and no migration at all, the lift-and-shift produces better security outcomes in the long run even if the transition period is worse. This is a reasonable argument for completing migrations rather than abandoning them. It does not argue against being honest about the transition period risk, which is where my position holds: the problem is not the migration, it is the security posture claim made before decommissioning is complete.
The post-migration verification that most projects skip
If your organization has completed a cloud migration in the past 18 months, run an external enumeration against the IP ranges and subdomains associated with your pre-migration on-premises environment. Use certificate transparency logs to identify subdomains that received certificates before the migration and check whether they still resolve to on-premises IP addresses. For each on-premises host that is still externally reachable, confirm its decommissioning status and its current patch level. If the host was supposed to be decommissioned and is still running, confirm whether it is in any active monitoring or patching scope. The 27% attack surface increase we see in post-migration assessments is not from the cloud environment — it is from the hosts that were supposed to be gone and are not. That verification takes a day and closes the most predictable gap in post-migration security posture.
Further Reading
Digital Footprint
digital footprint servicesVulnerability Assessment
vulnerability assessment servicesDigital Footprint and Monitoring - ThreatNG
digital footprint monitoring guideExternal Attack Surface Management Recorded Future
external attack surface managementNIST Vulnerability Assessment Definition
NIST vulnerability assessment definition
Frequently Asked Questions
Does cloud migration reduce external attack surface?
Not reliably during the transition period. In 63 Vulnox footprint assessments of organizations in the 18 months following a lift-and-shift cloud migration, external attack surface was 27% higher on average than the pre-migration baseline. The increase came from legacy on-premises infrastructure that was not decommissioned on the same timeline as the migration, and from shadow cloud resources created during the migration project that were not cleaned up after completion.
Why does the finance sector show higher attack surface increases after cloud migration?
Finance sector organizations in Vulnox post-migration assessments showed a 39% external attack surface increase versus the 27% average across all sectors. The driver is compliance-driven change management: regulatory examination periods, quarterly reporting cycles, and core banking system maintenance windows create change freezes that extend the period during which legacy infrastructure runs alongside new cloud infrastructure. The compliance process slows decommissioning without providing security benefit for systems being retired.
What is the typical gap between cloud migration completion and legacy infrastructure decommissioning?
In Vulnox assessment data, the period between declared migration completion and actual decommissioning completion averaged 9 to 14 months. During this period, legacy on-premises infrastructure runs with reduced patching attention — because the security team's focus has shifted to the cloud environment — while remaining externally reachable. This is the window during which post-migration external attack surface is at its highest.
What are shadow cloud resources and why do they persist after migration?
Shadow cloud resources are compute instances, storage buckets, IAM roles, and network configurations created during a migration project to facilitate the transition — temporary environments, data transfer infrastructure, integration test scaffolding. In 71% of Vulnox post-migration assessments, these resources persisted after migration completion with migration-phase permissions (broader than production standards) and no active ownership assignment. Migration projects plan for deploying these resources but rarely include decommissioning them with equivalent rigor.
How did a ransomware attack at a regional bank start from a forgotten marketing microsite?
A third-party vendor built a marketing microsite for the bank five years before the incident. The vendor relationship ended, the microsite was abandoned, and the hosting server was never decommissioned. It continued running an unpatched web framework with a publicly available file upload vulnerability. The server was not in the bank's asset inventory, not in their vulnerability management scope, and not in scope for the compliance audit the bank passed six weeks before the incident. Attackers found it through automated scanning of the bank's IP ranges.
How do you find legacy infrastructure that was supposed to be decommissioned after cloud migration?
External enumeration starting from pre-migration IP ranges and certificate transparency logs. CT logs contain permanent records of every TLS certificate issued for organizational subdomains, including those predating the migration. Checking whether historical subdomains still resolve to on-premises IP addresses identifies servers that were supposed to be retired. Port scanning pre-migration IP ranges finds hosts that internal monitoring no longer covers because the monitoring was reconfigured for the cloud environment. This is the same method attackers use to find post-migration remnants.
What should a cloud migration completion checklist include for external attack surface?
External enumeration at migration completion to verify that declared decommissioned systems are no longer externally reachable. Certificate transparency log review to identify subdomains that still resolve to on-premises addresses. Inventory of shadow cloud resources created during the migration project with a confirmed decommissioning status for each. Verification that migration-phase service accounts and IAM roles with broad permissions have been rotated or disabled. These steps are not standard in most migration project plans and account for the 27% post-migration attack surface increase in Vulnox assessment data.
Related Articles
Basic digital footprint check: what free tools find and what they miss
A basic digital footprint check using free tools takes less than an hour and reliably surfaces subdomains, certificate history, and indexed content. What it misses — assets with no DNS record, credential material in archived repositories, and vendor-created infrastructure — is where the regulatory exposure lives.
SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks
In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name. That gap between what you think you expose and what is actually visible is where most breaches begin.
Digital footprint exposure and data protection risk: what regulators find that internal teams miss
Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.