Cybersecurity in cloud migration: risks and best practices

69% of organizations reported experiencing identity and access security incidents in cloud environments in the previous 12 months, according to the 2026 Fortinet Cloud Security Report. Cloud migration security becomes especially difficult during the transition itself, when data, identities, infrastructure, and access controls may temporarily span on-premises and cloud environments. These eight practices address the gaps that can appear during that window, including shared responsibility, misconfiguration, shadow IT, and emerging AI agent risks.

Best practice 1: What makes the migration window the riskiest phase of the whole project?

The migration window can be one of the most security-sensitive phases of a cloud migration because data, identities, applications, and security controls are changing at the same time across on-premises and cloud environments.

Before migration begins, the organization usually understands its existing infrastructure. After a mature cloud environment is established, teams can build cloud-native controls around a relatively stable architecture.

The difficult period is in between.

During a migration, some workloads may remain on-premises while others have already moved. Data can exist in both locations. Temporary accounts may be created. Network rules may be opened to support transfer processes. Old security tooling may lose visibility before the replacement controls are fully operational.

This creates a migration window in which several types of risk overlap:

• Duplicate data exposure. Copies may exist on-premises, in staging environments, backups, and production cloud storage.
• Identity sprawl. Teams may create temporary users, service accounts, roles, and credentials to keep the migration moving.
• Hybrid visibility gaps. Monitoring tools designed for one environment may not provide complete coverage across both.
• Temporary network access. Migration tooling and integrations can require ports, endpoints, or connectivity that should not remain open afterward.
• Changing ownership. Responsibility can become unclear while infrastructure is being transferred between teams and platforms.

The migration strategy also affects the risk profile.

A rehost, often described as lift-and-shift, moves workloads with relatively limited architectural change. That can shorten the migration itself, but it may bring legacy assumptions and security configurations into the cloud.

A replatform changes selected infrastructure components during the move. This can improve cloud compatibility, but it introduces additional configuration decisions.

A refactor changes the application more substantially to use cloud-native architecture. It can produce a stronger long-term result, but it also creates more moving parts that security teams need to review during migration.

The objective is therefore not simply to secure the final cloud environment. It is to reduce migration-specific complexity, limit unnecessary temporary dependencies and duplicated controls, and define security measures for the period when workloads, data, and responsibilities span multiple environments.

An Agile delivery model that shortens the migration window itself can reduce how long teams operate with temporary architectures and duplicated controls.

Webellian’s cloud infrastructure and security services cover the design, migration, and management of cloud infrastructure, including lift-and-shift projects across platforms such as AWS, Google Cloud, and Microsoft Azure.

Treat the transition as its own security phase. If the security plan only describes the environment before and after migration, it is missing the point where the architecture is changing fastest.

Best practice 2: Do you know exactly where the shared responsibility line sits with your provider?

Cloud providers secure the underlying cloud infrastructure, but your organization remains responsible for critical areas such as data, identities, access policies, and workload configuration. The exact responsibility split varies by service model, cloud provider, individual service, and configuration.

Moving an application to the cloud does not transfer all security responsibility to the cloud provider.

This is the principle behind the shared responsibility model.

In an on-premises environment, an organization typically controls almost every layer. It is responsible for physical servers, networking, operating systems, applications, identities, data, and security controls.

Cloud changes the division of responsibilities, but it does not eliminate them.

With Infrastructure as a Service (IaaS), the provider generally secures the physical infrastructure and underlying cloud platform, while the customer retains substantial responsibility for areas such as operating systems, applications, identities, configurations, and data.

With Platform as a Service (PaaS), the provider typically manages more of the underlying stack, but the customer may still be responsible for application configuration, data, identities, access controls, and other service-specific settings.

With Software as a Service (SaaS), the provider manages most of the application and infrastructure stack, while the customer generally retains responsibility for areas such as account security, access management, data governance, and appropriate configuration and use.

These categories are useful as a starting point, but the exact responsibility split varies by cloud provider, individual service, configuration, and deployment model.

This means cloud migration security should include an explicit responsibility matrix.

