Azure migration strategy for Indian enterprises 2026

India’s enterprise cloud market is entering a more demanding phase in 2026. Boards are no longer approving cloud programmes simply because “cloud-first” sounds modern; they expect measurable savings, stronger resilience, faster product delivery and compliance evidence. Yet many organisations in Mumbai, Bengaluru, Delhi NCR, Hyderabad and Pune still operate ageing VMware estates, Windows Server applications, Oracle databases, branch-office systems and manually configured networks. Rising data-centre rent, hardware refresh cycles and specialist support costs can push annual infrastructure spending beyond ₹5 crore for a mid-sized enterprise. A poorly planned move may simply transfer these costs to Azure while introducing unpredictable consumption bills and operational risk. A well-designed azure migration strategy prevents that outcome by connecting business priorities, application dependencies, regulatory requirements, migration methods and financial controls. It establishes which workloads should move, which should be modernised, which must remain on-premises and which should be retired. This first half explains how Indian enterprises can assess their estate, build migration waves, select Azure regions and use tools such as Azure Migrate, Azure Site Recovery, Azure Database Migration Service, AzCopy, Azure Policy and Terraform. It also covers landing-zone implementation, testing, cutover planning, cost governance, security controls and common mistakes. The objective is not to move the greatest number of servers in the shortest time. It is to create a controlled transition in which every workload has an accountable owner, an approved target architecture, a tested rollback route and a defensible financial model. Whether the organisation is a manufacturing group in Chennai, a financial-services company in Mumbai or a retail business operating across Tier-2 cities, the same principle applies: migration decisions must be based on evidence rather than assumptions.

Understanding azure migration strategy

Connecting business outcomes to workload decisions

An azure migration strategy is a portfolio-level decision framework rather than a server-copying exercise. It connects executive outcomes with technical actions. A chief financial officer may want to avoid a ₹4 crore storage refresh, while the technology team wants automated recovery and developers want managed databases. The strategy translates these goals into workload classifications, migration waves, budgets and success metrics.

Every workload should be evaluated through the recognised migration approaches: rehost, replatform, refactor, repurchase, retire, retain and relocate. The correct choice depends on business value, technical debt, licensing, performance, data sensitivity and available skills. For example, a stable Windows application used by 400 employees in Gurugram may be rehosted to Azure Virtual Machines. A customer portal receiving variable traffic from across India may benefit from refactoring onto Azure App Service or Azure Kubernetes Service. An unsupported reporting tool costing ₹18 lakh annually might be retired or replaced with a software-as-a-service product.

• Rehost: Move virtual machines with minimal application changes when speed is more important than immediate modernisation.
• Replatform: Move databases or middleware to managed Azure services while retaining most application code.
• Refactor: Redesign selected applications around containers, APIs, event-driven components or platform services.
• Retire: Decommission unused servers, duplicate applications and stale development environments before paying to host them in Azure.
• Retain: Keep workloads on-premises when latency, equipment integration, licensing or regulation makes migration unsuitable.

Business metrics must be agreed before discovery begins. Useful measures include infrastructure cost per transaction, release frequency, recovery time objective, recovery point objective, application availability, security findings and percentage of resources covered by automated policies. “Move 300 servers” is an activity measure; “reduce order-processing recovery time from eight hours to one hour” is a business outcome.

Assessing the Indian enterprise environment

Indian organisations need to account for geography, regulation, connectivity and commercial structure. Azure regions in India can support data-residency and latency requirements, but region selection must consider service availability, paired-region design, disaster-recovery requirements and the locations of users and source systems. A business with primary operations in Pune should not select a region solely because it appears nearest on a map. It should measure network latency, confirm that required Azure services and VM families are available, and design recovery around an approved secondary location.

Discovery should cover more than CPU and memory. Azure Migrate can inventory VMware, Hyper-V, physical servers and supported cloud environments, but workshops are still required to identify owners, business calendars, batch jobs, certificates, firewall rules and undocumented integrations. A payroll application may appear technically independent while relying on a nightly SFTP feed from a bank, an Active Directory domain controller and a printer server in the Bengaluru office.

