Engagement
Engineering Risk Audit
An architecture and X++ code second opinion from senior engineers who read your code — but won't bid the build. Before you commit to a partner, a platform, or a post-go-live remediation proposal, get a vendor-neutral read on whether the design and the code will actually survive One Version and scale. So the expensive mistake doesn't get locked in.
Baseline scope: 1 D365 estate, 1 architectural decision, 1–2 integration topics. Access prerequisites listed below; scope factors agreed at signing.
Who it is for
- Solution architects about to sign a major D365 implementation contract or change-order.
- CIOs and IT directors who want an independent gut-check on a partner-recommended architecture.
- CIOs and CTOs evaluating a post-go-live remediation proposal — dual-write license upgrade, iPaaS replatform, embedded integration layer, or custom X++ build to "fix the live system."
- Microsoft partners who occasionally need a deeper engineering review on a complex deal (white-label or co-delivered).
- Procurement and vendor-management teams making a tool-selection decision (iPaaS vs custom vs embedded layer).
Not for pricing validation, not for full hands-on stabilization work (use Production Stabilization Sprint — Audit is the readout, Sprint is the fix), and not for high-level "trends in Dynamics" briefings.
Typical triggers
When teams reach out
- "We are about to commit to an iPaaS for our D365 estate — is that the right call?"
- "Our partner is recommending a custom X++ build — second opinion?"
- "Our partner wants €120k/year to upgrade our dual-write license tier as a fix — is that the right solution?"
- "We are 6 months from go-live and the architecture diagram has us nervous — can someone independent review it?"
- "Our internal team disagrees on integration approach. We need an outside arbiter."
What you get
Deliverable
An 8–15 page written readout with risk-ranked findings (BLOCKING / SHOULD / NOTE) across both architecture and X++ code — extension patterns, integration design, customization footprint — plus specific recommendations and explicit scope limits. Vendor-neutral — we name patterns, not products.
How it works
Timeline
-
1
Kickoff call 60 min
Confirm scope, share-folder access, set the working-session date, surface any data still needed.
-
2
Diagnostic phase 5–7 business days
We read everything sent, walk through the architecture, check it against Microsoft-supported patterns and real-world failure modes, write up findings.
-
3
Working session 90 min
Live walkthrough of findings with you and your architect. Q&A. Decisions captured.
-
4
Readout document 3 business days after the session
Written record of findings, recommendations, decisions reached, follow-up items.
Pricing
Fixed-fee — quoted on the scoping call
- Fixed fee for the baseline scope — 1 D365 estate, 1–2 integration topics, 1 architectural decision. The figure is set on the scoping call.
- Scope factors that change the quote — additional integration topics, deeper code review, multi-LE / multi-region — are agreed up front, never added silently.
- Payment: 50% on kickoff, 50% on readout delivery.
When we re-quote: We re-quote when the input pack reveals more than 3 integration topics, >3 extensions to review, or more than 1 LE / region.
Scope clarity
What this engagement is NOT
- Not a long-term advisory retainer (use Production Stabilization Sprint if you need engagement that touches your code or configuration directly).
- Not a Microsoft licensing review.
- Not a remediation engagement — the readout points at risks; fixing them is a separate scope.
- Not a "rate the implementation partner" exercise. We review architecture, not vendor performance.
Ready to start?
Bring the relevant materials — architecture diagrams, recent logs, the decision under review — and we will scope from there.