Before moving a workload, define:

• who configures identity and access policies;
• who manages encryption keys;
• who patches each layer;
• who monitors security events;
• who responds to incidents;
• who owns backup and recovery;
• who verifies compliance;
• who reviews third-party integrations.

Do not assume the answer is the same for every workload.

A virtual machine running in IaaS creates a very different responsibility split from an application hosted on a managed PaaS platform. The same applies to databases, container platforms, serverless services, and SaaS tools.

The cloud architecture also matters. How the choice between public, private, and hybrid cloud shifts that responsibility split should be part of the migration decision, not something security teams examine after the architecture has been approved.

A practical way to reduce confusion is to document responsibility per service rather than relying on a generic cloud policy.

For each migrated component, teams should be able to answer a simple question: if this control fails tomorrow, does the provider fix it, or do we?

If nobody knows, the responsibility gap is already a security risk.

Best practice 3: Is your data classified and encrypted before it ever leaves your servers?

Data should be classified by sensitivity before migration begins and encrypted both at rest and in transit throughout the move. Otherwise, teams can transfer sensitive information without applying the controls its risk level requires.

Data exposure remains a significant cloud security risk, alongside identity and access weaknesses and cloud misconfiguration.

The mistake often begins before the data reaches the cloud.

If an organization has not classified its information, migration teams may treat customer records, internal documents, regulated data, logs, credentials, and low-risk operational files as though they require the same security controls.

They do not.

A pre-migration data classification process should assign information to clear sensitivity levels, for example:

• public;
• internal;
• confidential;
• restricted or highly sensitive.

Organizations can then apply additional labels for data with specific handling or regulatory requirements, such as personal data, payment data, health information, credentials, or other regulated information.

Encryption then needs to protect the data throughout its journey.

Encryption in transit protects information while it moves between systems. Migration traffic should use encrypted protocols and secure tunnels instead of assuming private connectivity alone is sufficient.

Encryption at rest protects information stored in databases, object storage, disks, backups, snapshots, and other persistent systems.

Organizations should use approved encryption appropriate to their security, regulatory, and operational requirements, together with strong key-management practices. AES-256 is one widely used example for protecting sensitive data, but the effectiveness of encryption also depends on how cryptographic keys are generated, stored, accessed, rotated, and protected.

Migration teams should also review storage configuration carefully. Publicly exposed buckets and overly permissive storage policies are recurring examples of preventable cloud risk.

A strong process should therefore verify:

• encryption before transfer;
• encryption during transfer;
• encryption after arrival;
• access to encryption keys;
• backup encryption;
• storage permissions;
• retention and deletion policies.

For regulated or high-assurance environments, organizations may also require validated cryptographic modules or hardware security modules that meet applicable security and compliance requirements.

These controls should be designed as part of the wider architecture. A broader framework for designing secure, reliable cloud architecture can help teams assess security alongside reliability, performance, cost, and operations.

For organizations migrating primarily to AWS, Webellian also provides AWS-focused migration and security expertise within its broader cloud offering.

Do not wait until migration day to decide which data is sensitive. By then, the first copy may already be moving.

Best practice 4: Are misconfigurations and IAM gaps waiting to be found during your migration?

Misconfigured cloud resources and over-permissioned identities are among the most preventable cloud migration risks, especially when teams recreate on-premises access models without adapting them to cloud-native IAM.

Many cloud incidents do not begin with a sophisticated external exploit.

They begin with a storage resource that was accidentally exposed, an overly broad IAM role, a forgotten service account, or a default configuration nobody reviewed.

Migration makes these errors more likely because teams are operating under time pressure and frequently creating new infrastructure.

Common misconfiguration problems include:

• storage exposed beyond its intended audience;
• default security settings left unchanged;
• unnecessary public endpoints;
• overly permissive firewall or security-group rules;
• administrative interfaces accessible from inappropriate networks;
• logging disabled on new resources;
• temporary migration permissions never removed.

Manual review alone does not scale well enough to catch every error.

