Cloud Migration Playbook for Malaysian SMEs — From Assessment to Landing Zone in 90 Days

Something shifted in the Malaysian cloud landscape in May 2025. Microsoft cut the ribbon on Azure Malaysia West — the country's first Azure region, AI-ready hyperscale infrastructure with three availability zones, located in Greater Kuala Lumpur. It removed the single biggest excuse for keeping workloads on-premise: data residency. A second region, Southeast Asia 3, is already planned for Johor Bahru. Suddenly, the question from Malaysian boards wasn't "where will my data live?" but "why haven't we started?"

A year later, I still see the same pattern across the SMEs I work with. Everyone agrees cloud migration makes sense. The budget is approved. But teams stay stuck in an endless assessment loop — collecting inventory spreadsheets, running Azure Migrate assessments that sit in dashboards nobody opens, debating migration strategy in meetings that produce no action. Meanwhile, system integrators are building dedicated Azure migration practices, and Malaysia West is filling up with enterprise workloads from organisations that figured out how to execute.

The gap isn't knowledge. It's execution. So here's the playbook I've refined across a dozen Malaysian SME migrations: a concrete 90-day sprint from "we should move to Azure" to "we have a production landing zone with workloads running." Real commands, real timelines, and realistic costs in MYR.

Why Malaysian SMEs Are Moving Now

Malaysia's cloud adoption accelerated sharply after Malaysia West went live. The drivers:

• PDPA compliance — the Personal Data Protection (Amendment) Act 2024 came into force in phases from 1 January 2025, with data breach notification and DPO appointment obligations effective 1 June 2025. Data sovereignty matters, and Malaysia West provides it.
• Government cloud direction — MyDigital and the public sector's cloud-first push are pulling GLCs and their supply chains toward cloud.
• Talent availability — Azure-skilled architects are no longer unicorns in KL. Cognizant, HCL, and local SIs have stood up migration practices.
• Cost pressure — MYR weakness makes hardware procurement expensive. OpEx cloud models look genuinely attractive when your CapEx cycle means 18 months of PO approvals.

The technology, the talent, and the business case have aligned. But only if you execute within a reasonable timeframe. Ninety days is enough — if you follow a structured playbook.

Phase 1: Assessment & Discovery (Days 1–21)

Week 1: Inventory with Azure Migrate

Stop with the spreadsheet. Deploy the Azure Migrate appliance on your VMware or Hyper-V host — Microsoft provides a scripted deployment — and let discovery populate your project automatically. Once discovery is running, verify what the appliance is reporting:

# Verify servers discovered by your Azure Migrate project
# (az migrate is a CLI extension; it installs automatically on first use)
az migrate get-discovered-server \
    --project-name migrate-my \
    --resource-group rg-migration \
    --source-machine-type HyperV \
    --output table

Assessment itself is run from the Azure Migrate hub in the portal — discovery populates the inventory, and you create an assessment against a server group right there. If you want repeatable, versioned assessments, drive the same engine programmatically through the Azure Migrate AssessmentProjects REST API (the Az.Migrate PowerShell module covers replication and migration; assessments are exposed via REST):

# Create an assessment via the Azure Migrate REST API (api-version 2023-03-15)
az rest --method put \
    --url "/subscriptions/{sub-id}/resourceGroups/rg-migration/providers/Microsoft.Migrate/assessmentProjects/migrate-my/groups/production-workloads/assessments/day21-prod-assessment?api-version=2023-03-15" \
    --body '{
      "properties": {
        "azureLocation": "malaysiawest",
        "sizingCriterion": "PerformanceBased",
        "reservedInstance": "RI3Year"
      }
    }'

# Poll until assessment status is Completed, then read assessed machines
az rest --method get \
    --url "/subscriptions/{sub-id}/resourceGroups/rg-migration/providers/Microsoft.Migrate/assessmentProjects/migrate-my/groups/production-workloads/assessments/day21-prod-assessment?api-version=2023-03-15"