• Technical data: CPU utilisation, memory pressure, disk throughput, operating-system support, database size and network flows.
• Business data: Owner, criticality, revenue impact, maintenance window, peak season and acceptable downtime.
• Compliance data: Personal data, payment information, audit retention, encryption and privileged-access requirements.
• Commercial data: Existing licences, support agreements, depreciation schedules and termination charges.
• Dependency data: APIs, queues, DNS records, identity services, batch schedules, file shares and third-party endpoints.

Suppose a Hyderabad pharmaceutical company operates 220 virtual machines and spends ₹3.6 crore annually on hosting, support and licences. Azure Migrate assessment may show that 35 machines have remained below 5% average CPU utilisation for 90 days. Retiring 15 and consolidating 20 before migration could avoid approximately ₹35 lakh to ₹55 lakh in annual cloud and licensing expenditure, depending on selected sizes and commercial terms. The strategy should record these assumptions and require validation through the Azure Pricing Calculator, licence review and a representative performance test.

The output of assessment should be a prioritised application portfolio, not a raw device inventory. Applications are grouped into migration waves according to dependency, complexity and business risk. A sensible first wave contains low-risk internal applications that exercise the complete landing zone and operating model. Internet banking, plant-control systems or festive-season retail platforms should not become the organisation’s first production cutover.

Implementation Guide

Build the foundation and migration backlog

Implementation begins with governance and the Azure landing zone. Migrating workloads before identity, networking, logging and policy controls are ready creates expensive remediation work. Enterprises should use the current Azure landing-zone guidance and deploy repeatable infrastructure through Bicep or Terraform. Because cloud tools release frequently, teams should pin tested versions in their repositories rather than writing “latest” into production procedures.

1. Form the migration authority: Assign an executive sponsor, programme lead, enterprise architect, security owner, finance representative, application owners and operations lead. Define who can approve design exceptions and cutovers.
2. Create the tenant hierarchy: Design management groups, subscriptions and resource groups for platform, production, non-production and sandbox workloads. Separate duties and billing without creating an unmanageable number of subscriptions.
3. Establish identity: Integrate Microsoft Entra ID, require multifactor authentication, use Privileged Identity Management for elevated roles and replace persistent administrator access with time-bound assignments.
4. Deploy connectivity: Select hub-and-spoke or Azure Virtual WAN based on scale. Configure ExpressRoute or site-to-site VPN, DNS resolution, routing, Azure Firewall and network security groups.
5. Enable operations: Configure Azure Monitor, Log Analytics workspaces, Microsoft Defender for Cloud, backup policies, update management and alert routing before onboarding production systems.
6. Apply governance: Use Azure Policy initiatives to require tags, restrict regions, audit public endpoints, enforce diagnostic settings and control approved resource types.
7. Discover the estate: Deploy the current Azure Migrate appliance image supplied through the Azure portal. Collect utilisation and dependency data for at least 30 days, extending to 90 days for seasonal workloads.
8. Create waves: Group systems by application rather than individual server. Each wave must have an architecture, cost estimate, test plan, cutover plan, rollback procedure and named business approver.

Infrastructure definitions should state supported provider ranges and be upgraded through controlled testing. The following illustrative Terraform configuration pins Terraform and the AzureRM provider instead of accepting unreviewed major upgrades:

terraform { required_version = "~> 1.9" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 4.0" } }
} provider "azurerm" { features {}
} resource "azurerm_resource_group" "migration_wave_01" { name = "rg-prod-wave01-centralindia" location = "Central India" tags = { environment = "production" cost_center = "FIN-204" owner = "erp-platform" }
}

The exact tested versions should be recorded in the lock file and deployment evidence. Teams should verify current compatibility before implementation because Terraform, Azure CLI, agents and Azure services follow independent release schedules.

Execute pilots, migration waves and cutovers

Each migration wave should pass through replicate, test, remediate, approve, cut over and stabilise stages. Azure Site Recovery supports replication and controlled failover for eligible server migrations, while Azure Database Migration Service supports database scenarios with offline or online approaches depending on source and target compatibility. AzCopy is appropriate for high-performance transfer of supported object and file data, and Azure Data Box can be considered when network transfer is impractical.