This is where infrastructure as code, automated policy checks, and cloud security posture management (CSPM) can help. Instead of relying on someone to notice an unsafe setting after deployment, organizations can test configurations before or immediately after infrastructure is created.

Identity deserves the same level of attention.

The basic principle should be least privilege. A user, service, or workload receives only the permissions necessary to perform its job.

Migration is a particularly dangerous time to ignore this principle because teams often grant broad privileges temporarily to avoid blocking the project.

Temporary permissions have a habit of becoming permanent.

A strong IAM migration process should include:

• centralized identity management where possible;
• multi-factor authentication (MFA) for privileged and sensitive access;
• least-privilege roles;
• separate administrator and everyday accounts;
• short-lived credentials where supported;
• review of service identities;
• regular access recertification;
• immediate removal of migration-only privileges.

A zero-trust approach is useful here. Access should depend on verified identity and explicit authorization rather than assumptions based on network location.

The same logic appears in least-privilege controls applied to remote network access, although cloud migration applies it to workloads, applications, service identities, and infrastructure rather than only employees.

The key lesson is that policies need technical enforcement.

A document saying “follow least privilege” does not stop someone from assigning an administrator role. A deployment policy that rejects over-permissioned infrastructure can.

Cloud migration security improves when access and configuration controls become part of the deployment process rather than a manual cleanup exercise afterward.

Best practice 5: Have you tested your APIs and third-party vendors for migration-specific risk?

APIs and third-party vendors create additional attack paths during cloud migration, and one exposed endpoint or poorly governed external integration can bypass controls protecting the rest of the environment.

Modern cloud migrations rarely involve moving a self-contained application from one server to another.

Applications depend on APIs, identity providers, SaaS tools, payment platforms, data services, monitoring systems, external vendors, and partner integrations.

Every connection extends the migration’s trust boundary.

API risks can include:

• broken authentication;
• weak authorization;
• missing or ineffective rate limits;
• exposed administrative endpoints;
• misconfigured gateways;
• outdated API versions;
• excessive data returned by endpoints;
• insufficient logging.

These risks matter because APIs frequently connect migrated systems to both cloud and on-premises resources during the transition.

The brief’s research references a well-known Optus breach example in which an exposed API endpoint contributed to the compromise of data associated with around 10 million customers. The broader lesson is not specific to one organization. An API can undermine an otherwise well-secured environment if it exposes information without adequate authentication or authorization.

Migration teams should therefore review relevant risks from the OWASP API Security Top 10, test production and temporary endpoints, and confirm that security controls continue to function when traffic paths change.

A managed API layer can make this easier by centralizing access policies, authentication, monitoring, and service exposure. Webellian provides a managed, secured API layer built on AXWAY as part of its cloud integration capabilities.

Third-party vendors require a parallel assessment.

Ask:

• What data can the vendor access?
• Which cloud resources can it reach?
• Does access continue after migration?
• How is vendor activity logged?
• How are credentials issued and revoked?
• What security obligations exist in the contract?
• Can the vendor subcontract access to another provider?
• What happens to data after the relationship ends?

This is especially important when consultants or migration partners receive elevated access during the project.

Temporary third-party credentials should have explicit expiration dates and narrow scopes. Security teams should also monitor vendor activity rather than treating external users as inherently trusted.

Cloud migration expands the number of moving parts. API security and third-party vendor risk need to be assessed as part of the migration architecture, not as separate procurement or application-security exercises.

Best practice 6: Does your compliance plan account for how regulations apply differently in the cloud?

Moving data to the cloud does not remove regulatory obligations. It changes where data is processed, who can access it, which provider controls apply, and how your organization proves compliance.

Compliance frequently becomes more complex during migration because legal obligations intersect with technical architecture.

A workload that was previously hosted in one known data center may now use managed services, backups, replicas, logging systems, or support operations spread across different locations.

This makes data sovereignty and residency important considerations.

For European organizations, GDPR remains particularly relevant. Teams need to understand where personal data is processed, whether transfers leave the European Economic Area, what contractual safeguards apply, and how rights such as access and deletion can still be fulfilled after migration.

