How to keep up with Dynamics 365 and Copilot updates (without drowning)

The short answer: Track two clocks, not one. Release waves (twice a year: April–September and October–March) tell you what Microsoft plans to ship. Service updates (four a year, with autoupdates in February, April, July and October) are what actually change your Dynamics 365 Finance & Operations environment. Follow the release plan for the first, the “what’s new or changed” pages and the Message Center for the second, and give yourself thirty minutes a month on a recurring calendar invite. That’s the whole system.

Every D365 team I’ve worked with has the same background anxiety: the platform moves, and nobody’s quite sure whether they’re behind. It isn’t a lack of information — it’s the opposite. Release plans, “what’s new” pages, blogs, the Message Center, preview announcements, Copilot documentation that quietly changes a label from preview to GA. Four hundred pages of truth, and no idea which twelve apply to you.

So here’s how I actually keep track — and where the noise is safe to ignore.

The two clocks

The single most useful mental correction is separating these.

Clock one: release waves

Release waves are the announcement layer. They’re where you learn that an agent is coming, or that a module is being modernised. They’re planning input for your roadmap.

They are not a delivery guarantee, and Microsoft says so plainly. Release plans describe functionality that may not have been released yet, and delivery timelines and projected functionality may change or may not ship. Anyone building a business case on a wave-plan item is building on an intention.

The habit that helps: use the Release planner and filter to the products you actually run. Reading the whole Dynamics 365 plan is a waste of an afternoon. Reading the twenty rows relevant to your Finance and Supply Chain footprint is twenty minutes well spent, twice a year.

Clock two: service updates

This is the clock that changes your system.

The mechanics that matter for planning:

• Each release has a preview window, then general availability for self-update, then two autoupdate windows four weeks apart. You choose which window suits your validation cycle.
• Sandbox autoupdate happens seven days before the production update. That week is your regression window. It’s the most important date in the whole cycle and the one most often discovered by accident.
• You can pause, but only one consecutive update, applied to your UAT sandbox, production, or both. After the pause window, Microsoft applies the latest update based on your Lifecycle Services configuration.
• End of service is real. Each version has an end-of-service date after which Microsoft doesn’t investigate or fix issues, and support can’t take cases. Falling behind doesn’t just mean missing features — it means losing support.

To make this concrete: as I write in August 2026, version 10.0.48 is the current generally available release for self-update, and 10.0.49 — a major release — is in its preview window ahead of general availability in September. If you don’t know which of those numbers describes your environment right now, that’s the first thing to find out.

Practical move: put your sandbox autoupdate dates for the next twelve months in a shared calendar today, each with a seven-day regression block after it. Everything else in this article is optional; this one isn’t.

Where the reliable information lives

Five sources. That’s genuinely all you need.

1. The release plans on Microsoft Learn. Two visits a year, filtered to your products. Once when the wave plan publishes, once mid-wave to see what actually landed.

2. The “what’s new or changed” pages. Separate pages per app — Finance, Supply Chain Management, Commerce, Human Resources — plus platform updates and Lifecycle Services. This is the definitive per-version record and the correct input to your regression testing. The release plan says what’s planned; these say what shipped.

3. The Microsoft 365 Message Center. In the admin center under Health → Message center. Upcoming changes, new and changed features, planned maintenance, required actions. Each admin can set preferences and opt into a weekly digest — do that, because a weekly summary email is far more sustainable than remembering to check a portal. Service health for Dynamics 365 and Power Platform lives in the Power Platform admin center.

4. The official blogs. The Dynamics 365 blog and the Power Platform blog. Lower signal density than the docs, but they’re where the why gets explained — direction, intent, context that documentation doesn’t carry.

5. The docs for the specific features you depend on. This is the one people skip, and it’s the highest-value habit on the list. If your business relies on generative help, or the reconciliation agent, or the ERP MCP server, put those three pages on a quarterly re-read. Preview labels move. Prerequisites change. Retirement dates appear — the older static Dynamics 365 ERP MCP server, for instance, is documented as retiring on 1 October 2026, which is exactly the kind of thing you want to learn from a doc page rather than from an outage.

Why Copilot needs its own attention

Copilot and agent features don’t move on the F&O clock. They sit across three moving platforms — finance and operations apps, the Power Platform, and Copilot Studio — so a capability can change without a service update touching your environment.

Three specific things to re-check each wave:

Preview labels. Preview, production ready preview and generally available are three different commitments. Features move between them. Anything you’ve built a process around should have its label re-verified, not assumed.

Prerequisites and version floors. Copilot features carry minimum versions — agent management needs F&O 10.0.44 or later; the ERP MCP server needs 10.0.47 or later (or specified quality updates on 10.0.45/10.0.46). Those floors rise. Staying current is what keeps the AI roadmap available to you at all.

Billing and licensing. Copilot Studio’s billing currency changed from messages to Copilot Credits in September 2025; MCP tool calls bill differently depending on whether the agent runs in Copilot Studio or elsewhere. If agents are in production, licensing changes are cost changes.

If you want the current state of the F&O Copilot picture, I keep what Copilot actually does in F&O and the 2026 agentic shift updated as things move.

The system: thirty minutes a month

Here’s what I’d actually put in a calendar. It’s deliberately small, because a system nobody follows is worse than no system.

Monthly — 30 minutes

• Skim the Message Center digest. Anything flagged as requiring action goes straight into your backlog with an owner.
• Check your environments’ current versions in LCS against the release schedule. Are you where you thought you were?
• Re-read the doc page for one feature you depend on. Rotate through them.

Per service update — half a day, four times a year

• Read the “what’s new or changed” page for your version.
• Run your regression suite in the sandbox during the seven-day window before production.
• Note anything Copilot-related that changed behaviour.

Per release wave — two hours, twice a year

• Filter the release planner to your products.
• Pull out the five items that would actually matter to your business.
• For each: what’s the label, which wave, what would it require of us?
• Decide what to pilot in early access, and book it.

Annually

• Review agent and Copilot governance: who owns each agent, what roles they hold, what the activity logs show, what it all costs.

That’s it. About eight hours a year, and it replaces the two failure modes I see most: teams that ignore updates until something breaks, and teams that read everything and act on nothing.

The clever bit: build an agent that reads the docs for you

Here’s a genuinely good use of the technology to keep up with the technology — and, conveniently, an excellent first Copilot Studio project.

Microsoft publishes a Learn MCP Server that gives AI agents access to current Microsoft documentation, and Copilot Studio can connect to an MCP server as a tool. The Microsoft Learn Docs MCP connector is certified and requires no authentication. There’s even a dedicated Microsoft Learn article on getting started with the Learn MCP Server in Copilot Studio.

So you can build a small internal agent that:

• Answers “what are the current prerequisites for the D365 ERP MCP server?” from live documentation rather than from someone’s memory of a blog post.
• Runs on a weekly schedule and posts a short summary to a Teams channel.
• Is grounded in Microsoft’s actual docs, so it cites its sources and doesn’t invent features.

It’s a couple of hours’ work, it’s genuinely useful, and it’s the best possible way to learn the platform — you build the thing that keeps you current on the platform you’re trying to stay current with. My walkthrough is here: how to build your first agent in Copilot Studio.

One honest caveat: an agent that reads documentation is a research assistant, not a change-management process. It won’t tell you your sandbox autoupdate is next Tuesday. Keep the calendar.

Or hand the tracking to someone else

Staying current is exactly the kind of work that’s important, never urgent, and therefore never done. If you’d rather have a Microsoft-certified consultant watch the release plans, flag what actually affects your environment, and handle the regression testing around each service update, that’s a straightforward ongoing arrangement — and usually far cheaper than the update that catches you unprepared.

See Dynamics 365 Finance & Operations or book a free call.

Verified against Microsoft’s documentation in August 2026. Release schedules and version numbers move — always confirm the current dates for your own environments in Lifecycle Services.