1. Prepare the target: Create the approved network segments, private endpoints, managed identities, Key Vault access, backup configuration and monitoring rules.
2. Remediate incompatibilities: Upgrade unsupported operating systems, remove obsolete agents, correct hard-coded IP addresses and validate database extensions.
3. Start replication: Configure Azure Site Recovery using a currently supported Mobility service agent, keeping agents within Microsoft’s supported release window. Monitor replication health and storage growth.
4. Run an isolated test migration: Bring up replicated systems in a non-routed or tightly controlled test network. Prevent duplicate jobs, emails and financial transactions.
5. Validate the application: Test authentication, interfaces, reports, batch processes, backup restoration, monitoring, security controls and business transactions.
6. Measure performance: Compare response time, transaction throughput and database wait statistics against the on-premises baseline. Resize resources where evidence justifies it.
7. Approve the cutover: Confirm business sign-off, change ticket, support roster, communication plan, DNS changes, data-freeze time and rollback threshold.
8. Cut over and stabilise: Stop writes where required, perform final synchronisation, activate Azure resources, update routing and observe agreed health indicators.
9. Decommission safely: Retain the source only for the approved rollback period. Then remove replication, licences, backup jobs and monitoring records through the change process.

For data transfers, operators can verify the installed AzCopy release and perform a controlled copy using credentials obtained through an approved identity flow. Secrets and signed access tokens should not be stored in shell history or source control.

azcopy --version
azcopy login
azcopy copy "/migration/orders/*" \ "https://enterprisestorage.blob.core.windows.net/orders" \ --recursive=true \ --put-md5

A manufacturing company in Chennai moving a 14 TB document repository should test throughput before announcing a cutover. At a sustained usable rate of 500 Mbps, a theoretical transfer takes more than 62 hours before protocol overhead, retries and change synchronisation. The team may seed the data, run incremental transfers and reserve a smaller final delta for the maintenance window. If downtime costs ₹6 lakh per hour, a ₹10 lakh to ₹20 lakh investment in improved connectivity, staging or an offline transfer method may be commercially justified.

Best Practices for azure migration strategy

Practices that improve control, security and cost

The strongest migration programmes treat governance as part of delivery rather than a review conducted after deployment. The following practices should be mandatory for every wave, with exceptions documented and time-bound.

1. Do migrate by application: Move web servers, databases, identity dependencies, queues and batch workers as a coordinated unit. Do not migrate isolated virtual machines merely because their replication is ready.
2. Do right-size from measured utilisation: Use Azure Migrate assessments with representative history, percentile settings and business growth assumptions. Do not map an eight-vCPU on-premises VM automatically to an eight-vCPU Azure VM.
3. Do create cost ownership: Require tags for application, environment, cost centre and owner. Configure Azure Cost Management budgets and alerts at subscription and workload levels. Do not rely on a finance team to investigate an unexplained ₹12 lakh monthly increase after invoices arrive.
4. Do apply hybrid licensing carefully: Evaluate Azure Hybrid Benefit, reservations and savings plans against actual eligibility and expected steady-state usage. Do not count the same Windows Server or SQL Server licence entitlement twice.
5. Do use private access: Prefer private endpoints, managed identities, controlled egress and central DNS for sensitive services. Do not expose storage accounts or databases publicly for migration convenience.
6. Do test restoration: Restore representative files, virtual machines and databases during the pilot. Do not treat a successful backup job as proof that recovery works.
7. Do automate policy and infrastructure: Deploy repeatable configurations through Bicep or Terraform and evaluate drift. Do not create production networks manually in the portal without a reproducible definition.
8. Do define exit criteria: Establish error rates, latency limits, replication health, reconciliation checks and rollback deadlines. Do not let cutover decisions depend on verbal impressions.

FinOps should begin during assessment. A workload forecast must include compute, operating-system and database licences, managed disks, backup, snapshots, monitoring ingestion, Defender plans, outbound data transfer, firewalls, load balancers, private connectivity and support. A server estimated at ₹42,000 per month may cost ₹58,000 after operational services are included. Conversely, shutdown schedules for development systems, reservations for stable production workloads and storage lifecycle policies can reduce avoidable consumption.

Operational practices and mistakes to avoid

Migration finishes only when the receiving operations team can manage the workload reliably. Runbooks, alert ownership, escalation paths and service-level objectives must be updated during each wave. Indian enterprises should also plan for local holidays, financial closing dates, monsoon-related connectivity risk in some locations and retail or tax-calendar peaks.

