How to Assess, Plan & Migrate Citrix Workloads from AWS to Azure

Step 0Understand what you are actually moving

Before any tool is deployed, classify the source estate. The single biggest cause of failed Citrix cloud migrations is treating catalogs of machines as the unit of migration. The correct mental model is three planes:

• Control plane (broker): Where Delivery Controllers / Citrix Cloud, StoreFront, NetScaler/Gateway, License Server, and SQL Server live.
• Workload plane (machines): Session hosts / VDAs (Server OS or Desktop OS), machine catalogs, master images, and provisioning (MCS or PVS). This is usually the “Citrix workload on AWS” you literally see as EC2 instances.
• User state plane (identity + data): Active Directory / Entra ID, user profiles (UPM or profile containers), folder redirection, and the backend apps & data the sessions talk to.

Typical Citrix-on-AWS topologies you will encounter

High-level AWS → Azure mapping reference

Phase 1Assessment — establish the baseline with data

Assessment is where you de-risk the entire program. Budget 2–4 weeks of wall-clock time; every hour invested here removes rework in later phases. The output is a discovery workbook containing inventory, utilization baselines, persona segmentation, an application register, licensing status, cost baseline, and a risk register. The workbook is the single source of truth that every later design decision cites.

1.1 Inventory every Citrix component

Create a component inventory using Citrix Studio/Console exports, the Citrix PowerShell SDK, and AWS inventory sources (EC2 console, Tag Editor, AWS Config, or AWS Systems Manager). For each component capture: version/patch level, role, location (region/AZ), instance type, CPU/RAM/disk, network placement, and how it is provisioned (MCS/PVS/manual, persistent/non-persistent).

1.2 Capture utilization baselines — you cannot size Azure without them

Pull 4–12 weeks of history from Citrix Director/Monitor and the OS performance counters before anything is turned off. These baselines later become the acceptance criteria for the Azure environment.

1.3 Map dependencies and network flows

Every Citrix estate is a spiderweb of flows: VDA→broker, VDA→SQL (for the CVAD site database), VDA→profile store, VDA→backend apps, client→gateway, and AD replication. Produce a flow map and label each dependency as stays in AWS during coexistence, moves to Azure with the workload, or is on-premises and never moves.

• Identify the SQL Servers (Citrix site database, any app DBs), file servers, and LOB backends that require low latency.
• Measure RTT from each candidate Azure region to each backend location using Test-NetConnection, ping, psping, or Azure Network Watcher connectivity checks. The rule of thumb for a good Citrix session is ICA RTT well under ~150 ms end-to-end, and app-specific flows can be far stricter.
• Note which apps call back to AWS or on-premises: if a legacy app backend stays behind, plan the coexistence network path (Section 2.4) and its latency budget explicitly.
• Document DNS: internal names/zones (AD-integrated), StoreFront URLs, and the public DNS (Route 53) that clients resolve.

1.4 Segment users into personas — design units, not “users”

Group users by workload intensity and device profile so each segment can be assigned a purpose-built Azure catalog. This is the input for both sizing and wave planning.

1.5 Audit applications

• Usage reality check: export published apps from Studio and compare against Director usage data. Retire or park apps with near-zero launches instead of carrying them forward.
• Packaging method: note which apps are baked into the master image, layered (App Layering), or streamed (App-V). This decides whether the app is re-baked into the new Azure master image, re-created as a layer, or converted to MSIX App Attach (AVD path).
• Licensing compliance: verify each app’s EULA for virtualization rights, multi-session use, and cloud/VM licensing. On-prem server-license-based products and AWS-specific licensing can bite in Azure.
• Compatibility flags: record known hooks into the OS image, print drivers, antivirus, and endpoint agents (e.g., DLP, encryption) that must be re-certified on the new image.

1.6 Assess profiles, user data, and storage

• Identify the profile solution in use (UPM, FSLogix, roaming, local-only) and its GPO/policy configuration.
• Sample profile sizes and folder-redirection targets; quantify total user-data volume and file counts (this sizes the data-migration tool: AzCopy, Azure Data Box, or storage sync).
• List UNC paths and permissions, mapped drives, and drive maps users rely on.
• Quantify storage growth rate so target Azure storage (Azure Files Premium / NetApp / managed disks) is sized with headroom.

