Access End of Life? Understanding Microsoft's Roadmap and Your Options

If you search "Microsoft Access end of life," you'll find a mix of speculation, outdated information, and vendor marketing designed to create urgency. Some articles declare Access dead. Others insist Microsoft will support it forever. Neither extreme is accurate.

The reality is more nuanced and more challenging to plan around. Microsoft hasn't announced an Access end-of-life date. But the signals from Redmond over the past several years point clearly in one direction, and organizations running critical processes on Access need to understand what those signals mean for their planning horizons.

This post explains what Microsoft has actually said, what their actions indicate, and what options you have for addressing the strategic risk Access now represents.

What Microsoft Has Actually Announced

Let's start with facts.

Access remains in Microsoft 365. As of 2026, Access is included in Microsoft 365 Apps for Enterprise and several other Microsoft 365 subscription plans. Microsoft has not announced plans to remove it.

Access exists. Microsoft released Access as part of Office LTSC 2024, their perpetual license offering for organizations that don't use subscription licensing. This provides a supported version for the current long-term servicing channel.

Runtime distribution continues. The Access Runtime, which allows users without full Access licenses to run Access applications, remains available for download and distribution.

No published end-of-life date. Unlike products Microsoft has formally deprecated (such as Internet Explorer or various legacy Windows versions), Access has no official end-of-support or end-of-life announcement.

If you stopped reading here, you might conclude there's nothing to worry about. But the official announcements tell only part of the story.

What Microsoft's Actions Indicate

While Microsoft hasn't announced Access deprecation, their strategic investments and product direction communicate volumes.

Development has slowed dramatically. Compare Access's feature evolution to Excel, which receives continuous investment in areas like dynamic arrays, Python integration, and collaborative features. Access updates have been primarily maintenance-focused: security patches, compatibility fixes, and minor refinements. The last transformative Access feature (web apps via SharePoint) was introduced over a decade ago and has since been deprecated.

Access web apps were discontinued. In 2017, Microsoft announced that Access web apps and web databases in SharePoint would be retired. Organizations that built on this "modern" Access platform had to migrate away. 

Power Platform is the stated direction. Microsoft's strategic investment in low-code/no-code development flows entirely through Power Platform: Power Apps, Power Automate, Power BI, and Dataverse. When Microsoft executives discuss empowering citizen developers or modernizing business applications, they reference Power Platform exclusively. Access is absent from these conversations.

Documentation and training emphasize alternatives. Microsoft's official guidance for new projects consistently points toward Power Apps for forms-over-data applications, Power BI for reporting, and Azure SQL or Dataverse for data storage. Access documentation exists but isn't updated with the same frequency or prominence.

Copilot integration is absent. As Microsoft embeds AI capabilities across their product portfolio, Access has received no Copilot features. Excel has Copilot. Word has Copilot. PowerPoint has Copilot. Power Apps has Copilot. Access does not, and there's no announced roadmap for it.

The pattern is clear: Access is being maintained, not developed. It's supported, but not invested in. Microsoft isn't killing Access. They're letting it age out naturally while directing new development elsewhere.

The Strategic Risk Calculation

For IT leaders, the question is whether it's prudent to continue operating critical business processes on a platform with this technology trajectory.

Consider the compounding risks:

Talent availability is declining. Developers entering the workforce aren't learning Access or VBA. The pool of people who can maintain and enhance Access applications shrinks every year. The developers who built your current applications may retire before the applications do and finding replacements will become increasingly difficult and expensive.

Integration capabilities are falling behind. Modern business processes require integration with cloud services, APIs, and real-time data sources. Access's integration capabilities, while functional, haven't kept pace. Connecting Access to contemporary services requires workarounds, middleware, or custom code that adds complexity and maintenance burden.

Security expectations have evolved. Regulatory requirements around data protection, access controls, and audit trails have intensified. Access applications built even five years ago likely don't meet current compliance standards for sensitive data. Retrofitting security into Access applications is possible but more expensive than modernizing them entirely.

Cloud-first strategies leave Access behind. Organizations moving to cloud-first or cloud-only infrastructure face awkward decisions about Access applications. They don't run natively in Azure. They don't integrate cleanly with Microsoft 365's collaboration features. They represent exceptions in modern environments.

The "someday" problem becomes urgent suddenly. Organizations that defer Access modernization find themselves forced into rushed migrations when circumstances change; for example, an acquisition requiring system consolidation, a compliance audit identifying gaps, a developer departing, or a Microsoft announcement that finally does set a deprecation date. Planning proactively is always less expensive than reacting urgently.

Even without a formal end-of-life announcement, Access represents growing strategic risk that compounds the longer it remains unaddressed.

The Perpetual License Question

Some organizations believe perpetual licensing provides Access insulation. "We'll just keep using Access 2024 forever." This deserves examination.

Perpetual licenses allow continued use of a specific software version. They don't guarantee compatibility with evolving infrastructure. As Windows evolves, as database engines change, as security requirements tighten, a frozen Access version becomes increasingly isolated. You can still run it but connecting it to everything else becomes progressively harder.

Perpetual licenses also don't address the talent or capability gaps. You're committing to a technology ecosystem. If that ecosystem isn't receiving investment, your commitment carries hidden costs.

For applications that require no change: archival systems, read-only historical data access, isolated departmental tools, perpetual licensing may be ok. For applications that support active business processes requiring ongoing modification and integration, it's a deferral strategy.

Your Four Options

Organizations running Access applications have four basic paths forward. Each involves trade-offs.

Option 1: Maintain and Monitor

What it means: Continue running Access applications as-is while monitoring Microsoft's roadmap for changes. Invest in maintenance and minor enhancements but avoid major development. Plan to migrate eventually but don't commit to timelines.

