Microsoft 2026 End-of-Support Timeline: The Definitive Migration Guide for SharePoint, Exchange, and OOS Users

If you are an IT Director or CIO managing on-premise Microsoft servers, you have a cluster of dates converging between mid-2025 and the end of 2026 that will force infrastructure decisions. This guide consolidates the exact timelines, the real architectural risks of migrating from on-premise to cloud, and the gaps that generic migration tools leave behind.

The Master Timeline: When Does Your Infrastructure Lose Support?

Microsoft publishes end-of-support dates across multiple lifecycle policy pages. Here is the consolidated view, with sources.

October 14, 2025: Exchange Server 2016 & 2019

• Exchange Server 2016: End of Extended Support. All security updates and technical support cease.
• Exchange Server 2019: End of Mainstream Support. Extended Support continues until October 14, 2025 as well — both versions reach their final support dates on the same day.

Source: Microsoft Lifecycle Policy — Exchange Server

April 2026: SQL Server 2012 ESU Final End

• SQL Server 2012: If you purchased Extended Security Updates, the final ESU year ends. No further patches of any kind.

July 14, 2026: SharePoint Server 2016 & 2019

• SharePoint Server 2016: End of Extended Support.
• SharePoint Server 2019: End of Extended Support.
• Project Server 2016 / 2019: End of Extended Support.

Source: Microsoft Lifecycle Policy — SharePoint Server 2016, SharePoint Server 2019

December 31, 2026: Office Online Server

• Office Online Server (OOS): End of support. If you host Excel workbooks, render documents in browser, or use Power BI Report Server (PBIRS) on-prem, this is the end. There is no OOS successor for on-premise.

Migration Complexity Matrix

The table below maps each workload to its end-of-support date, primary migration target, Microsoft-provided tooling, and key risk areas.

The "Do Nothing" Option: Why ESU Is Expensive, Not Safe

Some organizations plan to purchase Extended Security Updates (ESU) to buy time. This is a valid short-term tactic, but it has compounding costs and diminishing returns.

1. The Cost Multiplier

ESU pricing increases each year, with each successive year costing more than the last. You are paying a growing premium for a product that receives only critical security patches — no feature updates, no bug fixes, no performance improvements.

2. The Talent Problem

The engineering talent pool for SharePoint 2016 on-premise administration, Exchange 2019 on-premise troubleshooting, and Dynamics AX maintenance is shrinking. Engineers are retraining for Azure, Power Platform, and Microsoft 365 cloud administration. If your Exchange Server crashes in 2027 after support has ended, finding someone with current on-prem expertise — at any price — becomes a real staffing risk.

3. Compliance and Insurance Exposure

Running business-critical workloads on unsupported software creates audit findings. Cyber insurance policies increasingly exclude breaches on systems past end-of-support. This is not a hypothetical — it is a question your auditors will ask.

The 3 Architectural "Gotchas" of On-Prem to Cloud Migrations

Moving from on-premise to cloud is not a copy-paste operation. The architectures are fundamentally different. These are the three most common failure points.

Gotcha #1: The Storage Limit Problem

On your local SQL Server, you might have terabytes of storage. Organizations commonly store 50MB PDFs, high-res images, and large attachments directly in the database.

Microsoft Dataverse enforces storage limits that are significantly tighter than a self-managed SQL Server. Attachment size limits vary by entity type and transaction method — note attachments, email attachments, and file columns each have different thresholds (commonly 5MB for notes by default, configurable up to 128MB for file columns in newer configurations). A migration that does not account for these differences will fail silently or produce errors at scale.

Detection method: Before migration, query your source database for all attachments exceeding the target platform's limits, grouped by entity type. This gives you a count and total size of records that need special handling.

Remediation pattern: Large files can be offloaded to Azure Blob Storage (or equivalent object storage) during migration, with a URL reference inserted back into the CRM record. This preserves access while staying within Dataverse storage limits.

Gotcha #2: The Identity Mapping Problem (Windows Auth vs. Entra ID)

On-premise SharePoint uses Windows Authentication (Active Directory). The cloud uses Entra ID (formerly Azure AD). These user identities do not map 1:1 automatically.

• DOMAIN\jdoe is not the same as john.doe@company.com.

If you use a tool that does not handle identity translation, you end up with thousands of files where the "Created By" field reads "System Account" because the tool could not resolve the on-prem identity. You lose your audit trail.

Detection method: Export a list of all unique Created By and Modified By values from your SharePoint content databases. Cross-reference against your Entra ID directory. Any identity without a match is an orphan that needs manual mapping.

