# Dynamics 365 Solution Blueprint: [Programme name]

> Solution blueprint for a Microsoft Dynamics 365 and Power Platform implementation, organised to
> support the Success by Design framework in the Dynamics 365 implementation guide on Microsoft Learn
> (framework page dated 4 August 2026): phases Discover, Initiate, Implement, Prepare and Operate;
> the Solution Blueprint Review, Implementation Reviews and the Go-live Readiness Review; findings
> classed as assertions, risks and issues. It covers programme strategy, solution scope, business
> process and application strategy, tenant and environment strategy, ALM, data, integration,
> security, analytics and AI, testing, performance, cutover and operations. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use this document as the input pack for the Solution Blueprint Review and keep it current: it
  becomes the living blueprint for the programme, re-reviewed at each phase gate.
- Start the blueprint in the Discover phase, while the high-level solution approach is shaped. Do
  not wait for detailed design: the point is to surface risk while change is still cheap.
- Each strategy section states the decision, the reasons and the open items. Detailed designs live in
  linked documents and are summarised here, not copied.
- Record every review finding in section 15 with its type (assertion, risk, issue), recommendation,
  owner and the success measure it affects.
- Related documents: Fit-gap analysis (`architecture/fit-gap-analysis`), Integration design
  (`architecture/integration-design`), Data migration strategy (`architecture/data-migration-strategy`),
  Low-code platform governance (`architecture/low-code-platform-governance`), Cutover plan
  (`project/cutover-plan`), Go-live readiness review (`project/go-live-readiness-review`), Salesforce
  solution design (`architecture/salesforce-solution-design`) and SAP S/4HANA solution design
  (`architecture/sap-s4hana-solution-design`) for comparison of enterprise application designs.
-->

## Document control