Set the assessment target to Malaysia West and use performance-based sizing. In the assessment properties, configure reserved-instance pricing — for steady-state production VMs this is the single biggest lever you have. Reserved Instances save up to ~40% on one-year commitments and up to 65% on three-year commitments versus pay-as-you-go. Run the assessment numbers yourself; on a single mid-size VM the annual saving can easily exceed RM15,000. Real money for an SME.

Weeks 2–3: Cost Modelling in MYR

Azure Migrate gives you a headline estimate, but you need to translate it into business language. I pull live pricing from the Azure Retail Prices REST API and build my own model — it's scriptable and auditable:

import requests

url = "https://prices.azure.com/api/retail/prices"
flt = ("armRegionName eq 'malaysiawest' and "
       "armSkuName eq 'Standard_D4s_v5' and "
       "serviceName eq 'Virtual Machines'")

resp = requests.get(url, params={"$filter": flt,
                                 "currencyCode": "USD"}).json()
for item in resp["Items"][:6]:
    print(item["type"], item["retailPrice"],
          item.get("reservationTerm", ""), item["unitOfMeasure"])

This returns consumption, DevTest, and reserved pricing side by side — exactly what you need for a board comparison. Typical monthly run rates I've seen for Malaysian SME workloads in Malaysia West:

Compare these against your current on-premise TCO — power, cooling, DC rental, hardware refresh cycles, admin staff. For most SMEs, cloud lands 20–40% cheaper over three years once you count avoided hardware refreshes. Treat the table as illustrative; your assessment output is the number that matters.

Day 21 Deliverable

A completed Azure Migrate assessment with:

• Performance-based sizing recommendations pinned to Malaysia West
• Reserved-instance cost estimates, translated into MYR
• A migration strategy per workload: rehost, replatform, or refactor

Phase 2: Landing Zone Build (Days 22–60)

This is where most SMEs stall. They finish assessment, then spend months debating architecture. Skip the analysis paralysis — use the Azure landing zone (ALZ) IaC Accelerator, the successor to the old CAF Enterprise-Scale Terraform repo (deprecated in January 2025 and in extended support until the repository is archived on 1 August 2026). The accelerator supports both Bicep and Terraform and deploys governance, networking, and monitoring as one opinionated package.

Weeks 4–5: Deploy the Platform Foundation

For most Malaysian SMEs I recommend the small-enterprise topology: a platform subscription with hub networking, plus a workload subscription with spoke VNets. After the accelerator bootstrap, workload spokes are plain Bicep — easy to own and extend:

// workload-spoke.bicep — minimal production spoke
param location string = resourceGroup().location
param addressPrefix string = '10.10.0.0/20'

resource vnet 'Microsoft.Network/virtualNetworks@2024-03-01' = {
  name: 'vnet-prod-myw'
  location: location
  properties: {
    addressSpace: { addressPrefixes: [addressPrefix] }
    subnets: [
      {
        name: 'snet-workload'
        properties: {
          addressPrefix: addressPrefix
          privateEndpointNetworkPolicies: 'Enabled'
        }
      }
    ]
  }
}

output vnetId string = vnet.id

# Resource-group-scoped deployment — location is inherited from the resource group
az deployment group create \
    --resource-group rg-prod-network-myw \
    --template-file workload-spoke.bicep

Weeks 6–7: Hardening for Malaysian Requirements

Once the foundation is deployed, harden it. Enable Defender for Cloud plans for the workloads you actually run (you pay per plan, so scope it deliberately):

# Enable Defender plans for your core workload types
az security pricing create --name VirtualMachines --tier Standard
az security pricing create --name SqlServersVirtualMachines --tier Standard
az security pricing create --name StorageAccounts --tier Standard

# Route subscription activity logs into Log Analytics for PDPA audit trail
az monitor diagnostic-settings create \
    --name "sub-activity-to-law" \
    --resource "/subscriptions/{sub-id}" \
    --workspace "/subscriptions/{sub-id}/resourceGroups/rg-mgmt/providers/Microsoft.OperationalInsights/workspaces/law-myw-logs" \
    --logs '[{"categoryGroup":"audit","enabled":true}]'

