Section Guide

Contents

Track A - Foundation: 1 Programme context | 2 Scope ⚑ | 3 Target operating model
Track B - Solution: 4 Application architecture ⚑ | 5 Data architecture ⚑ | 6 Integration architecture
Track C - Data and control: 7 Data migration ⚑ | 8 Security and licensing
Track D - Platform: 9 Environment and ALM | 10 Reporting and analytics | 11 Performance and volumetrics
Track E - Delivery: 12 Test strategy | 13 Deployment and cutover ⚑ | 14 Support and operating model

TRACK A - FOUNDATION

1. Programme context and business case

Decides: why this programme exists, what success looks like, and what is genuinely non-negotiable. Everything downstream gets prioritised against this.

Ask:

• What is driving this now: legacy end-of-life, growth, acquisition integration, compliance, cost, or another factor?
• What does the business case commit to, in measurable terms? Who owns those outcomes?
• Who is the executive sponsor and who has decision authority?
• Which constraint is genuinely fixed: date, budget, scope, regulation, or something else?
• What has been attempted before and what was learned?

Trap: an efficiency business case that depends on process change nobody has agreed to make.

Produces: drivers, measurable objectives, sponsor and governance, fixed constraints, and programme history.

2. Scope ⚑

Decides: which applications, modules, legal entities, countries, and deployment waves are in scope.

Ask:

• Which Dynamics 365 applications and modules are in scope, and which are explicitly out?
• ⚑ How many legal entities are proposed, and what drives each one’s existence: statutory filing, functional currency, regulatory need, management model, or inherited structure?
• Which countries and localisations are required?
• What remains on another system, and who owns that boundary?
• ⚑ What is the deployment phasing: big bang, geography, legal entity, module, or pilot-then-rollout?

Options to propose - phasing:

Always ask what the interim-state integrations and controls will cost.

Trap: legal-entity structure copied from the legacy system without testing whether the reasons still apply.

Produces: application/module scope, legal-entity register, country/localisation scope, explicit out-of-scope statement, and wave plan.

3. Target operating model and process architecture

Decides: how the business will run after go-live and which processes D365 supports.

Ask:

• Is there a target operating model, or are we designing against current state?
• Shared services or distributed processing? Which functions?
• Where will approval authority sit, and is it changing?
• Which processes are genuinely differentiating and which are commodity?
• Who owns each end-to-end process and has authority to decide?
• Are intercompany flows changing or simply moving systems?

Options to propose - standard-first posture:

Trap: “use standard wherever possible” without a threshold, approval forum, or authority to reject gaps.

Produces: operating model summary, process architecture, process ownership, and gap-governance posture.

TRACK B - SOLUTION

4. Application architecture ⚑

Decides: the application landscape, instance strategy, ISVs, Power Platform role, and extension posture.

Ask:

• ⚑ Single production instance or multiple? What requirement would justify multiple?
• Which ISVs are in scope? What is their support and service-update posture?
• ⚑ What belongs on Power Platform rather than in Finance/SCM, and why?
• Which existing Power Apps, Power Automate flows, or Dataverse dependencies must survive?
• ⚑ What is the extension-approval threshold and who can approve a gap?

Options to propose - logic placement:

Trap: an ISV selected before architecture without testing update compatibility, support model, and exit strategy.

Produces: application landscape, instance decision, ISV register, Power Platform scope, and extension governance.

5. Data architecture ⚑

Decides: chart of accounts, financial dimensions, product model, master-data ownership, and Dataverse/dual-write scope.

Ask:

• ⚑ Is the chart of accounts shared or entity-specific, and is rationalisation part of scope?
• ⚑ Which financial dimensions are required, which are mandatory, and what decision/report does each serve?
• ⚑ What product, storage, tracking, batch/serial, and variant dimensions are required?
• Who owns customer, vendor, product, and other master data? Is there an MDM platform?
• ⚑ Which entities, if any, are dual-written and in which direction?
• What happens operationally if dual-write or another data-sync dependency is unavailable?

Options to propose - dimension design:

For each proposed dimension ask: which report or decision does it serve, and who consumes it?

Trap: product/inventory dimension decisions made in isolation from costing, warehouse, quality, and reporting teams.

Produces: COA/dimension design, product model, master-data ownership matrix, dual-write scope, and failure behaviour.

6. Integration architecture

Decides: the interface landscape, pattern principles, middleware direction, and failure-design standards.

Ask:

• What is the full interface inventory: source, target, direction, volume, frequency, latency, and criticality?
• What is the business consequence of each critical interface being down for four hours?
• What middleware strategy is intended: direct, Azure Integration Services, existing ESB, or another platform?
• Who owns each interface after go-live and who receives alerts?
• Which legacy contracts or external interfaces constrain the design?

Pattern options:

For critical interfaces, require retry, poison-message handling, idempotency, alerting, ownership, and reconciliation at blueprint level.

Trap: interface inventory sized on average volume and designed only for the happy path.

Produces: inventory, pattern principles, middleware decision, failure principles, and ownership model.

TRACK C - DATA AND CONTROL

7. Data migration ⚑

Decides: what data moves, how history is handled, how opening balances are treated, and how correctness is proved.