When it makes sense: Applications are stable, low-criticality, and have limited users. The organization has other priorities consuming IT resources. Access developers are still available internally or through contractors.

The risks: Deferred costs compound. Sudden forcing functions (compliance changes, key person departures, acquisition activity) can turn gradual migration into emergency migration. Technical debt accumulates.

Realistic assessment: This is the default choice for many organizations. Not because it's optimal, but because it requires no immediate action. It trades future flexibility for present convenience.

Option 2: Migrate to Power Platform

What it means: Rebuild Access applications using Microsoft Power Apps (for forms and UI), Power Automate (for workflows), and Dataverse or SharePoint (for data storage). Stay within the Microsoft ecosystem but on their current strategic platform.

When it makes sense: Applications are relatively simple forms-over-data scenarios. Users are already familiar with Microsoft 365. The organization has invested in Power Platform licensing. Applications don't require complex custom logic or high-performance data operations.

The limitations: Power Apps is not a direct replacement for Access. Complex VBA logic doesn't translate easily. Reporting capabilities differ A LOT. Licensing costs can surprise orgs accustomed to Access being "included." Performance with large datasets requires careful architecture. Some applications simply aren't good candidates.

Realistic assessment: Power Platform works well for certain application profiles, particularly simpler applications that align with its strengths. But "migrate everything to Power Apps" oversimplifies the decision. Evaluate each application individually.

Option 3: Migrate to Custom Web Apps

What it means: Rebuild Access applications as modern web applications using frameworks like Blazor, React, Angular, or others. Data moves to SQL Server or Azure SQL. Business logic converts to C#, TypeScript, or another modern language.

When it makes sense: Applications are complex, business-critical, or require capabilities beyond low-code platforms. The organization needs full control over architecture and functionality. Apps require high performance, complex integrations, or sophisticated user experiences. Long-term maintainability and scalability matter.

The investment: Custom development requires more upfront investment than low-code alternatives. Organizations need development resources (internal or external) with appropriate skills (C#, Blazor, etc.) Planning and discovery phases matter a lot.

The payoff: Modern web apps offer performance, security, and user experience that Access cannot match. They integrate naturally with cloud infrastructure. They can be maintained by a broader pool of developers. They scale to enterprise requirements. The total cost of ownership, calculated over a reasonable horizon, often favors modernization despite higher initial investment.

Option 4: Replace with Commercial Software

What it means: Retire the Access application entirely and adopt commercial off-the-shelf software (SaaS or on-premises) that addresses the same business need.

When it makes sense: The Access application was a custom-built version of standard business functionality such as inventory management, CRM, project tracking, or similar. Commercial options have matured to cover requirements that at one time justified custom development. The organization prefers buying over building.

The trade-offs: Commercial software rarely matches custom application functionality exactly. Business processes need to adapt to the software rather than vice versa. Subscription costs replace development costs. Customization options vary by vendor.

Realistic assessment: Sometimes the right answer isn't migration. It's retirement. Evaluate whether the business process still requires a custom app or whether commercial alternatives close the gap.

Making the Decision

Choosing among these options requires an assessment of several factors:

Application complexity: How much business logic is embedded? How many forms, reports, and queries exist? How many lines of VBA code? Simple applications have more options. Complex applications narrow the viable paths.

Business criticality: What happens if the application fails? What processes depend on it? What's the cost of disruption? Critical applications justify greater modernization investment.

Data sensitivity: What regulatory requirements apply? What audit capabilities are needed? What access controls must exist? Compliance requirements often eliminate certain options.

Integration requirements: What other systems must the application connect with? How will those systems evolve? Isolated apps differ from integrated apps.

User expectations: What experience do users expect? Are they satisfied with Access, or frustrated by its limitations? Modernization often delivers user experience improvements that drive adoption.

Available resources: What capabilities exist for migration? What budget is available? What timeline is realistic? Resource constraints shape what's achievable.

Strategic direction: Where is the organization heading technologically? What platforms are being standardized? How does this application fit the broader architecture?

No single option is universally correct. The right choice depends on your specific app portfolio, organizational context, and strategic priorities.

The Assessment Starting Point

Regardless of which path you ultimately choose, the starting point is the same: understand what you actually have.

Most organizations significantly underestimate Access application complexity. What appears to be a simple database often contains years of accumulated business logic, undocumented dependencies, and critical functionality that users take for granted. Before committing to any option, inventory your Access applications thoroughly:

• How many applications exist across the organization?
• Who uses each application, and for what processes?
• What business logic is embedded in queries, VBA, and forms?
• What data sensitivity and compliance requirements apply?
• What integrations exist with other systems?
• Who maintains each application today, and what happens when they leave?

This assessment reveals the true scope of your Access estate and enables informed decision-making about each application's future. 

GAPVelocity AI offers a free assessment tool which you can download here. 

What Should You Do with MS Access?

Microsoft hasn't announced Access end of life. They probably won't for years, if ever. But waiting for an official announcement means waiting until the platform's decline creates unavoidable urgency which is exactly the wrong time to begin a migration.

The better approach is treating Access as a managed risk rather than a stable platform. Assess your applications. Understand their complexity and criticality. Develop a roadmap that addresses highest-risk applications first. Execute migration on your timeline, not in response to external forcing functions.

Access served organizations well for decades. But the signals from Microsoft are clear: the future runs on different platforms. Organizations that recognize this and plan accordingly will modernize on their terms. Those that wait will eventually modernize on someone else's.

Need help assessing your Access application portfolio? GAPVelocity AI provides comprehensive application assessments that inventory complexity, map business logic, and evaluate modernization paths, giving you the information you need to make confident decisions. Start your assessment.