Then configure data classification. Sensitivity labels (e.g., a "PDPA Personal Data" label) are managed in the Microsoft Purview portal and applied to storage accounts and databases holding personal data — this is portal and policy work, not a CLI flag, so put it on the hardening checklist and assign an owner.

Day 60 Deliverable

A production landing zone in Malaysia West with:

• Hub-spoke network topology
• Microsoft Entra ID integration and RBAC
• Defender for Cloud enabled on workload plans
• Activity and audit logging into Log Analytics for PDPA evidence
• Tagging and policy guardrails enforced via Azure Policy

Phase 3: Migration Execution (Days 61–90)

Data Migration Patterns

Three patterns cover most Malaysian SME estates.

Pattern 1: Lift-and-shift (VM rehost)

The fastest path, using Azure Migrate: Server Migration. Replication is configured in the portal or via the Az.Migrate module:

# Start replication for a discovered server (agentless)
# MachineId = the discovered machine's resource ID (get it from Get-AzMigrateDiscoveredServer)
# Full parameter set: Get-Help New-AzMigrateServerReplication
New-AzMigrateServerReplication `
    -MachineId "/subscriptions/{sub-id}/resourceGroups/rg-migration/providers/Microsoft.OffAzure/HyperVSites/{site-name}/machines/{machine-id}" `
    -LicenseType NoLicenseType `
    -TargetResourceGroupId "/subscriptions/{sub-id}/resourceGroups/rg-prod-workloads-myw" `
    -TargetNetworkId "/subscriptions/{sub-id}/resourceGroups/rg-prod-workloads-myw/providers/Microsoft.Network/virtualNetworks/vnet-prod-myw" `
    -TargetSubnetName "snet-workload" `
    -TargetVMName "vm-app01" `
    -TargetVMSize "Standard_D4s_v5" `
    -DiskType "Standard_LRS" `
    -OSDiskID "{os-disk-uuid}"

# Monitor until replication is healthy, then schedule cutover
Get-AzMigrateServerReplication -MachineName "vm-app01" `
    -ProjectName "migrate-my" -ResourceGroupName "rg-migration"

Pattern 2: SQL Server to Azure SQL

Two 2026 tooling updates matter here. The classic Azure Database Migration Service SQL scenarios were retired on 15 March 2026, and the Azure SQL migration extension for Azure Data Studio was retired together with Azure Data Studio itself on 28 February 2026 — don't build either into a new migration plan. Microsoft's current guidance, by target:

• Azure SQL Managed Instance — the guided path is the SQL Server migration experience in Azure Arc: discovery, assessment, and near-zero-downtime migration in a single flow. At scale, automate with the Azure DMS PowerShell cmdlets or Azure CLI.
• SQL Server on Azure VMs — the Azure DMS portal experience (online or offline, backups from Azure Blob storage or an SMB share), or the SSMS migration component if you can connect to both ends.
• Azure SQL Database — the DMS portal experience for schema + data (offline), or Striim for online, near-zero-downtime migration.

The workflow shape is unchanged: run the assessment (readiness flags plus a right-sized SKU recommendation — Managed Instance for near-parity lift, Azure SQL Database if you can modernise), choose online or offline mode, start the migration, and cut over in your change window.

Pattern 3: Web apps to Azure App Service

For .NET and Java web applications, replatforming to App Service is often the best value move. Containerise and deploy:

# Containerised .NET 8 app in Malaysia West
az webapp create \
    --resource-group rg-prod-workloads-myw \
    --plan plan-apps-myw \
    --name app-web-frontend \
    --deployment-container-image-name mcr.microsoft.com/dotnet/aspnet:8.0

# Integrate into the landing zone VNet
az webapp vnet-integration add \
    --resource-group rg-prod-workloads-myw \
    --name app-web-frontend \
    --vnet vnet-prod-myw \
    --subnet snet-workload

PDPA Compliance Checklist

Before cutover, verify:

