# Section Interview Guide

Load only the sections in play. Each entry gives what the section decides, the questions to ask, option sets where a real architectural choice exists, and the trap to watch for.

**⚑ marks a load-bearing decision.** Do not let the session move past it without either a decision or a named owner and blocking date.

---

## 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:**

| Approach | Works when | Costs you |
|---|---|---|
| **Big bang** | Scope is compact or highly interdependent | Highest single-point cutover risk; no learning between waves |
| **By geography / legal entity** | Units can operate semi-independently | Longer dual-running and interim integration complexity |
| **By module** | A clear functional sequence is justified | Temporary integration between D365 and legacy processes |
| **Pilot then rollout** | Many similar entities support a template approach | First wave absorbs template learning and needs strong governance |

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:**

| Posture | Statement | Suits |
|---|---|---|
| **Strict standard** | Business adapts unless a statutory constraint requires otherwise | Cost-led programmes with strong change appetite |
| **Standard with justified exception** | Extensions require a documented business/regulatory reason and named approval authority | Most enterprise implementations |
| **Fit to process** | System adapts heavily to existing business process | Rarely defensible without clear value and lifecycle-cost acceptance |

**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:**

| Layer | Use for | Avoid when |
|---|---|---|
| D365 configuration | Parameters, workflow, policies, standard behaviour | The requirement genuinely needs new business logic |
| Electronic Reporting | Documents, regulatory formats, file-generation scenarios | Complex transactional logic |
| Power Platform | Task apps, approvals, lightweight orchestration | High-volume transaction processing requiring ERP consistency |
| X++ extension | ERP business logic requiring transactional consistency | Standard configuration or lower-code options can meet the need |
| External service | Specialist domains and decoupled capabilities | It creates a platform the organisation cannot operate |

**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:**

| Approach | Consequence |
|---|---|
| Few, governed dimensions | Cleaner posting, easier adoption, simpler reporting |
| Many optional dimensions | Flexible analysis but higher complexity, weaker data quality, and larger cardinality |

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:**

| Pattern | Suits | Watch |
|---|---|---|
| OData / custom service | Low-volume synchronous access | Throttling and synchronous coupling |
| Data management / recurring integration | Batch and bulk movement | Latency, staging, and error handling |
| Business events | Event-driven notifications | Duplicate delivery and idempotency |
| Dual-write | Near-real-time F&O/Dataverse synchronization | Coupling and failure behaviour |
| Service Bus / Logic Apps | Decoupling, retry, orchestration | Additional platform ownership and operations |
| Analytics export/Fabric path | Reporting and analytics consumption | Not an operational write pattern |

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:**

| Approach | Cost | Consequence |
|---|---|---|
| Migrate detailed history | Highest reconciliation and database cost | Full in-system history |
| Keep legacy read-only | Ongoing legacy access cost | Fastest migration, weaker user experience |
| Extract to archive / analytics store | Moderate implementation cost | Often a strong reporting compromise |

**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:**

| Need | Candidate approach |
|---|---|
| Financial statements | Financial reporting capabilities |
| Operational documents and statutory formats | SSRS / Electronic Reporting where applicable |
| Operational enquiry | Standard D365 views and workspace capabilities |
| Cross-functional dashboards | Power BI |
| Enterprise analytics | Fabric / governed data platform |
| Ad-hoc finance analysis | Excel integration where appropriate |

**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.