Ask:

• ⚑ Historical data: migrate, retain legacy read-only, or extract to an archive/data platform? What specific obligation or business need drives the answer?
• Which objects fall into configuration, master, open transaction, opening balance, and historical classes?
• What opening-balance treatment is required for GL, AR/AP, inventory, fixed assets, bank, and other relevant areas?
• Where is data cleansing happening and who owns it?
• Who signs off migrated data and against which source/control reports?
• Which tools and environments are intended for migration?

Options to propose - history:

Trap: historical migration requested by habit rather than a legal, audit, or operational need.

Produces: migration scope, history decision, opening-balance strategy, cleansing ownership, reconciliation, sign-off model, and tooling direction.

8. Security, compliance, and licensing

Decides: security principles, segregation-of-duties requirements, data-access boundaries, licensing shape, and access administration.

Ask:

• What job families and user populations exist, and across which legal entities?
• What SoD expectations apply and who is the control authority?
• Are there data residency, privacy, or sector-specific constraints?
• Is record-level restriction required beyond legal-entity and organisational boundaries?
• What licences are currently contracted and what assumptions underpin the quantity?
• Who administers joiners, movers, leavers, privileged access, and recertification?

Trap: licence entitlement agreed before role design and never revalidated against actual access.

Produces: role-family model, SoD expectations, compliance constraints, XDS need, indicative licence shape, and access-admin model.

TRACK D - PLATFORM

9. Environment strategy and ALM

Decides: environment topology and how code/configuration move through the landscape.

Ask:

• Which environments are entitled and what additional capacity is required?
• What is each environment for, who owns it, and what is the refresh cadence?
• Where is golden configuration held and how is configuration transported?
• What branching and source-control strategy applies across all delivery parties?
• How are builds, releases, approvals, and production deployments automated?
• Who owns service-update planning and the regression gate?

Trap: environment planning sized for build but not for migration rehearsals, UAT, training, and cutover concurrently.

Produces: environment topology, refresh strategy, golden configuration approach, branching/pipeline design, and update governance.

10. Reporting and analytics architecture

Decides: which information products are required and which technologies serve them.

Ask:

• Which reports are genuinely business-critical? Who consumes them and what decision do they drive?
• What latency does each actually need?
• What statutory and regulatory reporting exists by country?
• What is the analytics-platform direction: Power BI, Fabric, existing warehouse, or another platform?
• Who builds and maintains reports after go-live?

Tool-selection examples:

Trap: “real time” requested without connecting latency to an actual decision cadence.

Produces: report inventory, latency requirements, tool mapping, analytics direction, statutory approach, and ownership.

11. Performance, scale, and volumetrics

Decides: whether the design can support expected production load and what must be tested later.

Ask:

• What are average and peak transaction volumes per critical process?
• What are current and projected data volumes over three years?
• What is peak user concurrency by function?
• What batch windows and hard deadlines exist?
• How long does month-end or another critical business cycle take today, and what is the target?
• Which operational deadlines create non-negotiable performance constraints?

Trap: annual averages used where peak-hour or period-end demand is the real design driver.

Produces: volumetric baseline, growth projection, concurrency profile, batch-window constraints, and performance acceptance targets.

TRACK E - DELIVERY

12. Test strategy

Decides: how quality is proven before go-live and maintained through future service updates.

Ask:

• Which test levels are required: unit, functional, integration/end-to-end, UAT, performance, security, regression, DR?
• Who writes and owns tests and how do they trace back to requirements/processes?
• What test data and volume will be used?
• What regression automation is required, and what is the cost of the manual alternative?
• What numeric exit criteria apply to each phase?
• Who signs off UAT and readiness?

Trap: no regression automation and no funded manual regression capacity.

Produces: test-level model, traceability approach, test-data strategy, automation decision, exit criteria, and severity model.

13. Deployment and cutover approach ⚑

Decides: the shape of go-live and the constraints a later detailed runbook must satisfy.

Ask:

• ⚑ Does the phasing decision from section 2 still hold after the rest of the architecture has been understood?
• What cutover window is available and what drives its boundaries?
• Is parallel running required? By whom, and what will it prove?
• What is the rollback position and point of no return?
• Who declares go/no-go and against which measurable criteria?
• What business freeze is tolerable?

Trap: a cutover window based on preference rather than measured full-volume migration timings.

Produces: deployment approach, cutover-window constraint, parallel-running decision, rollback position, and go/no-go authority.

14. Support and operating model

Decides: who runs the solution after implementation and how knowledge, updates, support, and change are governed.

Ask:

• What is the target support model: L1/L2/L3, internal, partner-managed, or hybrid?
• What are hypercare duration, staffing, and exit criteria?
• Which named people will hold functional, technical, and architecture knowledge after go-live?
• Who owns the service-update calendar and regression gate?
• What is the post-go-live change process for enhancements, new entities, and new requirements?
• Who owns the Microsoft/product-roadmap relationship?

Trap: knowledge-transfer plans with roles or teams named but no actual recipients allocated.

Produces: support tiers and ownership, hypercare model, knowledge-transfer plan, update governance, and change process.