1. Data classification — personal data is labelled and encrypted at rest (encryption is default on Azure storage and SQL, but verify it hasn't been disabled anywhere).
2. Access logging — access to personal data is logged with retention agreed with your DPO (seven years aligns with Malaysian tax record-keeping practice).
3. Consent and purpose — processing purposes match your PDPA notices.
4. Breach notification — Defender for Cloud alerts feed your incident process; the PDPA requires notification of qualifying breaches within 72 hours.
5. Erasure requests — your data architecture can actually delete data when asked.

# Verify encryption is enabled on the storage account holding audit data
az storage account show \
    --name stauditmyw \
    --resource-group rg-mgmt \
    --query "encryption.services.blob.enabled" \
    --output tsv

The Cutover Playbook

Run cutover on days 85–88 with a rollback window to day 90:

1. Day 85 — final data sync (Azure Migrate continuous replication; Azure SQL online mode keeps log shipping warm).
2. Day 86 — DNS switchover for internal applications.
3. Day 87 — external DNS switchover, monitoring on high alert.
4. Days 88–90 — hypercare. Watch dashboards, resolve issues, confirm performance against the baselines you captured during assessment.

Common Pitfalls (and How to Avoid Them)

Pitfall 1: Underestimating network connectivity. Malaysia West is local, but your users still need adequate bandwidth to it. Budget for ExpressRoute or at minimum a site-to-site VPN during migration and hypercare — get a fresh quote; connectivity pricing moves.

Pitfall 2: Ignoring licensing. Azure Hybrid Benefit for Windows Server and SQL Server can cut VM costs dramatically if you already own qualifying licenses. Check entitlements before paying for license-included pricing.

Pitfall 3: Over-engineering the landing zone. The small-enterprise topology is enough for most Malaysian SMEs. Don't deploy a full multi-region enterprise-scale platform with Virtual WAN when a single hub-spoke in Malaysia West serves you fine. You can grow into complexity; you can't shrink out of it easily.

Pitfall 4: Skipping the PDPA conversation. I've seen migrations stall at the last minute because Legal wasn't engaged early. Bring your DPO or compliance officer to the Week 1 kickoff. PDPA compliance is a design constraint, not an afterthought.

Pitfall 5: No rollback plan. Keep the on-premise environment warm until you've validated production performance in Azure. Set DNS TTL low (300 seconds) during cutover so you can flip back fast if something misbehaves.

The Cost Reality

Let me be direct about numbers for a typical Malaysian SME — 20 servers, a SQL database estate, and a few web applications:

• Assessment phase — RM0. Azure Migrate's discovery and assessment tooling is free.
• Landing zone run cost — roughly RM800–1,500/month for the platform subscription (management, monitoring, networking).
• Migration tooling — minimal; the primary costs are replication storage and any temporary bandwidth.
• Post-migration run rate — RM15,000–25,000/month with Reserved Instances, for the workload profile above.
• Professional services — if you engage an SI for the 90-day engagement, budget in the region of RM80,000–150,000 depending on scope.

Compare that against your current on-premise TCO. If you're due a hardware refresh within 18 months, the business case practically writes itself.

Key Takeaways

1. Assessment is a solved problem — stop dwelling there. Azure Migrate is free, and Malaysia West is live with three availability zones in Greater Kuala Lumpur. Run discovery in Week 1 and commit to a migration plan by Day 21. Endless assessment is procrastination wearing a spreadsheet.
2. Use the ALZ accelerator, not custom architecture. The Azure landing zone IaC Accelerator (Bicep or Terraform) gives you enterprise-grade governance out of the box, and the classic CAF Terraform tooling is being retired — don't build on it. Your landing zone should be production-ready by Day 60.
3. PDPA compliance is a design constraint, not a checklist item. Classify personal data, log access with agreed retention, verify encryption, and make sure your breach workflow can hit the 72-hour window. Build it into the landing zone from Day 1, not Day 89.
4. Budget honestly, in MYR. Pull live pricing from the Retail Prices API, model reserved-instance terms, and compare against your real on-premise TCO — including the hardware refresh you're about to buy anyway.
5. The 90-day timeline is aggressive but real. The trick is parallelism: the landing zone build doesn't need your server inventory, so start it while assessment finishes. Lift-and-shift 80% of workloads, replatform the 20% where the value justifies it.

Malaysia West removed the data sovereignty barrier. The question is no longer whether to migrate — it's whether you'll execute before your competitors do.