Administrators relying on Azure Migrate Classic to move physical Windows servers face a critical decision: act now on two distinct paths, or risk being locked out of the migration process by September 30, 2026. The platform stopped creating new recovery points on May 31, meaning every replica currently sitting in an Azure Migrate project is frozen in time—and growing staler by the day.

Microsoft’s documentation, updated earlier this year, lays out a hard deadline: the Classic replication appliance retires on September 30, 2026. After that date, no cutover, no management, no access to Classic instances through the portal. For physical-server migrations that still depend on Classic, the window isn’t just closing—it’s already half shut.

The Hidden Urgency: Recovery Points Frozen Since May

It’s easy to misread the September 30 date as “I have until fall.” That’s dangerously incomplete. The real deadline landed on May 31, when Azure Migrate stopped producing new recovery points for Classic replications. As of late July, even the youngest possible replica is nearly two months old—and that gap only widens.

The March 31 block on enabling new Classic replications for physical servers meant that any workload discovered after that date never had a chance to enter the Classic pipeline. But existing replications, while still supported for migration, are no longer synchronizing. They are static snapshots, not continuously updated mirrors.

Microsoft warns that after September 30, you will no longer be able to view, manage, replicate, or migrate affected Classic machines in the Azure portal. The retirement isn’t a service degradation; it’s a complete removal of the management path.

Two Paths Diverge: Cutover vs. Re-Replication

Every server still tied to a Classic replication must immediately be sorted into one of two tracks. The first is a tightly controlled final migration using the existing frozen recovery point—if that point is demonstrably usable. The second is a re-replication through the new, simplified Azure Migrate appliance, which requires a fresh agent installation and a new replication lifecycle.

This isn’t a preference exercise; it’s a governance decision. Choosing the wrong track can mean data loss, compliance exposure, or a migration that fails validation when it’s too late to pivot.

Option A: Cut Over from the Frozen Classic Replica

Cutting over from Classic is defensible only when the final recovery point represents a state the business can knowingly deploy. This might be the case for a truly static server—think a domain controller whose directory replicates elsewhere, or a web front end that pulls dynamic content from an external database. It could also apply to a machine that stopped receiving changes before May 31 because it was decommissioned or disconnected.

But “usable” requires proof, not assumptions. Microsoft’s tooling won’t tell you whether the replica boots cleanly, whether application services start, or whether dependent systems still accept its identity. Administrators must run a test migration in a non-production network and validate:
- Operating system boot and driver compatibility
- Windows service start behavior
- Application component connectivity (databases, message queues, APIs)
- Authentication and authorization (domain membership, certificates, service accounts)
- DNS and firewall rule alignment with the current production environment

A successful test migration confirms the image is recoverable; it does not guarantee the recovered data is fit for purpose. The business owner must accept the data gap explicitly. Records created or changed after May 31 will be absent unless reconstructed through a separate process—log shipping, backup restore, or manual re-entry.

Option B: Re-Replicate Using the Simplified Appliance

If any of these conditions apply, the server belongs on the simplified appliance:
- The workload has changed since May 31 (application data, OS patches, configuration).
- The Classic recovery point fails test validation or has never been tested.
- The server was discovered after March 31, 2026 (the date Classic enablement was blocked).
- The migration schedule extends past September 30, 2026.
- The application owner cannot accept the frozen data state.

Re-replication is not a one-click conversion. It means deploying a new replication appliance—a Windows machine in the on-premises environment that runs a PowerShell script to register with the Azure Migrate project—installing the Mobility Service agent on the source server, and beginning a brand-new replication cycle. The old Classic appliance and its recovery point can remain in place as a fallback until the new path is proven with a test migration of its own.

Microsoft’s guidance emphasizes that the simplified appliance is the only supported path for all new agent-based migrations and must be used for any workload that requires current data or ongoing replication management past the retirement date.

Who Should Cut Over – And Who Must Start Over

