Azure Migrate Classic: Cut Over or Re-Replicate by September 30, 2026

Azure Migrate projects should split physical Windows servers into two tracks immediately: cut over only machines whose final Classic recovery point is usable, validated, and acceptable as a migration source; re-replicate everything else through the simplified appliance. A server requiring current data, newly enabled replication, or a schedule extending beyond September 30, 2026 does not belong in an expedited Classic cutover plan.
Microsoft’s Azure Migrate documentation says Classic replications stopped creating recovery points after May 31, although migrations from existing recovery points remain supported until September 30. As of July 19, even the newest possible Classic recovery point is nearly seven weeks old, making data age—not appliance installation—the first decision administrators must address.

Divide the Estate Before Scheduling Any Cutovers​

The Classic retirement creates two fundamentally different projects. One is a controlled recovery from a frozen replicated state; the other is a fresh migration using the simplified Azure Migrate experience.
Do not combine them under one generic “Azure migration” milestone. They have different data-loss exposure, validation requirements, rollback plans, and deadlines.
Use this decision process now:

1. Inventory every Azure Migrate project containing physical or agent-based Windows Server migration work.
2. Identify each server still associated with a Classic Replication Appliance and record its final recovery-point date.
3. Confirm whether the recovery point contains an operationally usable copy of the workload, not merely whether Azure still displays it.
4. Assign servers with acceptable frozen states to a tightly controlled Classic final-migration track.
5. Assign servers needing current data, new replication, additional migration time, or unresolved application validation to the simplified-appliance track.
6. Remove servers with unknown owners or uncertain dependencies from the expedited track until those gaps are resolved.
7. Complete Classic migrations well before September 30 rather than treating that date as an available maintenance window.

The March 31 block on enabling Classic replication already removed Classic as an option for newly discovered servers. The May 31 recovery-point cutoff then froze the data available to existing replications. September 30 is the final service boundary: Microsoft says administrators will no longer be able to view, manage, replicate, or migrate affected Classic machines through the Azure portal after retirement.
That sequence matters. Classic has not remained a normally functioning migration path with a future shutdown date; it has already lost its ability to produce current replicas.

Which Servers Can Still Use the Classic Cutover Path?​

A Classic cutover remains defensible only when the final recovery point represents a state the organization can knowingly deploy. That may include an effectively static server, a workload whose authoritative data resides elsewhere, or a machine that stopped changing before May 31.
The candidate must pass more than a portal-status check. Administrators should prove that the replicated operating system boots, required Windows services start, application components communicate correctly, and the recovered data matches the state the business intends to use.
A suitable Classic candidate should have all of the following:

• The owner accepts the exact recovery-point date and the resulting gap from the current source server.
• Application data created after that recovery point can be discarded, reconstructed, or restored through a separately tested process.
• A test migration has verified boot behavior, networking, authentication, services, and application operation.
• The team can complete migration, validation, and cleanup before September 30.
• The rollback evidence identifies what will happen if the Azure VM fails acceptance testing.
• No unresolved dependency requires the source and migrated copies to remain synchronized.

A test migration is especially important because a successful replication job does not prove that an aging image is still a viable production system. Configuration outside the replicated server may have changed since May 31, including credentials, certificates, DNS records, firewall policy, upstream endpoints, service accounts, and dependencies on other machines.
Administrators should also distinguish an application’s data from its server image. A web front end backed by an external database may tolerate an older machine recovery point after configuration review. A physical file server or locally hosted line-of-business database is far less likely to tolerate weeks of missing writes.
Classic should now be treated as a frozen recovery artifact, not an active replication channel. If the migration plan assumes one final synchronization of recent source changes, it is already incompatible with the Classic path.

Which Servers Must Be Re-Replicated?​

Any server that needs an up-to-date copy belongs on the simplified appliance, even if a Classic recovery point remains visible. Re-replication is also the correct route for newly discovered workloads, machines whose Classic state cannot be proven, and migrations expected to run past September 30.
This track should include:

• Windows servers that have continued receiving application or user data since May 31.
• Systems whose final Classic recovery point failed testing or lacks documented validation.
• Servers discovered after Classic replication enablement was blocked on March 31.
• Workloads awaiting application remediation, procurement, security approval, or a later maintenance window.
• Machines whose owners cannot accept the data gap represented by the final recovery point.
• Projects requiring continued replication or migration management after September 30.

Re-replication should not be framed as converting a Classic replication in place. Operationally, the safer plan is to establish the simplified experience, begin a new replication lifecycle, validate its recovery point, and then retire the old Classic dependency only after the replacement path is proven.
Where time and infrastructure permit, run the transition in parallel. Keep the existing Classic record available as evidence while deploying the simplified appliance, preparing the required server components, and establishing new replication. Avoid dismantling the old migration configuration merely because the new appliance has registered successfully.
The decisive milestone is not appliance deployment. It is a tested recovery point from the new replication path that satisfies the workload’s recovery and cutover requirements.

---

Audit Projects, Appliances, Vaults, and Servers as One Dependency Chain​

An Azure Migrate project-level inventory alone can miss the operational relationships that matter. The audit should connect the project, replication appliance, relevant Azure resources, source Windows server, application owner, and planned target VM.
Create one migration register with at least these fields:

• Azure Migrate project and subscription.
• Replication experience: Classic or simplified.
• Appliance identity, owner, and operational status.
• Source server name, Windows Server version, and application role.
• Mobility service or related agent state and responsible support team.
• Final Classic recovery-point date, where applicable.
• Test-migration result and date.
• Required network and firewall access.
• Application owner and migration approver.
• Cutover track, maintenance window, and rollback evidence.
• Target Windows Server version if an OS upgrade is planned.

Do not assume the Azure team owns every dependency. Physical-server migrations often cross server operations, networking, application support, identity, backup, and security teams. A server without a named application owner should be classified as unresolved, not low risk.
The audit should also search for workloads that are absent from the expected project. Compare Azure Migrate records against physical-server inventories, monitoring systems, backup catalogs, configuration-management databases, firewall rules, and application documentation. A server discovered after the March 31 Classic enablement block can only begin new agent-based replication through the simplified experience.
Ownership of the appliance itself requires attention. Record who patches and monitors its Windows host, who can access its configuration, which firewall endpoints it relies upon, and who will respond if replication stops. Capture the installed agent state on each source machine rather than assuming that prior discovery proves migration readiness.

Do Not Hide an OS-Lifecycle Decision Inside the Cutover​

Microsoft flags Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 as end-of-support systems whose continued use and migration plans require review. Moving one of these systems to an Azure VM does not make the underlying operating system modern.
Azure Migrate supports an OS upgrade during migration where applicable, with target options including Windows Server 2016, 2019, 2022, or 2025. That capability can reduce duplicated migration and upgrade work, but it expands the validation scope: administrators must test the operating system upgrade, drivers, installed roles, application compatibility, services, authentication, and management tooling.
WindowsForum’s coverage of the end of Windows Server 2008 Premium Assurance and the approaching Windows Server 2012/R2 Extended Security Updates deadline points to the same planning problem. A rushed lift-and-shift can preserve an unsupported application stack while merely changing its location.
For a legacy Windows server, record three separate decisions:

1. Whether its current replication path is Classic or simplified.
2. Whether the workload should be moved, rebuilt, replaced, or retired.
3. Whether the migration should retain the current OS or perform a supported target upgrade.

Those decisions can produce different schedules. A server may need urgent re-replication now but still require a later application modernization project. Conversely, an easily validated static server may complete its Classic cutover quickly while its operating-system upgrade remains a separately governed change.

The Deadline Is an Operational Boundary, Not a Target Date​

September 30 is also the retirement date for other Microsoft services discussed by WindowsForum, including Azure Virtual Desktop Classic and Azure API for FHIR. Shared dates can create competition for change windows, cloud engineers, network teams, and application testers even when the technologies are unrelated.
Azure Migrate teams should therefore set an internal Classic completion date substantially earlier than Microsoft’s retirement. That buffer is needed for failed tests, rejected application validation, networking changes, and the possibility that a supposedly usable recovery point proves too old.
The practical choice is now clear. Cut over from Classic only when the frozen May 31-or-earlier state is explicitly acceptable and thoroughly tested; otherwise deploy the simplified appliance and establish a fresh replication chain. By September 30, every physical Windows server should either be migrated successfully or have no remaining operational dependency on the Classic experience.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Migrate machines as physical servers to Azure with Azure Migrate and Modernize - Azure Migrate | Microsoft Learn

   This article describes how to migrate physical machines to Azure with Azure Migrate and Modernize.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Virtual Desktop Classic: Migrate Before September 30, 2026 | Windows Forum

   Azure Virtual Desktop (classic) retires on September 30, 2026, and most organizations should not treat the deadline as a one-click control-plane upgrade...

   windowsforum.com

 

[ChatGPT]

Azure Migrate Classic projects should cut over only machines whose May 31 recovery point has been tested and accepted as an intentionally stale migration source. Everything else should move now to the simplified experience and begin a fresh replication cycle, because Classic cannot create another recovery point and disappears from the Azure portal on September 30, 2026.
Microsoft’s retirement notice changes the calculation for VMware and physical-server migrations. This is no longer a conventional “finish before the deadline” exercise: every Classic-protected server now has a fixed recovery point, created no later than May 31, 2026, and that point grows older every day. A successful cutover remains possible until September 30, but the business and technical acceptability of the data behind it is now the central question.

The September deadline is a cutover deadline, not a replication deadline​

Azure Migrate Classic stopped allowing new Enable replication operations on March 31, 2026. Classic replication support then ended on May 31, when its final recovery points were created. Microsoft says existing Classic-replicated VMware and physical machines can still be migrated with those final recovery points through September 30, 2026.
That distinction matters. An administrator can still see a Classic machine that was already replicated and can still migrate it before the retirement date, but cannot ask Classic to capture post-May 31 changes. A file server, line-of-business application server, domain-adjacent utility VM, or physical Windows server may therefore be technically eligible for migration while being operationally unsuitable for a production cutover.
On September 30, Classic machines can no longer be viewed, managed, replicated, or migrated in the Azure portal. Projects that need to continue past that date must use Azure Migrate’s simplified experience and its new appliance.
Do not blur this schedule with separate Azure Site Recovery lifecycle and modernization discussions. The relevant decision for an Azure Migrate Classic VMware or physical-server project is specific: September 30, 2026 is the final day to migrate from the frozen Classic recovery point.

---

Make the decision server by server, not project by project​

A single migration project may contain machines with radically different answers. A decommission-bound reporting server with largely static data could be a credible Classic cutover candidate. A Windows file server, SQL-backed application tier, domain controller, management server, or VMware guest with ongoing writes usually is not.
The fastest way to regain control is to divide inventory into two tracks immediately:

1. Cut over from Classic only where the May 31 recovery point is known, testable, and acceptable to the application owner.
2. Re-replicate through the simplified experience where current data, a later migration date, or reliable rollback planning is required.

Treat “acceptable” as a documented business decision, not an assumption made by the infrastructure team. The question is not merely whether the VM will boot in Azure. It is whether the application can operate safely after losing every change made since its final Classic recovery point.
For each machine, record the final recovery-point time, data-change profile, application owner, dependency set, planned cutover window, and required recovery objective. If the owner cannot explicitly accept the age of the recovery point, that machine belongs in the re-replication track.
This is especially important for systems whose state extends beyond the guest operating system. Databases, queued work, file shares, authentication dependencies, scheduled jobs, monitoring agents, backup tooling, license services, and external integrations may all make a bootable VM an incomplete recovery.

Run the Classic cutover test before committing to it​

Classic’s remaining utility is not simply that it can still perform a migration. Its value is that teams can test whether the final recovery point produces a usable Azure workload before they spend the remaining runway on a production cutover.
Use a disciplined runbook for every machine being considered for the Classic path:

1. Identify the recovery-point boundary. Record the exact final Classic recovery-point date and time visible for the machine, then identify what data and configuration changes occurred afterward. Do not describe the source as “recent” or “mostly current.”
2. Confirm application-owner acceptance. Ask the application owner to approve the maximum data loss represented by that recovery point. If there is no owner, no documented recovery objective, or no credible way to reconcile missed changes, classify the machine for re-replication.
3. Validate Azure landing-zone readiness. Confirm that the target subscription has enough quota for the intended virtual machine, disks, networking, and any dependent services. Confirm the target virtual network, subnet, routing, DNS path, network security rules, identity access, and management tooling before beginning a test.
4. Perform a test migration or failover using isolated networking where possible. The goal is to validate the recovered operating system and application without creating duplicate production identities, names, addresses, or services on the live network.
5. Check the guest and workload, not just portal status. Verify Windows startup, device and network behavior, service state, application logs, scheduled tasks, storage visibility, authentication, certificate-dependent services, backups, monitoring, and required agent health. For a VMware guest, also validate any dependency that previously assumed vCenter-side tooling or on-premises network reachability.
6. Prove DNS and IP behavior. Decide in advance whether the migrated workload will retain a required address pattern, receive a new Azure address, or be reached through a changed DNS record. Test resolution from actual client networks, not only from an administrator’s jump box.
7. Write the rollback decision before production cutover. A rollback plan must state who can stop the Azure workload, restore on-premises service, reverse DNS or traffic changes, and communicate the outcome. If the source workload has continued changing since May 31, recognize that “rollback” may not recover the lost data created by a Classic-based cutover.
8. Schedule production only after validation passes. Freeze or quiesce application activity as appropriate, perform the migration, make the planned network and DNS changes, validate with the owner, and preserve a precise record of what was accepted.

The test should expose the uncomfortable cases early. If the recovered server works only after manual repair, depends on an unprepared route, cannot reach identity services, or carries stale business data that nobody will sign off on, the correct conclusion is not to attempt a more hurried Classic cutover. It is to re-replicate.

---

Re-replication means starting a new protection path​

The simplified experience is Microsoft’s path for new agent-based VMware and physical-server replications. Microsoft positions it as the newer platform with additional mobility-agent support, security enhancements, and newer capabilities; critically, it requires a new appliance for projects moving beyond Classic.
Administrators should not assume that a Classic machine can be transitioned in place while preserving its existing replication history. The practical planning assumption should be that moving to the simplified experience requires a new replication setup and a new initial data transfer. That is why waiting until September is risky even for workloads that are not urgent: the project needs time to deploy the new appliance, establish replication, let initial synchronization complete, test the target, and schedule the final migration.
For Windows and VMware teams, this turns the simplified experience into a capacity-planning exercise as much as a migration exercise. Inventory the machines requiring re-replication, then check whether the Azure landing zone can absorb their compute and storage requirements. Confirm network connectivity from the appliance to source systems and Azure, and verify that the workloads’ operating systems and required mobility-agent support are compatible with the newer path.
The initial replication period can become the hidden schedule driver. A large physical server, a VM with substantial attached storage, or a workload on a constrained WAN link may need more runway than its migration change window suggests. Do not leave these machines in Classic merely because they remain visible in the portal today.

DNS, identity, and stale data are where the easy plan fails​

The most dangerous Classic cutovers are not necessarily the largest machines. They are the systems that appear simple but quietly participate in a broader Windows environment.
A utility server may provide DNS forwarding, certificate enrollment, file distribution, software deployment, licensing, print services, task automation, or an application integration endpoint. Migrating a recovery point from May 31 can revive old configuration state and remove later changes that were never captured. Even if the operating system starts cleanly, the service may be inconsistent with the rest of the environment.
Avoid treating IP addressing as an afterthought. A server’s Azure network interface, route path, DNS registration, firewall rules, and client expectations must all align. If the migration requires DNS changes, lower the operational risk by documenting the old and new records, the change owner, validation clients, and the reversal action.
The same caution applies to identity. A recovered Windows server may have credentials, trust relationships, certificates, service accounts, or directory-dependent settings that made sense on May 31 but no longer reflect the production environment. This is not an argument against Classic cutover; it is an argument for treating the age of the recovery point as a first-class technical constraint.
WindowsForum’s broader 2026 retirement coverage has emphasized that lifecycle deadlines tend to cluster rather than arrive alone. Azure Migrate teams should protect time for this decision now instead of allowing the September 30 date to collide with other operating-system, infrastructure, and cloud-governance work.

---

Frequently Asked Questions​

Can Azure Migrate Classic create one more recovery point before September 30?​

No. Classic replication support ended on May 31, 2026, and its final recovery points were created then. Existing replicated machines can still be migrated from that fixed point until September 30.

Can we continue managing Classic machines after September 30?​

No. Microsoft says Classic machines will no longer be viewable, manageable, replicable, or migratable through the Azure portal after September 30, 2026.

Does moving to the simplified experience preserve our Classic replication state?​

Teams should plan as though it does not. The simplified experience uses a new appliance and a new replication setup, so the safe operational assumption is that affected machines need to establish replication again.

Which workloads are best suited to a final Classic cutover?​

Only workloads whose owners can accept the final recovery-point age, whose dependencies have been tested in Azure, and whose DNS, networking, validation, and rollback actions are documented. Static, low-change, or soon-to-retire systems may fit; actively changing production workloads often will not.
The remaining Classic window is therefore best used as a validation and execution period, not as a place to defer decisions. By separating acceptable frozen-point cutovers from workloads that need fresh replication now, Windows and VMware administrators can turn September 30 from a hard retirement surprise into a controlled final migration milestone.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Simplified experience for Azure Migrate - Azure Migrate | Microsoft Learn

   Describes the simplified experience an upgraded agent-based migration stack for physical and VMware environments

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Migrate Classic: Cut Over or Re-Replicate by September 30, 2026 | Windows Forum

   Azure Migrate projects should split physical Windows servers into two tracks immediately: cut over only machines whose final Classic recovery point is...

   windowsforum.com