Remediation pattern: Build a User Mapping Matrix before migrating any content. This is a lookup table that maps every on-premise identity (DOMAIN\username) to its cloud equivalent (user@domain.com). The migration process uses this matrix to rewrite metadata on every migrated object.

Example mapping schema:

| Source Identity (AD)   | Target Identity (Entra ID)  | Status    |
|------------------------|-----------------------------|-----------|
| ACME\jdoe              | john.doe@acme.com           | Matched   |
| ACME\msmith            | (departed - no cloud ID)    | Map to admin |
| ACME\svc_sharepoint    | (service account)           | Map to system |

Gotcha #3: The "Orphaned" Data Problem (Parent-Child Dependencies)

This is specific to Dynamics 365 migrations. Records in Dynamics have parent-child relationships — a Note is attached to a Contact, an Activity is linked to an Opportunity. If the child record (Note) arrives in the cloud before its parent record (Contact) has been created, the system rejects it: "Parent record not found." The child record is silently dropped.

Standard bulk-import tools process records in flat batches without dependency awareness. This is where data loss happens.

Remediation pattern — Upsert & Retry logic:

for each record in migration_batch:
    try:
        upsert(record, target_system)
    except ParentNotFound:
        add_to_retry_queue(record)

while retry_queue is not empty:
    for each record in retry_queue:
        try:
            upsert(record, target_system)
            remove_from_retry_queue(record)
        except ParentNotFound:
            increment_retry_count(record)
            if retry_count > MAX_RETRIES:
                log_failure(record)
                remove_from_retry_queue(record)

This pattern ensures that records whose parents have not yet been created are re-queued and retried after later batches have run, rather than being dropped on first failure.

Microsoft's Native Migration Tooling: What It Does and Where It Stops

Before evaluating third-party options, understand what Microsoft provides natively.

SharePoint Migration Tool (SPMT) and Migration Manager

• Handles file migration from SharePoint on-prem to SharePoint Online
• Supports incremental migration (delta passes)
• Does not migrate custom InfoPath forms, SharePoint Designer workflows, or sandbox solutions
• Identity mapping capabilities are limited — complex AD-to-Entra mappings often require manual CSV preparation
• Throttling is enforced; large migrations may take days without parallelization

Exchange Hybrid Deployment

• Microsoft's recommended path for Exchange migrations
• Allows staged mailbox moves with coexistence (on-prem and cloud users can coexist during migration)
• Public folder migration has separate tooling and is a common failure point
• Free-busy sharing, calendar delegation, and mail-enabled groups require careful cutover planning

Dynamics Data Migration Framework / Lifecycle Services

• Provides entity-level import/export for Dynamics 365
• Does not handle parent-child dependency ordering natively
• Custom plugins and workflows may not transfer; they require manual rebuild in the target environment
• No built-in large-attachment offloading

Third-Party Tooling Landscape

Tools like ShareGate, AvePoint, and Metalogix (now Quest) offer SharePoint migration capabilities beyond SPMT — including workflow documentation, permission analysis, and pre-migration reporting. For Exchange, BitTitan MigrationWiz and Quest On Demand Migration are commonly used for large-scale mailbox moves. Each has trade-offs in cost, API throttling behavior, and metadata fidelity.

A neutral evaluation of these tools against your specific workload is worth the time before committing to any path.

Choosing Your Migration Approach

There are two broad categories.

Self-serve tooling: You purchase a migration tool license and assign your internal IT team to execute. Costs look low upfront ($50–$500/month for licensing). The hidden cost is your team's time learning API limits, throttling behavior, data mapping edge cases, and debugging failures. For small, simple environments (< 1TB, no custom workflows, clean identity mapping), this can work.

Engineer-led service: You engage a team that has executed this type of migration repeatedly and handles the data mapping, identity resolution, dependency ordering, and error remediation. The cost is higher upfront but the execution risk is significantly lower, particularly for environments with complex customizations, large data volumes, or tight downtime windows.

The right choice depends on your environment complexity, internal team capacity, and risk tolerance — not on which option a vendor tells you to pick.

The Cost of Waiting

The supply-demand math is straightforward. The number of organizations running SharePoint 2016, Exchange 2019, and Dynamics on-premise instances exceeds the available pool of experienced migration engineers and consultants. As the 2025 and 2026 deadlines approach, demand for migration services will spike. Rates increase. Timelines stretch. Availability shrinks.

Starting assessment and planning now — even if execution is scheduled for later — is the single highest-leverage action you can take.