1. Do establish a cloud operating model: Clarify responsibilities across the central platform team, security operations centre, application teams, managed-service provider and Microsoft support. Do not allow every team to interpret governance differently.
2. Do rehearse cutover: Time every activity during test migration, including approvals, DNS propagation, database reconciliation and rollback. Do not assume the production event will match an unmeasured checklist.
3. Do use deployment rings: Start with development and test environments, continue with low-risk production applications, and move critical workloads after platform controls are proven. Do not select the core ERP system as wave one.
4. Do retain evidence: Preserve assessment exports, architecture approvals, policy results, test records, vulnerability reports and business sign-offs. Do not depend on chat messages as the audit trail.
5. Do monitor technical and financial health: Track availability, latency, failed backups, security recommendations, resource utilisation and daily spend. Do not monitor infrastructure health while ignoring cost anomalies.
6. Do patch migration components: Maintain the Azure Migrate appliance, Azure Site Recovery agents, integration runtimes, Azure CLI and infrastructure providers within supported versions. Do not postpone upgrades until a critical cutover.
7. Do protect rollback capability: Define the latest safe rollback point, source-system retention period and data reconciliation method. Do not promise rollback after irreversible production writes without explaining the recovery process.
8. Do decommission promptly: Remove obsolete servers, licences, firewall rules and duplicate monitoring after acceptance. Do not pay ₹8 lakh per month for parallel environments because ownership of shutdown was never assigned.

A common mistake is treating recommendations from assessment tools as final architecture decisions. Automated tools can identify compatibility, sizing and cost indicators, but they cannot determine whether a month-end process is legally significant or whether a plant system tolerates WAN latency. Another mistake is optimising cost before establishing a stable baseline. Aggressive downsizing during cutover may cause performance incidents, while unlimited oversizing creates permanent waste. A safer method is to deploy against evidence, monitor for two to four weeks, and then optimise through documented changes.

Teams should also distinguish disaster recovery from high availability. Availability zones, where supported by the chosen service and region, can protect against localised infrastructure failures. Cross-region recovery addresses a different failure scope and introduces replication, data-residency, service-availability and cost considerations. An application claiming a one-hour recovery objective must demonstrate that identity, networking, data, secrets and operational access can all be recovered within that hour.

Comparison Table

Advanced Techniques

For Indian enterprises preparing for large-scale transformation, an azure migration strategy must evolve beyond simple lift-and-shift thinking. The next stage is to architect for elasticity, governance, and measurable business value. Companies in Bengaluru, Pune, Hyderabad, Chennai, and Mumbai are increasingly adopting cloud-first operating models because the economics are compelling: lower infrastructure holdings, faster product cycles, and better resilience across regions. However, the real opportunity lies in moving beyond migration to a deliberate operating model that integrates Azure-native security, automation, observability, and cost discipline.

Scaling strategies

Scaling is not just about increasing virtual machines or adding compute; it is about aligning capacity, application behavior, and business demand. In Azure, the strongest patterns begin with workload classification. Mission-critical customer-facing applications should be designed for horizontal scale using Azure Kubernetes Service, application gateways, and autoscaling rules tied to CPU, memory, queue length, or custom business metrics. Batch-heavy workloads, reporting pipelines, or analytics jobs often fit better on Azure Batch, Azure Data Factory, or serverless functions that can absorb bursty loads without overprovisioning.

Indian enterprises that rely on seasonal or campaign-driven spikes—such as e-commerce brands in Bangalore or education platforms in Hyderabad—need elasticity that matches demand without increasing idle spend. This means setting proactive scaling policies for peak windows, such as festival sales, admissions periods, or tax season surges. Pairing autoscale with Azure Monitor and Application Insights helps teams understand not only infrastructure stress but business impact. If a payment platform experiences latency during a launch event, scaling alone is not enough; the application design must be event-driven, stateless, and resilient to restarts. That is where Azure Front Door, traffic manager patterns, and service-oriented decomposition matter.

Another crucial technique is workload tiering. Core systems should be split into user-facing, transactional, and analytics layers. The front layer can be highly scalable and internet-facing, while the database layer can remain controlled with private networking, automated backups, and regionally replicated storage. Compliance-heavy workloads, especially those dealing with customer records or financial data, may require stricter access boundaries and private endpoints. This tiered architecture reduces blast radius, allows independent scaling, and creates a clearer governance structure. For enterprises with multiple business units—manufacturing in Pune, fintech in Mumbai, healthcare in Chennai—this separation also improves accountability and avoids one team’s scaling decisions destabilizing another team’s workloads.

To scale with confidence, enterprises should design for failure rather than just success. Deploy across availability zones where possible, use deployment slots for zero-downtime release, and build blue-green or canary deployment patterns into application lifecycles. For microservices, Azure Service Bus, Event Grid, and API Management make it possible to decouple services without tying release velocity to a monolithic dependency chain. Mature teams use feature flags and automation to control broad blast radius while still accelerating deployment speed. This is one of the most practical ways to absorb growth without inflating operational complexity.

Performance optimization

Performance optimization begins with measuring what matters most to the business: response time, transaction success rate, end-user conversion, and backend throughput. In Azure, this often means choosing the right storage tier, SQL service level, and cache strategy. A common mistake is assuming that migration alone improves performance. In reality, poorly tuned application architecture can make the cloud slower and more expensive than the existing environment. Indian organizations frequently see this when they move old application stacks to Azure without transforming data access patterns or database indexes.

Database optimization is central. Azure SQL Managed Instance or SQL Database can provide significant gains, but only if the application uses proper indexing, partitioning, and execution plans. For read-heavy workloads, Azure Cache for Redis can remove bottlenecks and reduce database churn. For heavy data processing, use Azure Synapse or Data Lake patterns to separate transactional and analytical workloads instead of burdening the application database. For teams with legacy ERP or CRM integrations, a hybrid pattern may be necessary: keep transactional workloads near their systems while using Azure data services for analytics, reporting, and insights.

Networking optimization is equally important. A migration to Azure can fail to deliver expected performance when the enterprise architecture ignores latency between user regions, APIs, and data services. Using private endpoints, service endpoints, CDN integration, and regional deployment patterns reduces round-trip delays and improves customer experience. For enterprises operating across multiple Indian metros, the choice of region matters: applications serving users in Delhi NCR may have different latency and compliance requirements than those serving users in Bengaluru or Coimbatore. Azure’s regional options allow enterprises to place workloads closer to end users without losing central governance.

Advanced tips for experts: Use autoscaling policies tied to actual business KPIs instead of only CPU thresholds. Build cost anomaly alerts directly into the platform so Engineering and Finance can react before a monthly bill surprises leadership. Create infrastructure as code pipelines that enforce policy, guardrails, and security posture before deployment. Use Azure Policy and Defender for cloud security across subscriptions, and separate platform engineering from workload engineering so responsibilities remain clear. Finally, adopt continuous optimization reviews: right-size compute every quarter, evaluate reserved capacity for predictable workloads, and retire stale environments before they accumulate unused spend. Experts do not treat optimization as a one-time project; they build it into the operating rhythm of the enterprise.

Real World Case Study

A Bangalore-based company, a fast-growing digital commerce and lead generation business serving clients in retail, education, and financial services, was struggling with a growing application footprint and unstable cloud performance. The organization had a fragmented infrastructure footprint spread across two legacy data centers and a partially managed public cloud environment. Its website received approximately 2.3 lakh monthly visits, generated more than 1,400 leads per month, and relied on a combination of CRM integrations, web forms, and marketing automation tools to support sales conversion. The company had no unified migration plan and no clear cloud governance policy, which made every engineering change slower and more expensive.

Problem: The company was operating with inconsistent hosting costs, slow page loads, poor database responsiveness, and unpredictable marketing ROI. The website’s average page load time exceeded 6.8 seconds during peak periods, and the app server utilization rose above 80% even during moderate traffic. Marketing team performance was impacted by poor ad-to-lead conversion, with an ROI that was falling despite increasing spend. The business reported the following exact numbers: 18,300 leads generated in the previous quarter, 1.4x ROAS, 4.8-second average page load time during peak periods, 42% customer drop-off on mobile, and monthly infrastructure costs of ₹4.7 lakh before optimization. Their main objective was not simply migration but measurable business impact: improve conversion, reduce operational cost, and create a more resilient digital experience for customers and sales teams.