As you inventory your Azure Migrate projects, classify each machine by its recovery-point date and its operational state since May. A server that was part of a financial batch run on June 2 almost certainly has data written after the freeze; its Classic replica is obsolete. A print server with no configuration changes might be fine. But be ruthless: if there’s any doubt, re-replicate.

WindowsForum’s analysis of the timeline adds a critical nudge: even the newest possible Classic recovery point is now weeks old, making data age the first decision gate, not appliance installation effort. Their recommendation aligns with Microsoft’s own accelerated timeline—treat Classic as a frozen recovery artifact, not an active replication channel.

Administrators should also consider the server’s Windows Server lifecycle. Microsoft flags Windows Server 2008, 2008 R2, 2012, and 2012 R2 as end-of-support systems. A lift-and-shift migration to Azure doesn’t modernize the OS. Azure Migrate does offer an OS upgrade during migration (to Windows Server 2016, 2019, 2022, or 2025), but that adds validation complexity—drivers, application compatibility, service startup, and management tooling all need re-testing. If you’re already re-replicating, it may be the right moment to upgrade the target OS, but don’t conflate the two decisions. Record them separately: migration path (cutover vs. re-replicate), workload disposition (move, rebuild, retire), and target OS version.

The Action Plan: From Audit to Final Migration

Facing a hard September 30 cutoff, the only safe approach is to treat the date as an operational boundary—not a maintenance window. The portal will lock you out; there is no grace period. Build an internal deadline weeks earlier to absorb failures.

Step 1: Full Inventory Audit

List every Azure Migrate project, subscription, and associated Classic replication appliance. For each source machine, record:
- Final Classic recovery-point date (if applicable)
- Whether the recovery point has been test-migrated
- Application owner and business function
- Dependency map (other servers, network segments, certificates)
- Current replication status and agent version
- Target Azure region, virtual network, and VM size

Step 2: Triage into Two Tracks

Using the cutover-vs-re-replicate criteria, assign each server to a track. Mark any machine without a named owner or with unresolved dependencies as “re-replicate” until those gaps are closed. A server that merely appears in the portal but whose operational status is unknown is not a candidate for a rushed cutover.

Step 3: Validate the Cutover Candidates

For servers earmarked for Classic cutover, perform a test migration in an isolated network. Validate boot, service health, application connectivity, and security controls. Get written acceptance from the business owner on the data gap. Only after that should you schedule the final migration—and be prepared to roll back if the Azure VM fails acceptance testing.

Step 4: Set Up the Simplified Appliance for Re-Replications

Download the PowerShell installer from the Azure portal, prepare a dedicated Windows machine meeting hardware and software requirements, and run the registration script. After the appliance registers, install the Mobility Service on each source server. Begin replication and run a test migration before declaring the new path ready.

Step 5: Execute and Clean Up

For Classic cutovers, complete the migration before your internal deadline. Then select “Complete migration” in the portal to clean up replication state. For simplified appliance migrations, after final cutover, also complete the migration to stop billing and release resources.

Step 6: Don’t Forget the Orphans

Cross-check inventories against backup catalogs, configuration databases, and network scans. A physical server that never appeared in Azure Migrate because it was missed or discovered after March 31 still needs a home. It can only be migrated via the simplified appliance.

Why September 30 Isn’t a Target – It’s a Hard Stop

The retirement of Azure Migrate Classic isn’t happening in isolation. Other Microsoft services share the September 30, 2026 date—including Azure Virtual Desktop Classic and Azure API for FHIR—which can create resource contention in organizations managing multiple cloud transitions. Network engineers, identity teams, and change advisory boards may already be stretched thin.

For physical-server migrations, the message is unambiguous: every server still linked to Classic must exit that path by September 30. After that, the portal simply won’t offer the option to cut over. The environment will disappear from view.

The most important takeaway for administrators is to stop viewing Classic as a pending migration and instead see it as a completed snapshot that either gets promoted to production or discarded. The clock is no longer ticking toward a deadline; it’s measuring the staleness of data that can never be refreshed within the Classic framework. The only acceptable response is an immediate, surgically precise plan—cut over what you can prove is good, and re-replicate everything else before the final door closes.