Other environments may be subject to frameworks or regulations such as:

• HIPAA for protected health information in relevant US healthcare contexts;
• CCPA for certain personal information concerning California consumers;
• PCI DSS where payment-card data is involved;
• industry-specific security and retention obligations.

The important point is that the cloud provider’s certification does not automatically make your workload compliant.

A provider may operate infrastructure that supports a regulatory framework, while the customer remains responsible for configuring services correctly, restricting access, encrypting data, maintaining logs, and managing retention.

This brings compliance back to the shared responsibility model.

Before selecting the target architecture, conduct a cloud compliance assessment covering:

• data categories and regulatory scope;
• required storage and processing locations;
• encryption requirements;
• identity and access controls;
• audit logging;
• backup and retention rules;
• deletion requirements;
• vendor and subprocessors;
• incident notification responsibilities.

The assessment should happen before migration decisions become difficult to reverse.

For example, an architecture that distributes data across multiple regions may offer resilience advantages but create additional compliance questions. A SaaS platform may reduce infrastructure responsibilities while also limiting the customer’s control over certain technical processes.

That is why the cloud model you choose affects who owns compliance.

Webellian’s cloud infrastructure and security offering includes work in environments subject to requirements such as PCI and HIPAA. The important principle remains the same regardless of provider: compliance should influence cloud architecture from the beginning.

Do not treat regulatory review as a final checklist before go-live. If the architecture violates a residency, retention, or access requirement, discovering that after migration can be extremely expensive.

Best practice 7: Who’s watching your cloud environment after the migration is “done”

Cloud migration security continues after cutover, and the early post-migration period deserves particularly close monitoring because configuration errors, abandoned migration resources, and unexpected usage patterns may become visible only once the new environment is operating under real workloads.

A successful cutover is not the end of the security project.

It is the beginning of the operational phase.

Teams should assume that some assumptions made during migration will prove wrong after real workloads and users begin interacting with the environment. Access patterns change. New resources appear. Temporary infrastructure may remain active. Monitoring starts generating real baselines.

That is why continuous monitoring matters.

Post-migration security should include:

• CSPM to identify cloud configuration weaknesses;
• centralized logging;
• SIEM integration where appropriate;
• vulnerability scanning;
• IAM reviews;
• detection of unused resources and credentials;
• monitoring of network and API activity;
• validation that temporary migration access has been removed.

The first 90 days can be especially important because they provide the first meaningful view of the system under normal operational conditions.

There is also another problem: shadow IT.

Employees and teams can adopt cloud tools, SaaS products, low-code platforms, AI tools, and external services without going through the organization’s normal security process.

According to Gartner, 41% of employees acquired, modified, or created technology outside IT’s visibility in 2022, and the company predicts that this figure will reach 75% by 2027.

Whether or not every organization sees the same level of usage, the direction is clear. Cloud adoption makes it easier for teams to introduce new technology without central infrastructure teams provisioning it.

This creates visibility gaps.

Security teams should therefore maintain an inventory of cloud services and combine it with network, identity, expense, and endpoint information where appropriate to identify unmanaged tools.

Continuous monitoring should answer questions such as:

• Which cloud services are actually in use?
• Which resources have no identified owner?
• Which accounts have not been used recently?
• Which workloads changed configuration?
• Which systems are accessible from the public internet?
• Which new applications are handling company data?
• Are old migration tools still connected?

Cloud security posture management helps identify technical drift. Governance processes are still needed to address organizational drift.

The environment on day 90 will not look exactly like the architecture diagram approved before migration. Good cloud migration security assumes change and keeps watching for it.

Best practice 8: Are AI agents provisioning or attacking your cloud environment faster than you can review it?

AI agents and copilots introduce a new cloud migration risk because they can create infrastructure, replicate configuration mistakes, and accelerate reconnaissance much faster than a human operator working manually.

This is one area where cloud migration security in 2026 differs materially from older migration playbooks.