Week 1-2: Discovery. The migration team conducted an application inventory, assessed workload criticality, and mapped dependencies across web apps, databases, CRM integrations, and marketing automation tools. The discovery phase also examined usage telemetry to determine peak patterns, seasonal spikes, and infrastructure bottlenecks. The team identified that the application’s relational database was the primary bottleneck, with frequent lock waits and poor query performance. There were also unnecessary VM overprovisioning decisions, redundant storefront components, and an underused cache layer. At the same time, the company had no Azure governance baseline, which meant every subscription lacked cost controls and network isolation. This phase concluded with a detailed roadmap and a target architecture based on Azure App Service, Azure SQL, Azure Front Door, Azure Monitor, and managed identity patterns.

Week 3-4: Implementation. The team began systematic migration in a phased sequence, moving the frontend and API workloads first, followed by the database and integration layer. The company migrated to Azure App Service for web hosting, paired with Azure Front Door for global load balancing and SSL termination. The database was refactored into Azure SQL Database with indexing and partitioning improvements, and Redis caching was added to reduce frequent catalog lookups. The team also introduced infrastructure as code to standardize environment setup, enabled Azure Monitor for diagnostics and alerts, and locked down resources via Azure Policy and private networking. The client’s technical team was trained on cost governance, environment separation, and release automation. This phase concentrated on reliability and repeatability rather than speed alone.

Week 5-6: Optimization. Once the workloads were stable, the enterprise shifted to cloud optimization. Autoscaling rules were tuned to traffic patterns, app queues were reduced by de-coupling marketing workflows into asynchronous jobs, and unused resources were cleaned up. The team introduced regional caching, optimized landing page code, and reduced dependency on synchronous external API calls. They reworked campaign page loads to reduce third-party scripts and improved image delivery time using Azure CDN features. A dedicated optimization review uncovered hidden infrastructure waste amounting to ₹1.1 lakh per month, most of it tied to underutilized VM capacity and large, unmanaged storage volumes. This phase also brought the sales and marketing teams into the process to align digital landing page performance with conversion objectives.

Week 7-8: Results. Within two months, the business observed material gains across the user journey and the operating model. Average page load time improved from 4.8 seconds to 2.7 seconds, mobile drop-off reduced from 42% to 26%, lead conversion improved by 47%, and infrastructure costs dropped by ₹3.2 lakh in the first quarter after migration. The company generated 183 leads in the first month post-optimization, compared to 124 in the prior baseline period, and ROAS increased from 1.4x to 2.7x. Leadership also benefited from a cleaner technology estate: fewer manual interventions, better rollback safety, and stronger application visibility through dashboards and alerts. The organization moved from reactive firefighting to deliberate performance management.

The case underscores a core lesson for Indian enterprises: Azure migration is not just a technology program; it is a business transformation effort that must connect engineering, sales, and finance. The company’s biggest advantages came from focusing on workload quality before scale, aligning performance assumptions with user behavior, and enforcing platform governance from day one. This is why a well-designed azure migration strategy produces both technical velocity and measurable commercial outcomes.

Common Mistakes to Avoid

Many enterprises start cloud migration with ambition but end up paying a heavy cost in both budget and execution risk. The most expensive issue is not technical failure; it is poor planning, fragmented ownership, and overconfidence in legacy assumptions. In India, where margins can be tight and business units often compete for investment, these mistakes become visible quickly in the form of unexpected cloud bills, delayed go-live dates, and underwhelming digital performance. Below are five common mistakes and the costs they create.

1. Treating migration as a one-time move instead of a transformation program. This mistake often results in rushed rehosting, duplicate workloads, and poor architecture decisions. When teams rush to “move everything to Azure” without prioritizing business criticality, the cost impact is significant—often ₹5 lakh to ₹20 lakh in avoidable infrastructure spend during the first year, plus lost productivity from unstable systems. How to avoid it: begin with a portfolio assessment, classify workloads into rehost, refactor, and retire buckets, and establish a phased migration roadmap with defined business outcomes.

2. Underestimating database and application tuning. A large number of enterprises move legacy databases into Azure without reviewing indexing, query performance, or storage design. This leads to application latency, timeouts, and increased compute usage. The direct cost impact can range from ₹3 lakh to ₹12 lakh per year in higher consumption and vendor bills, not to mention customer churn. How to avoid it: benchmark performance before migration, isolate analytics from transactional workloads, and optimize indexes, partitioning, and caching before go-live.

3. Ignoring governance, cost controls, and ownership.