<!-- Guidance: Identify the programme, the Dynamics 365 apps in scope and the review that this version supports. A change in app scope, tenant strategy or number of production environments is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [D365-SBR-001] |
| Programme | [Programme name] |
| Dynamics 365 apps in scope | [Finance, Supply Chain Management, Sales, Customer Service, Field Service, Project Operations] |
| Implementation partner | [Partner name] |
| FastTrack engagement | [Yes, FastTrack solution architect assigned / No, partner-led review] |
| Current phase | [Discover / Initiate / Implement / Prepare / Operate] |
| Review supported by this version | [Solution Blueprint Review / Implementation Review on [topic] / Go-live Readiness Review] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@programme-director], [@customer-architect], [@partner-architect], [@security-lead], [@data-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Programme director | [@name] | [Decision] | YYYY-MM-DD |
| Customer lead architect | [@name] | [Decision] | YYYY-MM-DD |
| Partner lead architect | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for the Solution Blueprint Review |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Findings from the review workshop added; performance testing added to scope |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline approved at the end of Initiate |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Programme vision and strategy](#1-programme-vision-and-strategy)
2. [Success by Design alignment](#2-success-by-design-alignment)
3. [Solution scope](#3-solution-scope)
4. [Business process strategy](#4-business-process-strategy)
5. [Application and extension strategy](#5-application-and-extension-strategy)
6. [Tenant and environment strategy](#6-tenant-and-environment-strategy)
7. [ALM strategy](#7-alm-strategy)
8. [Data strategy](#8-data-strategy)
9. [Integration strategy](#9-integration-strategy)
10. [Security strategy](#10-security-strategy)
11. [Reporting, analytics and AI](#11-reporting-analytics-and-ai)
12. [Test strategy](#12-test-strategy)
13. [Performance strategy](#13-performance-strategy)
14. [Cutover, go-live and operations](#14-cutover-go-live-and-operations)
15. [Findings, risks and success measures](#15-findings-risks-and-success-measures)
16. [Glossary and references](#16-glossary-and-references)

## 1. Programme vision and strategy

<!-- Guidance: State why the programme exists, the outcomes it commits to and how it will be delivered. Questions: what does success look like a year after go-live? Which methodology does the partner use, and how do Success by Design reviews fit into it? Pitfall: a vision that names software rather than business outcomes. -->

### 1.1 Vision and outcomes

| ID | Outcome | Measure | Baseline | Target | Owner |
|---|---|---|---|---|---|
| OUT-001 *(Example)* | Faster financial close | Working days to close the month | 9 | 5 | @finance-director |
| OUT-002 *(Example)* | One view of customer service history | Cases handled without switching systems | 40 % | 90 % | @service-director |
| OUT-003 *(Example)* | Retire three legacy ERPs | Systems decommissioned | 0 | 3 | @cio |
| [OUT-NNN] | [Outcome] | [Measure] | [Baseline] | [Target] | [@owner] |

### 1.2 Delivery approach

| Item | Decision |
|---|---|
| Implementation methodology | [Partner methodology, for example a hybrid of waterfall phases and agile build sprints] |
| Rollout strategy | [Big bang / phased by legal entity / phased by country / phased by process] |
| Number of releases | [Release 1 scope, release 2 scope] |
| Governance bodies | [Steering committee monthly, design authority weekly, change control board] |
| Customer team model | [Process owners, key users, centre of excellence] |
| Partner roles | [Solution architect, functional leads, technical lead, data lead, test lead] |

Success by Design is methodology-agnostic: it adds product-aligned reviews to whatever method the
programme uses. Map the review points onto the programme plan in section 2 so that they are funded
and scheduled, not added late.

## 2. Success by Design alignment

<!-- Guidance: Show where each review happens, what artefacts it needs and who attends. Pitfall: postponing the Solution Blueprint Review "until design is complete", which defers the discovery of risk. -->

### 2.1 Phases and review points

```mermaid
flowchart LR
    D[Discover] --> I[Initiate] --> M[Implement] --> P[Prepare] --> O[Operate]
    D -. starts .-> SBR[Solution Blueprint Review]
    I -. completes .-> SBR
    SBR --> IR[Implementation Reviews]
    M -. hosts .-> IR
    P -. hosts .-> GLR[Go-live Readiness Review]
```

The Success by Design page lists five phases (Discover, Initiate, Implement, Prepare, Operate). The
implementation guide overview page names the first stage Strategize; treat the two names as the same
stage and use the term your programme already uses.

| Review | Phase | Mandatory | Inputs from this blueprint | Attendees | Planned date |
|---|---|---|---|---|---|
| Solution Blueprint Review | Starts in Discover, completed in Initiate | Yes | Sections 1 to 14 at draft level | Customer and partner project managers and architects; FastTrack where engaged | YYYY-MM-DD |
| Implementation Review: data *(Example)* | Implement | When findings call for it | Section 8 and the data migration strategy | Data lead, architects | YYYY-MM-DD |
| Implementation Review: integration *(Example)* | Implement | When findings call for it | Section 9 and the integration design | Integration lead, architects | YYYY-MM-DD |
| Implementation Review: performance *(Example)* | Implement | When findings call for it | Section 13 | Technical lead, test lead | YYYY-MM-DD |
| Go-live Readiness Review | Prepare | Yes | Sections 12 to 15 with evidence | Programme leadership, architects, support lead | YYYY-MM-DD |

### 2.2 Review input checklist

Before the Solution Blueprint Review, confirm that a draft of each input exists, even if incomplete.
The list below is organised in this template's own words; it reflects the kinds of strategy documents
and project artefacts that the FastTrack guidance asks teams to bring.

| Input | Section or document | Status |
|---|---|---|
| Programme charter and plan | Section 1, project plan | [Draft / Ready] |
| Process catalogue and key gaps | Section 4, fit-gap analysis | [Status] |
| Legal entity and business unit structure | Section 3.2 | [Status] |
| Application landscape diagram | Section 3.3 | [Status] |
| Environment and production instance strategy | Section 6 | [Status] |
| ALM strategy | Section 7 | [Status] |
| Data and migration scope | Section 8 | [Status] |
| Interfaces list | Section 9 | [Status] |
| Security strategy | Section 10 | [Status] |
| Reporting and analytics scope | Section 11 | [Status] |
| Test strategy | Section 12 | [Status] |
| User volumes and usage profile | Sections 3.4 and 13 | [Status] |
| Responsibility matrix | Section 1.2 and RACI below | [Status] |

### 2.3 RACI for blueprint work

| Activity | Customer architect | Partner architect | Process owners | FastTrack (if engaged) | Steering committee |
|---|---|---|---|---|---|
| Maintain the blueprint | A | R | C | C | I |
| Run the review workshop | C | R | C | R or C | I |
| Classify findings | C | R | I | C | I |
| Approve recommendations with cost or scope impact | C | C | C | I | A |
| Track success measures | A | R | I | C | I |

## 3. Solution scope

<!-- Guidance: Describe the apps, the organisation structure, the landscape and the user volumes. Questions: which legal entities, countries and languages go live in each release? Pitfall: user counts that leave out integration, batch and agent load. -->

### 3.1 Apps and capabilities

| App or service | Release | Capabilities in scope | Out of scope |
|---|---|---|---|
| Dynamics 365 Finance *(Example)* | 1 | General ledger, payables, receivables, fixed assets, budgeting | Public sector features |
| Dynamics 365 Supply Chain Management *(Example)* | 1 | Procurement, inventory, warehouse management | Manufacturing execution (release 2) |
| Dynamics 365 Customer Service *(Example)* | 1 | Case management, knowledge, omnichannel chat | Voice channel (release 2) |
| Power Platform *(Example)* | 1 | Model-driven apps, Power Automate flows, Copilot Studio agents | Citizen-developed apps outside the governed environments |
| [App] | [Release] | [Capabilities] | [Out of scope] |

### 3.2 Organisation structure

| Entity | Type | Country | Currency | Language | Release | Notes |
|---|---|---|---|---|---|---|
| [Entity code] *(Example: GB01)* | Legal entity | United Kingdom | GBP | en-GB | 1 | Shared service centre |
| [Entity code] *(Example: DE01)* | Legal entity | Germany | EUR | de-DE | 1 | Localisation for e-invoicing |
| [Entity code] | [Type] | [Country] | [Currency] | [Language] | [Release] | [Notes] |

### 3.3 Application landscape

The diagram shows the apps in scope, the shared Dataverse layer and the main external systems; each line
becomes one or more interfaces in section 9.

```mermaid
flowchart TB
    subgraph D365[Dynamics 365 and Power Platform]
        FIN[Finance and Supply Chain]
        CE[Customer Service]
        DV[(Dataverse)]
    end
    CE --- DV
    FIN -- dual-write or virtual tables --- DV
    FIN <--> BANK[Bank connectivity]
    FIN <--> WMS[Third-party logistics]
    CE <--> WEB[Customer portal]
    FIN --> DL[(Analytics platform)]
    DV --> DL
```

### 3.4 Usage profile

| Persona | Named users | Peak concurrent | Peak period | Main transactions |
|---|---|---|---|---|
| Accounts payable clerk *(Example)* | 60 | 45 | Month end, days 1 to 3 | Invoice entry, matching |
| Warehouse worker *(Example)* | 200 | 150 | Daily 06:00 to 09:00 | Mobile picking and receiving |
| Service agent *(Example)* | 300 | 220 | Monday mornings | Case create and update |
| Integration and batch *(Example)* | n/a | [Threads] | Nightly 01:00 to 04:00 | Imports, settlement, MRP |
| [Persona] | [Users] | [Concurrent] | [Period] | [Transactions] |

## 4. Business process strategy

<!-- Guidance: Show how processes are catalogued, who owns them and how gaps are decided. Pitfall: replicating legacy processes in full and treating each difference from standard as a gap to build. -->

| Item | Decision |
|---|---|
| Process catalogue | [Business process catalogue with levels: end-to-end process, process area, business process, scenario] |
| Process ownership | [One accountable business owner per end-to-end process] |
| Fit-gap method | [Workshops with demonstrations of standard capability; decisions recorded in the fit-gap analysis] |
| Gap decision rule | [Adopt standard, change the process, configure, extend, or accept a workaround: in that order of preference] |
| Requirement traceability | [Requirement IDs traced to process, design, build item and test case] |

| ID | End-to-end process | Owner | Scenarios | Standard fit | Gaps | Gap decisions pending |
|---|---|---|---|---|---|---|
| PRC-001 *(Example)* | Procure to pay | @procurement-director | 42 | 36 | 6 | 2 |
| PRC-002 *(Example)* | Record to report | @finance-director | 55 | 51 | 4 | 0 |
| PRC-003 *(Example)* | Case to resolution | @service-director | 30 | 26 | 4 | 1 |
| [PRC-NNN] | [Process] | [@owner] | [n] | [n] | [n] | [n] |

Each row should satisfy scenarios = standard fit + gaps. The detail of each gap and its decision sits in
Fit-gap analysis (`architecture/fit-gap-analysis`); the specifications for extensions follow the WRICEF
object specification (`architecture/wricef-object-specification`) or the programme's equivalent.

## 5. Application and extension strategy

<!-- Guidance: State how the solution is extended and what is forbidden. Questions: which extensions are low-code and which are pro-code? How are partner ISV solutions assessed? Pitfall: extensions that block the continuous update cadence. -->

| Extension type | Allowed for | Tooling | Guardrails |
|---|---|---|---|
| Configuration and parameters | All apps | Standard configuration | Documented in configuration workbook |
| Low-code apps and flows | Departmental needs | Power Apps, Power Automate in managed environments | Governed by low-code platform rules; DLP policies apply |
| Agents | Approved AI use cases | Copilot Studio, built-in Dynamics 365 agents | Agent scope, data access and human escalation defined in section 11 |
| Pro-code extensions to customer engagement apps | Complex logic | Plug-ins, PCF controls | Code review, solution layering rules |
| Pro-code extensions to finance and operations apps | Logic not possible by configuration | X++ extensions (no overlayering) | Extension-only model, code review, best practice checks |
| ISV solutions | Industry gaps | AppSource offers | Roadmap fit, support model, update compatibility |

Microsoft ships updates on a continuous service cadence with planned release waves. Older release
plans are archived as new ones are published, so check the current release planning portal on
learn.microsoft.com for the waves that fall inside the programme timeline; record in section 7 how the
programme watches that roadmap and tests updates before they reach production.

## 6. Tenant and environment strategy

<!-- Guidance: Decide the tenant, the number of production environments, their regions and the non-production plan. Questions: single global environment or one per region? Which environments are needed when, and for which activities in parallel? Pitfall: discovering late that training, data migration and UAT all need the same environment in the same weeks. -->

### 6.1 Tenant and production strategy

| Item | Decision |
|---|---|
| Microsoft Entra tenant | [Single corporate tenant / separate tenant, with reason] |
| Production environments | [One global environment / one per region], reason: [collaboration, residency, performance] |
| Geography and region | [Geography], to meet [residency and latency requirements] |
| Early release validation | [Early release cycle environment used for validating upcoming features: yes / no] |
| Default environment | [Renamed and restricted to personal productivity; no business apps] |
| Capacity | [Database, file and log capacity forecast per environment] |

A single global environment is the most common model and makes shared data and processes simpler.
Choose several production environments only when residency, legal separation or scale justifies the
cost of integration between them, and record that decision in section 15.

### 6.2 Environment plan

| Environment | Type | Purpose | Needed from | Needed until | Data | Owner |
|---|---|---|---|---|---|---|
| DEV-[n] *(Example)* | Sandbox (customer engagement), development environment (finance and operations) | Build | Initiate | Operate | Configuration and test data | Technical lead |
| BUILD *(Example)* | Build environment or pipeline host | Packaging and automated tests | Implement | Operate | None | Technical lead |
| TEST *(Example)* | Sandbox | System and integration test | Implement | Operate | Migrated test data, masked | Test lead |
| MIG *(Example)* | Sandbox | Mock migrations | Implement | Prepare | Full volume, masked | Data lead |
| UAT *(Example)* | Sandbox, production-sized tier for performance tests | Acceptance, performance, training | Implement | Operate | Copy of migrated data | Test lead |
| PROD | Production | Live | Prepare | n/a | Live | Platform owner |

Power Platform environment types include production, sandbox, trial, developer and the default
environment. Microsoft has deprecated unmanaged developer environments and Dataverse for Teams
environments: no new ones can be created from 15 November 2026, existing unmanaged developer
environments are suspended from 15 December 2026 (and deleted from 15 January 2027) unless Managed
Environments is enabled on them first, each user can create one managed developer environment, and
Dataverse for Teams environments not upgraded to Dataverse are suspended on 15 September 2027 and
decommissioned on 30 October 2027 (check the current notice). Plan developer environments as managed
environments. For finance and operations apps, record whether environments are managed through the
Power Platform admin center or through Lifecycle Services for this tenant, and check the current
Microsoft guidance for the provisioning model.

## 7. ALM strategy

<!-- Guidance: Define how changes move from development to production and how Microsoft updates are absorbed. Pitfall: unmanaged solutions in production, which make removal and layering unpredictable. -->

```mermaid
flowchart LR
    A[Developer environment] --> B[Source control]
    B --> C[Build pipeline: package and test]
    C --> D[Test environment]
    D --> E[UAT]
    E --> F{Change board}
    F -->|Approved| G[Production]
```

| Item | Decision |
|---|---|
| Source of truth | [Git repository in Azure DevOps or GitHub] |
| Customer engagement packaging | Solutions: unmanaged in development, managed in every downstream environment |
| Finance and operations packaging | [Deployable packages built from source; unified developer experience where adopted] |
| Pipelines | [Pipelines in Power Platform / Azure DevOps with Power Platform Build Tools / GitHub Actions] |
| Branching | [Main plus release branches; hotfix branch] |
| Solution layering | [Publisher prefix, segmentation by domain, dependency rules] |
| Microsoft update handling | [Update calendar, regression suite, early access validation] |
| Configuration data | [Configuration migration tooling, data packages, golden configuration environment] |

## 8. Data strategy

<!-- Guidance: Cover data ownership, migration scope, archiving and quality. Questions: which system masters customers, vendors and products? How much history migrates? Pitfall: migrating all history because nobody decided what to leave behind. -->

| Data domain | System of record | Migration scope | Volume | Source systems | Owner |
|---|---|---|---|---|---|
| Customers *(Example)* | Dynamics 365 (Dataverse and Finance aligned through dual-write) | Active customers | 120,000 | Legacy CRM, legacy ERP | @customer-data-owner |
| Vendors *(Example)* | Dynamics 365 Finance | Active vendors, 2 years of open items | 15,000 | Legacy ERP | @procurement-data-owner |
| Open transactions *(Example)* | Dynamics 365 Finance | Open AP, open AR, open purchase orders | 80,000 | Legacy ERP | @finance-data-owner |
| General ledger history *(Example)* | Analytics platform | Balances by period for 3 years; detail stays in archive | n/a | Legacy ERP | @finance-data-owner |
| Cases *(Example)* | Dynamics 365 Customer Service | Open cases and 2 years of closed cases | 600,000 | Legacy service tool | @service-data-owner |
| [Domain] | [System] | [Scope] | [Volume] | [Sources] | [@owner] |

State the migration tooling (for example the data management framework for finance and operations apps,
Dataverse import tooling or a migration platform), the number of mock migrations and the reconciliation
approach. Full detail sits in Data migration strategy (`architecture/data-migration-strategy`), master
data governance in Master data management design (`architecture/master-data-management-design`).

## 9. Integration strategy

<!-- Guidance: List interfaces, the patterns and the platform, and show the decision for each pattern. Pitfall: synchronous calls between apps for flows that tolerate delay, which couple availability. -->

| Pattern | Dynamics 365 and Power Platform options | Use for |
|---|---|---|
| Near-real-time synchronisation between finance and operations apps and Dataverse | Dual-write, virtual tables | Customers, products, sales orders shared between apps |
| Business events | Finance and operations business events, Dataverse events to Azure Service Bus or Event Grid | Notifying downstream systems |
| APIs | OData and custom services, Dataverse Web API | Real-time lookups and updates |
| Bulk and file | Data management framework, recurring integrations | High-volume imports and exports |
| Analytics feed | Link to Microsoft Fabric or Azure Synapse Link for Dataverse (check current option) | Reporting copy of data |
| Orchestration | Azure Integration Services, Power Automate for low-volume flows | Multi-step processes across systems |

| ID | Source | Target | Pattern | Frequency | Volume per day | Error handling | Owner |
|---|---|---|---|---|---|---|---|
| INT-001 *(Example)* | Bank | Finance | File through integration platform | Daily | 5,000 statement lines | Reject file to queue, alert treasury | @integration-lead |
| INT-002 *(Example)* | Finance | Third-party logistics | Business event to message queue | On shipment release | 3,000 | Dead letter queue, retry | @integration-lead |
| INT-003 *(Example)* | Customer portal | Customer Service | Dataverse Web API | Real time | 10,000 | Retry with backoff, user message | @integration-lead |
| [INT-NNN] | [Source] | [Target] | [Pattern] | [Frequency] | [Volume] | [Handling] | [@owner] |

Detailed interface specifications follow Integration design (`architecture/integration-design`) and the
enterprise rules in Integration strategy (`architecture/integration-strategy`).

## 10. Security strategy

<!-- Guidance: Describe the identity, authorisation, data protection and compliance model. Pitfall: security roles designed late, after testing has run with administrator rights. -->

| Area | Decision |
|---|---|
| Identity | Microsoft Entra ID with single sign-on, conditional access and MFA |
| Privileged access | Admin roles through Privileged Identity Management; break-glass accounts documented |
| Authorisation in customer engagement apps | Security roles, business units, teams, column security profiles |
| Authorisation in finance and operations apps | Roles, duties and privileges; segregation of duties rules |
| Data loss prevention | Tenant-wide DLP policies for connectors; environment-level policies for exceptions |
| Encryption and keys | [Microsoft-managed keys / customer-managed keys where licensed] |
| Auditing | [Dataverse auditing, database logging in finance and operations apps, retention period] |
| Compliance | [GDPR, SOX controls, sector rules]; privacy assessed in DPIA (`compliance/dpia`) |
| Agent access | Agents run with least-privilege identities; data scope reviewed before go-live |

Build the security role design in Implement and test every persona with its real role before UAT.
Identity patterns shared with other systems belong in IAM solution design
(`security/iam-solution-design`).

## 11. Reporting, analytics and AI

<!-- Guidance: Describe operational reporting, analytics and the AI and agent scope with its governance. Questions: which AI maturity level does the organisation target? Where must a human approve an agent's work? Pitfall: agents switched on without evaluation or a fall-back path. -->

### 11.1 Reporting and analytics

| Need | Tool | Data source | Owner |
|---|---|---|---|
| Operational lists and dashboards | In-app views and dashboards | Live app data | Process owners |
| Financial reporting | [Financial reporting tool] | Finance | @finance-director |
| Enterprise analytics | Power BI on the analytics platform | Fabric or data lake copy | @data-lead |

### 11.2 AI and agents

Success by Design now includes agentic design principles and an AI maturity scale running from human
first, through Copilot assistance and humans working with agents, to agent first with human oversight.

| ID | Use case | App or tool | Target maturity | Data access | Human oversight | Evaluation | Owner |
|---|---|---|---|---|---|---|---|
| AI-001 *(Example)* | Supplier communication follow-up | Built-in Supply Chain agent | Humans with agents | Purchase orders, vendor contacts | Buyer approves changes to dates | 200 scenario test set, accuracy above 95 % | @procurement-lead |
| AI-002 *(Example)* | Case summarisation | Copilot in Customer Service | Copilot assisted | Case and conversation | Agent reviews summary | Sampled quality review | @service-lead |
| [AI-NNN] | [Use case] | [Tool] | [Level] | [Data] | [Oversight] | [Evaluation] | [@owner] |

For each agent, confirm responsible AI review, evaluation results on production-like data, telemetry and
alerting, and an incident path before go-live. Detailed design follows AI agent specification
(`ai-data/ai-agent-spec`).

## 12. Test strategy

<!-- Guidance: Define the test types, environments, entry and exit criteria and the automation approach. Pitfall: leaving performance testing out on the assumption that the cloud service is fast enough on its own. -->

| Test type | Phase | Environment | Scope | Exit criterion | Owner |
|---|---|---|---|---|---|
| Unit | Implement | Development | Each extension | Tests pass, code review complete | Developers |
| Functional | Implement | Test | Scenarios per process | All priority 1 scenarios pass | Functional leads |
| End-to-end process | Implement | Test | PRC-001 to PRC-NNN across apps and interfaces | No open severity 1 or 2 defects | Test lead |
| Data migration validation | Implement, Prepare | MIG | Each mock migration | Reconciliation within agreed tolerance | Data lead |
| Performance | Implement | UAT (production-sized) | Section 13 scenarios | Targets met | Technical lead |
| Security and role | Implement | Test | Each persona | Role matrix signed | Security lead |
| User acceptance | Prepare | UAT | Business scenarios | Business sign-off | Process owners |
| Regression for Microsoft updates | Operate | Test | Automated suite | Pass before update reaches production | Test lead |

Document the full plan in Test plan (`dev/test-plan`).

## 13. Performance strategy

<!-- Guidance: Turn the usage profile into measurable targets and test them. Pitfall: testing with tiny data volumes and few users, then meeting month-end load in production. -->

| ID | Scenario | Volume | Target | Method |
|---|---|---|---|---|
| PRF-001 *(Example)* | Post 5,000 vendor invoices in a batch | 5,000 | Under 20 minutes | Batch run in UAT with production-sized data |
| PRF-002 *(Example)* | Open case form under peak load | 220 concurrent agents | 95th percentile under 3 s | Load test tool |
| PRF-003 *(Example)* | Warehouse pick confirmation | 150 concurrent users | Under 1 s per scan | Mobile device test at site |
| PRF-004 *(Example)* | Nightly integration window | INT-001 to INT-NNN | Completes by 05:00 | Timed rehearsal |
| [PRF-NNN] | [Scenario] | [Volume] | [Target] | [Method] |

Watch the design choices that most often hurt performance: heavy synchronous plug-ins, chatty
integrations, unfiltered views over large tables, and batch jobs scheduled into business hours. Include
API request limits and service protection limits in the integration design.

## 14. Cutover, go-live and operations

<!-- Guidance: Summarise the cutover approach, go/no-go criteria and the support model after go-live. Pitfall: a support model defined in the last week, with no named owners for Microsoft support cases. -->

| Item | Decision |
|---|---|
| Cutover approach | [Weekend big bang / phased by entity], detailed in Cutover plan (`project/cutover-plan`) |
| Mock go-lives | [Number and dates of full rehearsals] |
| Go/no-go criteria | [Open defects, data reconciliation, readiness of users, support and operations] |
| Deployment runbook | [Tasks, owners, durations and dependencies; location] |
| Hypercare | [Duration, exit criteria], see Hypercare plan (`ops/hypercare-plan`) |
| Support model | [Tier 1 service desk, tier 2 centre of excellence, tier 3 partner, Microsoft support] |
| Monitoring | [Telemetry, admin center health, integration monitoring, agent monitoring] |
| Handover to operations | [Runbooks, knowledge transfer], see Operations handover (`ops/operations-handover`) |

The Go-live Readiness Review checks these items with evidence. Record the outcome and any conditions in
Go-live readiness review (`project/go-live-readiness-review`).

## 15. Findings, risks and success measures

<!-- Guidance: Keep every review finding with its type, the recommendation and the owner, and track success measures over time. Pitfall: findings reported once and never closed. -->

### 15.1 Findings register

| ID | Review | Type | Finding | Recommendation | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
| FND-001 *(Example)* | Solution Blueprint Review | Risk | Performance testing is not in the test plan; several high-volume integrations and one mandated customisation | Add performance testing to the test cycle; hold a performance Implementation Review | @test-lead | YYYY-MM-DD | Open |
| FND-002 *(Example)* | Solution Blueprint Review | Assertion | Single global production environment agreed, with clear residency analysis | None; keep | @solution-architect | n/a | Closed |
| FND-003 *(Example)* | Implementation Review: data | Issue | Customer duplicates across legacy CRMs exceed 8 % | Cleansing sprint before mock 2; match rules agreed with data owners | @data-lead | YYYY-MM-DD | In progress |
| [FND-NNN] | [Review] | [Assertion / Risk / Issue] | [Finding] | [Recommendation] | [@owner] | YYYY-MM-DD | [Status] |

### 15.2 Risk heat map

| Impact / Likelihood | Low | Medium | High |
|---|---|---|---|
| High | [IDs] | FND-001 *(Example)* | [IDs] |
| Medium | [IDs] | [IDs] | [IDs] |
| Low | [IDs] | [IDs] | [IDs] |

Plot risks only. Issues such as FND-003 have already happened and are tracked in the findings register.

### 15.3 Success measures

Success by Design tracks project health through success measures grouped into categories, each rated
red, yellow or green after a review or significant project event. Microsoft lists seven categories with
over 30 measures, plus supplementary AI categories such as agent readiness and evaluation quality. Use the categories your FastTrack
architect or partner tooling provides; the rows below are examples in this template's own words.

| Category | Measure | Rating | Date | Comment |
|---|---|---|---|---|
| Architecture *(Example)* | Environment strategy approved | Green | YYYY-MM-DD | Section 6 baselined |
| Implementation *(Example)* | Performance testing planned | Red | YYYY-MM-DD | FND-001 open |
| Project governance *(Example)* | Steering committee decisions recorded | Yellow | YYYY-MM-DD | Two decisions pending |
| Agent readiness *(Example)* | Agent scope and responsible AI sign-off | Yellow | YYYY-MM-DD | AI-001 evaluation running |
| [Category] | [Measure] | [Red / Yellow / Green] | YYYY-MM-DD | [Comment] |

### 15.4 Decisions

| ID | Decision | Options | Reason | Date | Approver |
|---|---|---|---|---|---|
| DEC-001 *(Example)* | One global production environment in the EU geography | Single, one per region | Shared processes, residency met, lower integration cost | YYYY-MM-DD | Design authority |
| DEC-002 *(Example)* | Dual-write for customers and products | Dual-write, custom integration | Standard pattern, near-real-time, supported | YYYY-MM-DD | Design authority |
| [DEC-NNN] | [Decision] | [Options] | [Reason] | YYYY-MM-DD | [Approver] |

## 16. Glossary and references

<!-- Guidance: Define the Microsoft terms used and list the pages checked, with the date. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| Success by Design | Microsoft framework of phases, reviews and guidance for Dynamics 365 implementations |
| FastTrack for Dynamics 365 | Microsoft customer success programme that runs Success by Design reviews for eligible projects |
| Solution Blueprint Review | Early, mandatory review of the overall scope and design concepts |
| Implementation Review | Deeper review of one topic raised by blueprint findings |
| Go-live Readiness Review | Mandatory review of remaining risk before go-live |
| Assertion, risk, issue | The three types of review finding: good practice observed, possible negative impact, current negative impact |
| Dataverse | Data platform underlying Power Platform and customer engagement apps |
| Dual-write | Near-real-time synchronisation between finance and operations apps and Dataverse |
| Managed solution | Locked solution package deployed to downstream environments |

### 16.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Dynamics 365 implementation guide, Success by Design framework, learn.microsoft.com | Page dated 2026-08-04 | Phases, reviews, findings, success measures, AI guidance |
| Dynamics 365 implementation guide overview | Page dated 2026-08-19 | Stage names, guide structure |
| TechTalk: Solution Blueprint Review with FastTrack | Page dated 2025-10-03 | Review inputs and process |
| Plan your environment strategy for Dynamics 365 | Page dated 2024-01-16 | Section 6 |
| Power Platform environments overview | Page dated 2026-10-08 | Environment types and deprecations |
| Power Platform, Important changes (deprecations) | Checked 2026-10-23 | Developer and Dataverse for Teams timelines |
| ALM with Microsoft Power Platform | Page dated 2025-01-29 | Section 7 |
| Dynamics 365 and Power Platform release planning portal | Check current | Release cadence note |

## Standard and licence note

Structure aligned with the Success by Design framework and the Dynamics 365 implementation guide
published by Microsoft on Microsoft Learn (framework page dated 4 August 2026), and with Microsoft
Power Platform environment and ALM guidance. Only phase, review, finding type and product names are
used; the strategy sections, checklists, criteria and examples are original text written for this
collection and do not reproduce Microsoft checklists. Check the current Microsoft Learn pages before use,
since the guidance is updated often. Microsoft, Dynamics 365, Power Platform, Dataverse and related
product names are trademarks of their owners; this template is not affiliated with or endorsed by them.
Template licence: MIT.