AI-assisted infrastructure tooling can help engineering teams work faster. Developers can generate infrastructure-as-code templates, troubleshoot deployment problems, propose IAM policies, and automate repetitive provisioning tasks.

The same speed creates risk.

Consider an AI agent that generates an infrastructure as code (IaC) configuration containing an overly permissive network rule.

If a human creates one resource manually, the mistake affects one resource.

If an automated workflow replicates the same configuration across dozens of accounts, regions, or environments, the mistake scales immediately.

That creates the first risk: automated misconfiguration.

Organizations should treat AI-generated infrastructure changes like production code.

That means:

• use version control;
• require review for sensitive changes;
• validate IaC automatically;
• run security policy checks before deployment;
• limit what the AI agent is authorized to provision;
• maintain logs of agent-generated changes;
• use approval gates for privileged operations.

Prompts and natural-language instructions should not be treated as a substitute for engineering controls.

If an agent can create infrastructure, it should have an explicit identity and a tightly restricted permission scope.

The second risk comes from attackers.

AI can also accelerate automated reconnaissance. Instead of manually checking endpoints, buckets, services, and exposed systems one by one, attackers can automate large parts of discovery and triage.

That is particularly concerning during the migration window, when teams may temporarily expose services or create infrastructure that has not yet reached the final security baseline.

A configuration error that remains visible for several hours can be discovered far faster than teams might expect.

This reinforces an older security principle: build security in from the start instead of bolting it on afterward.

That principle now applies not only to applications and infrastructure but also to the agents creating and managing them.

The increased speed and scale of AI-assisted reconnaissance reinforce the need to assume that exposed services and configuration mistakes may be discovered quickly during migration.

The correct response is not to avoid AI-assisted infrastructure management. It is to apply normal production controls to it.

An AI agent with cloud privileges should be treated as a privileged machine identity, not as a convenient assistant operating outside the security model.

FAQ

What are the top 3 cloud security risks?

Three of the most important cloud security risks are data exposure, misconfiguration, and weak identity and access management.

Data can be exposed through insecure transfers, public storage, excessive permissions, or poor encryption. Misconfigurations can unintentionally make resources accessible or disable required security controls. IAM failures can give users, workloads, or third parties more access than they need.

During migration, these risks often overlap because data, infrastructure, and identities are changing at the same time.

What are the five pillars of cloud security?

There is no single universal framework used by every provider, but a practical cloud security model can be organized around five areas:

1. Identity and access management, including least privilege and MFA.
2. Data protection, including classification, encryption, backup, and retention.
3. Infrastructure and workload security, including secure configuration and vulnerability management.
4. Visibility and monitoring, including logging, CSPM, detection, and incident response.
5. Governance and compliance, including policies, ownership, regulatory requirements, and continuous review.

These pillars need to operate together. Strong encryption, for example, cannot compensate for an administrator account with excessive access.

What are the 7 R’s of cloud migration?

The 7 R’s of cloud migration are commonly used to describe different strategies for moving or changing applications:

1. Rehost, moving the application largely as it is.
2. Replatform, making selected changes to benefit from cloud capabilities.
3. Refactor, redesigning the application more substantially.
4. Repurchase, replacing the existing system with another product, often SaaS.
5. Relocate, moving workloads with minimal application change at the infrastructure level.
6. Retain, keeping selected applications in their current environment.
7. Retire, decommissioning applications that are no longer needed.

The chosen strategy affects cloud migration security. A rehost can preserve legacy weaknesses, while a refactor creates more architectural change that needs security review.

What are the five phases of cloud migration?

Cloud migration is often organized into five broad phases:

1. Assessment, where applications, dependencies, data, risks, and requirements are identified.
2. Planning, where the target architecture, migration strategy, security controls, and responsibilities are defined.
3. Migration, where data and workloads are transferred or rebuilt.
4. Validation, where functionality, security, performance, compliance, and recovery are tested.
5. Optimization and operations, where monitoring, cost, security posture, access, and architecture are continuously improved.

Security should be present in all five phases. Treating it as a validation task at the end leaves the riskiest part of the migration insufficiently protected.

Sources: