Run book operations after Dynamics 365 go-live

Go-live is the start, not the finish. A Dynamics 365 system needs ongoing operation — monitoring, periodic maintenance, release-wave updates, capacity management, security review, user support. The operations run book captures who does what when. Without it, operational work happens ad-hoc; with it, the system stays healthy at a known cost.

The run book's role.

A run book is a documented set of recurring procedures, each with:

• Procedure name — what's done.
• Trigger — when it happens (daily, weekly, monthly, on event).
• Owner — accountable role / person.
• Steps — detailed how-to.
• Validation — how to know it succeeded.
• Escalation — what to do if something goes wrong.
• Last updated — when the procedure was reviewed.

The run book lives in a shared location accessible to the operations team — typically Confluence, SharePoint, an Azure DevOps wiki, or a similar collaboration tool.

Daily operations.

• Application Insights review — check tenant telemetry for errors, slow operations, anomalies. 10 minutes of dashboard glance.
• Job queue / batch failures — review failed jobs; investigate top failures.
• Integration health — verify cross-system flows running successfully. Webhook deliveries, Service Bus queues, scheduled imports.
• User support tickets — triage incoming. New tickets categorised; high-priority assigned for same-day work.
• Service health — Microsoft service status; any incidents affecting your tenant.

Total daily ops effort: 30 minutes to an hour for a mid-sized tenant in steady state.

Weekly operations.

• Capacity review — Dataverse storage, API call usage, AI Builder credit consumption. Trend against thresholds.
• License review — newly-added users; license alignment; unused licenses.
• Power Platform inventory review — new apps, flows; orphaned assets from departed users.
• Solution health review — any failed deployments; release pipeline status.
• Security review — access changes; privileged role grants; suspicious activity logs.
• Bulk delete jobs — verify scheduled cleanup is running.
• User training metrics — adoption / engagement statistics; gaps identified.

Total weekly ops effort: 1-2 hours.

Monthly operations.

• Period close support — finance close is monthly; ops team supports with batch monitoring, error resolution, escalation handling.
• Compliance review — audit logs reviewed; any access or change anomalies investigated.
• Backup verification — point-in-time restore drill to a sandbox; verify the restore process actually works.
• Performance review — slow operations; high-load pages; query analysis.
• DR scenario rehearsal — once a quarter or every 6 months; full DR procedure tested.
• Power Platform governance review — new apps deployed; compliance status; risk apps flagged.
• Vendor invoices / contract review — license invoices reconciled; contract terms revisited.

Total monthly ops effort: half a day to a day.

Release-wave operations.

Every 6 months when a Microsoft release wave (Wave 1 in April, Wave 2 in October) approaches:

• 8 weeks before: review Microsoft's published Release Plan; identify features to enable, deprecations affecting our tenant.
• 6 weeks before: install preview build in a sandbox; run regression suite; verify extensions / customisations.
• 4 weeks before: brief business stakeholders on changes; update documentation.
• 2 weeks before: training users on new features they'll see.
• Wave week: verify production update; immediate post-update validation; user-facing communication.
• 2 weeks after: post-update review; bug fixes / configurations adjusted.

Total release-wave effort: 2-3 days spread across the 8-week window.

Incident response.

When something breaks:

• Severity 1 (system unusable for many users) — immediate response. Escalate to partner; engage Microsoft Support if needed; alert leadership.
• Severity 2 (significant impact for some users) — same-day response. Internal investigation; partner engagement if needed.
• Severity 3 (minor inconvenience) — within-day response. Standard ticket handling.

Documented in the run book; everyone knows the playbook.

Quarterly operations.

• Risk register review — operational risks identified; mitigation status.
• Roadmap planning — features in pipeline; capacity for build work.
• Steering committee — leadership review of system health, costs, value.
• Annual cost review (when in scope) — license costs vs value; renegotiation opportunities.

Annual operations.

• Full DR drill — complete disaster recovery rehearsal.
• Security audit — full review of access, configurations, policies.
• Vendor performance review — partner, ISV evaluations.
• Strategic review — does the system still fit the business? Major changes warranted?
• License optimisation — comprehensive license audit (see the license optimisation guide).

Who runs operations.

• Customer's internal IT — typically owns operations day-to-day.
• Implementation partner — provides escalation and specialist support.
• Microsoft Support — for platform-level incidents (often escalated through the partner).

Roles documented in the run book — who calls Microsoft, who calls the partner, who handles incidents.

Common pitfalls.

• No run book — operations happen ad-hoc; key procedures rely on tribal knowledge.
• Run book without ownership — procedures listed but no clear owner; nothing happens.
• Run book unmaintained — procedures from go-live still listed; current procedures undocumented.
• Tool sprawl — different procedures live in different places; ops team can't find them.

Operational reality. Run book operations are the unglamorous infrastructure of running a Dynamics 365 system well. Build the run book during hypercare; mature it across the first six months; treat it as a living document. The cost is small; the system's reliability over years is substantial.