1.7 Licensing & commercials — resolve before you design

1.8 Capture the cost baseline (TCO)

Build a full-cost baseline of the AWS estate, not just raw EC2: instance costs, EBS/EFS/FSx storage, data-transfer and NAT-gateway charges, marketplace/Citrix consumption, support, and the operational labor of managing the estate. You need this number twice: once to validate the Azure business case, and once as the “before” side of the post-migration cost review. Use the Azure Pricing Calculator and TCO calculator to model the target and capture assumptions (reservations, savings plans, Autoscale power-off savings, egress elimination).

1.9 Assessment sign-off checklist

• Component inventory exported and maintained in a live workbook
• Utilization baselines captured (sessions, CPU/RAM, logon, ICA RTT, profiles) for ≥4 weeks
• Dependency/flow map complete, with backend locations and latency measurements
• Persona segmentation agreed with business units
• Application register with keep/retire/repack decisions drafted
• Profile & data volume quantified; profile solution chosen at high level
• Licensing position documented for Citrix, Microsoft, and top apps
• Cost baseline and target-state cost model reviewed with finance
• Risks logged with owners (top risks: app compatibility, profile migration, latency to backends, printing, licensing)

Phase 2Target design & migration planning

Design freezes happen before any Azure subscription is built. The outputs of this phase are: an architecture document (landing zone, network, identity, image/provisioning, sizing, storage, access, HA/DR, security, monitoring), a licensing/costing model, and the wave & release plan with success criteria. Use Microsoft’s Cloud Adoption Framework (CAF) as the scaffold — it maps cleanly onto Citrix-on-Azure deployments.

2.1 Decide the target architecture (Scenario A vs. B vs. hybrid)

Choose per persona if needed — there is no rule that everyone must land on the same platform. Whatever the mix, the sequence in this guide is identical for the layers that matter: landing zone, image, catalog provisioning, profiles, apps, and cutover.

2.2 Landing zone design (governance & subscriptions)

• Subscription model: use management-group hierarchy with separate subscriptions (or resource groups with tight policy) for connectivity, identity, and each Citrix workload environment (Prod / Non-prod / DR). Follow Citrix reference guidance: up to ~2,500 VDAs can sit comfortably in a well-structured single subscription; larger estates should use a hub-and-spoke subscription model to stay inside Azure and MCS scale limits (5,000 VDAs per subscription per region is Citrix’s recommended ceiling — see its DaaS limits documentation).
• Region selection: choose the region nearest the users and the backend data. Where user groups span geography, prefer multi-region resource locations over one distant region. Check vCPU quota in the target region early — VDI fleets routinely need quota-increase requests for hundreds of vCPUs.
• Resource organization: dedicated resource groups per catalog/role with tags (cost-center, persona, wave, environment). Keep MCS-managed resource groups untouched by hand.
• RBAC & service principals: create a service principal for Citrix with least-privilege permissions to create/manage VMs, disks, NICs, and resource groups in the Citrix subscriptions (Citrix provides an ARM template that creates a minimal-role for the host connection). Separate SAs for image automation and Azure DevOps pipelines.
• Azure Policy & governance: enforce allowed VM SKUs/regions, require diagnostic settings, mandate tags, deny public IPs on VDAs, require disk encryption. These policies later become your automated guardrails.

2.3 Identity architecture

• Domain join: VDAs and Cloud Connectors must reach an AD domain. If the current AD is in AWS or on-premises, you either replicate/stand up domain controllers in Azure (joined over ExpressRoute/VPN to the forest) or use AWS Managed AD→Entra Domain Services–style equivalents where architecture allows. Cloud-only / Entra-joined endpoints matter for the AVD path.
• Identity flow: Citrix on Azure works with AD joined VMs and (for Citrix DaaS) Entra ID integration for authentication/SSO and MFA through the gateway. For AVD: native Entra ID join, single sign-on, and Conditional Access.
• Groups: mirror AD groups that grant access to delivery groups into target-side groups; keep naming consistent so cutover scripts can map users 1:1 (e.g., DG-Sales-AWS → DG-Sales-Azure).
• GPO vs. policy engine: inventory every VDA-applicable GPO, Citrix policy, and (if AVD) Intune configuration profile. Map each to its target equivalent and identify which ones need re-creation from scratch. This is routinely underestimated.
• MFA / Conditional Access: design the new gateway authentication stack (NetScaler nFactor / Citrix Gateway Service, or Entra ID Conditional Access for AVD) in parallel — do not carry weak legacy auth forward.

2.4 Network & connectivity design

• Hub-and-spoke VNets: a connectivity hub hosts ExpressRoute/VPN gateways, Azure Firewall, and DNS forwarding. Spokes host identity, Citrix infrastructure, and VDA catalogs, peered to the hub.
• Backend reachability: route VDA traffic to on-premises/other-cloud backends over ExpressRoute (preferred for latency-sensitive and large data flows) or Site-to-Site VPN. For the transition window you will also need AWS↔Azure connectivity (Section 3.1).
• Internal DNS: deploy conditional forwarders in Azure so VDAs resolve internal names to AD/backend zones; keep split-horizon DNS for StoreFront URLs identical to today where possible to minimize endpoint changes.
• Security boundaries: NSGs on subnets (deny inbound from internet on VDA subnets), no public IPs on VDAs, Azure Bastion for admin access, private endpoints for Azure Files and other PaaS storage used for profiles/data.
• Remote access: deploy NetScaler VPX in Azure in HA (active-passive across availability zones) fronted by Azure Load Balancer, or move to Citrix Gateway Service to remove the NetScaler VM footprint entirely. Plan TLS certificates and public DNS (Route 53 → Azure DNS, or keep DNS where it is and point records at Azure).
• Capacity: size the ExpressRoute/VPN for peak concurrent traffic — a Citrix estate moving to Azure concentrates media, profile, and app traffic that previously spread across AWS and on-prem paths.

2.5 Image strategy & machine provisioning

• Master image per persona: build one golden image per OS/persona combination (e.g., Windows 11 multi-session for knowledge workers, Windows Server 2022 for task/RDS-style, Windows 11 + GPU drivers for graphics) with the current Citrix VDA (LTSR recommended), core apps, agents, and security tooling.
• Image lifecycle: publish images as versions to Azure Compute Gallery (formerly Shared Image Gallery) so the same image is replicated across regions for HA/DR and can be versioned for patching. Use an image-builder pipeline (Packer in Azure DevOps, Azure Image Builder) so the “build once → validate → publish” loop is repeatable monthly/quarterly.
• Provisioning choice: MCS is the default on Azure and handles most deployments cleanly. Keep PVS only where there is a strong reason (existing PVS investment, specific update patterns). For pooled catalogs use MCS on-demand provisioning and non-persistent machines where app/profile design allows — it is cheaper and more predictable than persistent VDI.
• Which machines to truly migrate: in general, do not replicate session hosts. Non-persistent machines are rebuilt from a new Azure image anyway; persistent/static machines and any genuinely lift-and-shift backends are the only candidates for VM replication (Section 3.6).

2.6 Sizing the Azure estate

Translate the utilization baselines (Section 1.2) into Azure VM SKUs per persona, then validate in the pilot with a load test. Guidance below is a starting point — always confirm with measured data and Citrix reference architectures, since SKU naming and density recommendations evolve.

• Storage per machine: OS disks on Standard SSD or Premium SSD; pooled machines can use small OS disks + FSLogix for profile state, keeping disks lean. Enable ephemeral/on-demand provisioning where supported to cut storage spend.
• Compute economics: pair Citrix Autoscale (schedule + load based) with Azure Reserved Instances / Savings Plans for the always-on baseline, and pay-as-you-go for the elastic peak. RIs require matching region + OS + SKU, so freeze SKUs early and let Autoscale handle the time dimension.
• Right-size during migration: as with AWS, do not faithfully copy over-provisioned instance sizes into Azure; the migration is the cheapest moment to re-shape.

2.7 Profiles, user data & storage design

• Profile container standard: adopt FSLogix profile containers on the target (works whether you land on Citrix DaaS on Azure or AVD, so it is future-proof). If you must keep Citrix UPM in the interim, plan the eventual FSLogix conversion as a follow-on workstream.
• Storage tier for profiles: Azure Files Premium (SMB, low latency, 100 TiB, private endpoints) is the default for most estates. Use Azure NetApp Files where you need higher IOPS/latency guarantees, larger scale, or strong NFS/SMB feature parity with existing filers.
• Folder redirection: redirect Documents/Desktop/Downloads to the same profile share or an Azure Files share per user to keep login times low.
• Data migration mechanics: plan AzCopy/robocopy parallel copies of user data to Azure storage during the build window, with a delta pass before each wave’s cutover, and Azure Data Box for any multi-TB estate where WAN copy is impractical.
• Printing: decide the print architecture early (Universal Print, NetScaler/print-server redirection, or a print server VM in Azure) — printing is one of the top three cutover surprises.

2.8 High availability, backup & disaster recovery

• In-region HA: place Cloud Connectors and VDAs across Availability Zones; use flexible scale sets for catalogs where you want zone distribution with MCS. Multiple StoreFront/NetScaler instances behind a load balancer for the access layer.
• Cross-region DR: replicate the golden images via Azure Compute Gallery to a secondary region, keep FSLogix shares replicated (Azure Files geo/zone redundancy or NetApp cross-region replication), and define a DR runbook with a target RTO/RPO. Persistent desktops and the CVAD SQL layer can use Azure Site Recovery or native DB replication.
• Backups: Azure Backup for any persistent VMs and file shares; snapshots or versioning for images. Document restore testing in the runbooks.

2.9 Security & compliance design

• Layer identity-centric controls: Conditional Access, MFA, and session policies at the gateway; RBAC least privilege inside Azure.
• Protect VDAs with Microsoft Defender for Cloud / Defender for Servers (or your existing EDR) before first user wave; keep agent deployment in the golden image.
• Encryption at rest (SSE, disk encryption), TLS everywhere in flight, private endpoints for profile/back-end storage, no public IPs on VDAs, and Azure Policy to keep drift from re-introducing exposures.
• Confirm data-residency and compliance requirements (Sovereignty, regional data) against the chosen Azure region, and record evidence in the architecture document.

2.10 Monitoring & operations model

• Monitor the Citrix layer with Citrix Monitor (Director successor) — session trends, logon breakdown, ICA RTT, app failures — plus Citrix Analytics for user-behavior/experience signals if licensed.
• Monitor Azure with Log Analytics/Application Insights: VM health, guest OS counters, Autoscale/power state, quota & cost alerts. Ship Citrix VDA and infrastructure logs to a central workspace and build dashboards that reproduce the AWS-era operational reports.
• Patching cadence: for non-persistent catalogs, patch by image refresh (quarterly OS+Citrix VDA updates published to the gallery and re-provisioned), which is simpler and more consistent than in-place patching of hundreds of VDAs. Keep an always-on maintenance/seed catalog for emergency in-place patching if needed.
• Define runbooks, on-call ownership, and a Sev1/2 escalation path before pilot starts. Decide who owns Citrix vs. Azure vs. network vs. identity tickets in the new model.

2.11 Wave & release planning

• Wave definition: group users by business unit/region rather than by convenience — each wave should be able to run a complete business cycle and its own UAT. Typical shape: Wave 0 (IT/early adopters, 20–50 users) → Wave 1 (pilot BU, 5–10% of users) → Waves 2..n (10–25% each) → tail (problem users, execs) — the last waves should be the least risky, not the most senior.
• Coexistence window: plan for AWS and Azure estates running in parallel during waves (this is your rollback insurance). Cost the double-running period explicitly — it is a feature, not waste.
• Cutover pattern per wave: because both environments can be live, wave cutover is usually “flip the user’s access” rather than “move the machine”: add the user/group to the Azure delivery group, remove from the AWS delivery group (or point the client to the new store/gateway), and validate. Keep AWS memberships intact for 48–72h of hypercare so rollback is one click/command.
• Success criteria & KPIs: agree measurable gates before Go: logon duration within X% of baseline (or < defined seconds), ICA RTT under threshold, UAT defect rate, helpdesk ticket volume per 100 users, app-launch success ≥ baseline, cost/user within model ±10%.
• RACI & staffing: name owners for Citrix engineering, Azure networking, identity, app teams, helpdesk/change, and each wave’s BU liaison. Schedule hypercare teams for every cutover window.
• Communications: per-wave user comms — what changes (store URL/client, if any), what does not (apps, credentials, data), when, and who to call. Under-communication is the #1 source of negative user sentiment in VDI migrations.

Phase 3Migration execution — build, pilot, wave rollout

Execution is deliberately boring and repeatable. Build the foundation once, prove it with a ruthless pilot, then run the same cutover playbook wave after wave. Protect the plan with three rules: one wave at a time, every wave has a rollback path, and nothing changes without a change record.

3.0 Pre-flight: governance & tooling setup (Week 0–1)

• Provision the management group / subscription hierarchy, RBAC, service principals, and Azure Policy assignments from the design.
• Deploy the connectivity hub (ExpressRoute/VPN gateways, Azure Firewall, DNS forwarders) and spoke VNets; create the AWS↔Azure interconnect for coexistence (e.g., Site-to-Site VPN or Direct Connect Gateway / ExpressRoute to AWS Direct Connect). Validate routing tables both ways with test VMs.
• Stand up the identity layer in Azure (domain controllers replicating the AD forest, or Entra ID + Domain Services per design) and confirm AD replication, DNS resolution of internal names from Azure, and GPO readiness.
• Create the Azure Compute Gallery, image-builder pipeline, Log Analytics workspace, and alerting skeleton.
• Stand up target-side file shares (Azure Files Premium / NetApp) with private endpoints, and stub the folder-redirection & FSLogix structure.

3.1 Establish AWS↔Azure coexistence connectivity

During wave migration you will run two estates against the same backend apps, AD, and user data. Options (in ascending cost/effort): a temporary Site-to-Site VPN between VPC and VNet; Direct Connect Gateway + ExpressRoute if the org already uses DX; or routing both clouds through the existing on-premises hub if backends live there. Whatever the mechanism, validate three things with real traffic before building anything on it:

3.2 Build golden images & validate (Week 2–4)

1. Install a clean Windows Server or Windows 10/11 multi-session OS (eligible per licensing review) in Azure.
2. Apply OS optimization for the target use (Citrix’s image-optimization guidance / Microsoft’s AVD optimization where relevant), all current security patches, and your EDR/agents.
3. Install the matching Citrix VDA (LTSR current) with the correct delivery type (Citrix DaaS / CVAD), then core apps per persona.
4. Generalize, publish to Azure Compute Gallery with version naming, and build a Machine Catalog in the non-prod resource location first.
5. Run a structured smoke test: boot, broker registration, logon, profile attach, app launch, print, clipboard/redirection, HDX features, and performance counters. Fix image issues in the image, not on individual machines.

3.3 Stand up the target control plane

• Scenario A (Citrix Cloud / CVAD on Azure): add a new Azure resource location with ≥2 Cloud Connectors per location (spread across zones), add an Azure hosting connection for the Citrix service principal, and connect the site database/controllers per design. Register VDAs from the test catalog to validate end-to-end brokering.
• Scenario A self-managed CVAD: if controllers move as VMs, install/restore the new site on Azure VMs (or migrate the existing site database and point new controllers at it) and stage StoreFront & NetScaler in Azure.
• Scenario B (AVD): create host pools, workspace(s), application groups, session-host registration using the FSLogix + multi-session stack, and Entra ID/Intune policies.
• Validate end-to-end user flow: endpoint → gateway (NetScaler VPX in Azure / Citrix Gateway Service / Windows App) → StoreFront/feed → broker → VDA → profile share → backend. Measure logon time and ICA RTT against baseline.

3.4 Provision production catalogs in Azure (Weeks 4–6)

• Create the Machine Catalogs and Delivery Groups per persona with the agreed SKUs and Autoscale schedules, in the Prod resource location.
• Re-create Citrix policies (or map GPOs) at target parity — session, bandwidth/HDX, security, printing. Compare policy sets side-by-side so nothing is silently dropped.
• Map AD groups: source delivery-group memberships → target groups. Automate the mapping table so each wave only flips membership flags.
• Enable Autoscale per schedule/load from the utilization baselines; run a dry power-cycle test.
• For any machines that must be migrated rather than re-provisioned (persistent desktops, backends — Section 3.6), prepare the replication pipelines now, before wave 1.

3.5 Profile & user-data migration pipeline

1. Build the profile-conversion process: Citrix UPM → FSLogix (or direct folder-redirection + FSLogix). Use Citrix’s profile-migration tooling or a documented robocopy/AzCopy recipe; never let users log on to the Azure estate before their profile data lands.
2. Classify users by data volume (from Phase 1) into: small (copy at wave cutover), medium (pre-copy night before + delta), large / multi-TB (continuous sync via Azure File Sync or Data Box for the seed + sync until cutover).
3. Automate per-wave data moves with a scripted pipeline that: stops the user’s AWS session, does the final delta copy, verifies checksums/file counts, marks the user “ready,” and updates the access groups. Record start/end time and bytes moved in the wave log for audit.
4. Validate profile conversion with a pilot set: logon time, app data intact, redirected folders present, permission integrity (ACLs preserved).

3.6 The Wave 0 + pilot (Weeks 6–8) — the gate that matters most

Wave 0 (IT/eager users, ~20–50) proves plumbing. Pilot wave (5–10% of the user base) proves the product — run it for at least one full business cycle (2–4 weeks). During pilot:

• Compare measured KPIs to baselines: logon duration breakdown, ICA RTT, app launch, session reliability, print.
• Run a load test against the pilot catalogs (Citrix load-testing tools or scripted synthetic load) to validate concurrency assumptions and Autoscale behavior at the wave-1 scale.
• Instrument helpdesk: log every pilot ticket with category; track defects to root cause in image, policy, profile, or network.
• Test rollback for real: flip one pilot user back to AWS for a day to prove the mechanism and rebuild confidence.

3.7 Wave rollout & cutover playbook (Weeks 9–16+)

Each wave follows the identical runbook. Freeze the playbook after pilot; changes to it between waves are a process-change request, not a spontaneous tweak.

1. Prepare (T-7 days): notify users, update helpdesk, pre-copy user data, snapshot target catalog state, confirm backend capacity for the wave’s concurrent load.
2. Stage (T-1 day): final delta sync of profiles/data; verify target delivery group has capacity for the wave’s peak concurrency; warm Autoscale hosts if needed.
3. Cutover (T-0, off-peak window): move the wave’s users to the Azure delivery group / new store (remove or re-scope AWS memberships), flip public DNS/URL if the store URL changed, and re-test a sample of users end-to-end.
4. Hypercare (T+0 → T+72h): dedicated support channel; monitor logons, failures, app errors, and ICA RTT in real time; on Sev1 or prolonged outage, execute the documented rollback for the wave (re-add to AWS groups, re-point DNS), then return the wave to a later slot.
5. Close (T+5 days): BU sign-off on the wave’s success criteria; retro notes folded back into the playbook; AWS resources for the wave marked for decommission (not yet deleted).

Wave pacing guidance: allow 2–5 business days of steady-state observation between waves. If a wave fails its criteria, pause the program — do not accelerate to “make up time.” The program is done when the last wave closes, not when the calendar says so.

3.8 Special cases: persistent desktops & lift-and-shift servers

Not everything should be re-provisioned. For persistent (static) desktops and non-VDI servers you genuinely keep (e.g., the CVAD SQL server, print server, file server, or LOB app VMs that must move with the estate), use a replication-based migration:

• Azure Migrate (agent-based or agentless) replicates AWS EC2 VMs to Azure: set up an Azure Migrate project, add the AWS account/credentials as a discovery source, replicate chosen VMs to the target VNet, test-recover, then migrate in the wave window. Agent-based replication also covers VMs running in on-premises or other clouds.
• Right-size during replication (choose the Azure SKU and disk type from utilization, not source size).
• Always do a test failover into an isolated test VNet, validate DNS/AD/backends, then schedule the final cutover. Keep the AWS source running until hypercare passes.
• For persistent desktops, plan the profile/data handling separately — replicating the VM does not automatically give you a clean FSLogix profile layout on the target.

3.9 Testing & UAT architecture

• Stand up a mirrored non-prod environment in Azure from the same images and IaC as prod so every release is validated before production change.
• Build a user acceptance test pack per persona (logon, the persona’s top 5 apps, print, files, clipboard, USB/redirection, VPN/off-net access) and require BU sign-off per wave.
• Automate the repeatable checks (image build, broker registration, FSLogix attach, autoscale cycle, failover drill) in CI/CD — e.g., GitHub Actions/Azure DevOps pipelines running Packer + PowerShell + Bicep/Terraform.

Phase 4Optimize & operate the Azure estate

4.1 Post-migration optimization loop

• Right-size continuously: after 4–6 weeks of steady state, re-analyze utilization in Azure (Azure Monitor + Citrix Monitor). Expect density to change as Autoscale settles and users adjust — adjust SKUs and Autoscale policies rather than leaving the pilot sizing in place forever.
• Cost governance: review Azure Cost Management monthly against the cost baseline; check reservation utilization, storage costs per catalog, and egress. In particular, watch unused persistent disks and orphaned MCS resources — they silently inflate the bill.
• Image hygiene: refresh golden images on a quarterly cadence (security patches + Citrix VDA LTSR updates) through the automated pipeline and re-provision non-persistent catalogs from the new versions. Confirm the patching SLA with security teams.
• UX telemetry: tune Citrix Monitor/Endpoint Analytics thresholds; build alerts for logon-time regressions, app failures, and session drops. Run a regular sampling of ICA RTT from representative endpoint locations to catch network drift early.

4.2 Decommissioning the AWS estate

Decommission in deliberate order, gated on hypercare closure and data-retention policy, never all at once:

1. After each wave’s hypercare + BU sign-off: remove user access from AWS delivery groups; keep machines running but idle for the retention window.
2. After the final wave closes and the full parallel-run window ends: snapshot/bill, then power off AWS catalogs. Retain powered-off for one patch-cycle (or per policy), then delete MCS catalogs, EC2 instances, and Cloud Connectors.
3. Decommission the AWS resource location / CVAD site only after confirming no user, no app, and no monitoring still depends on it. Retire the AWS↔Azure interconnect and related Route 53/NAT/peering entries last, after DNS cutover is fully proven.
4. Archive the assessment workbook, wave logs, and cost baseline in your CMDB/docs for audit and future migrations.

Watch-outsTop pitfalls — and how to avoid them

ReferenceTools & resources cheat-sheet

TimelineRealistic timeline, roles & final checklist

Indicative program timeline (mid-size estate, ~500–2,000 users, Scenario A)

Total for this profile: roughly 5–8 months wall clock. Smaller estates (1–3 hundred users, simple apps) can compress toward 2–3 months; very large or GPU-heavy estates stretch longer. The sequence does not compress well — the pilot is the gate, not a speed bump.

Team roles that make it succeed

One-page final checklist

• Discovery workbook with live inventory + ≥4 weeks utilization baselines
• Licensing confirmed in writing (Citrix, Microsoft VDI/RDS, third-party, Azure Hybrid Benefit)
• Target architecture + landing zone diagram approved; region chosen by user/backend proximity
• Azure quotas requested; SKU availability verified in target region
• Coexistence connectivity AWS↔Azure validated (latency, throughput, DNS)
• Golden images built in Azure Compute Gallery with automated lifecycle
• Pilot exit criteria met (logon, ICA RTT, UAT, helpdesk, rollback drill, cost)
• Wave plan frozen; playbook versioned; hypercare & rollback per wave
• Profile/data pipeline automated and verified (ACLs, checksums, retention)
• Monitoring, patching, DR, and support runbooks owned and tested
• Cost model reconciled monthly; decommission of AWS in gated order

Bottom line: migrating Citrix from AWS to Azure is not a virtualization exercise — it is a layered platform migration where the machine re-provisioning is the easy part and the assessments, identity/policy parity, profile data, network path, and wave discipline are the actual project. Follow the four phases with evidence-based gates, and the move becomes a repeatable playbook rather than a leap of faith.