D365 Solution Blueprint

GitHubOfficialFirst committed by mibrahim234UKDistributed by GitHub

Skill
Content generator
Software development
MIT
No issues found

From the author

Authors a Dynamics 365 Finance and Supply Chain Management Solution Blueprint from scratch through a structured, section-by-section architect interview, establishing scope, target operating model, application and data architecture, integration landscape, migration strategy, security model, ALM, testing, deployment, and support approach, with a decision log capturing rationale and rejected alternatives. Use when the user wants to create D365 implementation architecture documentation, start a D365 implementation, design the architecture, prepare a Solution Blueprint, or identify the architectural decisions the programme must make. Do not use for critique of an existing design; that is a review task rather than blueprint authoring.

— the description by mibrahim234UK

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The d365-solution-blueprint skill facilitates a multi-session architectural workshop to produce a comprehensive Dynamics 365 implementation blueprint. It guides the user through a structured, section-by-section interview process covering foundation, solution, data, platform, and delivery tracks. The skill emphasizes capturing architectural decisions, rationale, and rejected alternatives in a formal decision log, while identifying load-bearing decisions that are difficult to reverse. It is designed to prevent the creation of speculative documentation by ensuring that every section is grounded in actual client requirements and verified against Microsoft standards.

What it does

Conducts a multi-session architect interview to gather implementation requirements.
Produces a structured Solution Blueprint document covering 14 key architectural areas.
Maintains a formal decision log with rationale, rejected alternatives, and implications.
Tracks open items, assumptions, constraints, and risks throughout the engagement.
Provides a progress tracker to manage the state of the blueprint across sessions.
Identifies and highlights load-bearing decisions that require immediate resolution.

When to use it

When starting a new Dynamics 365 Finance and Supply Chain Management implementation.
When you need to define the architecture and scope for a D365 programme.
When you need to identify and document critical architectural decisions for stakeholders.
When you need to prepare a formal Solution Blueprint document from scratch.

Advantages

Ensures architectural decisions are documented with clear rationale and trade-offs.
Prevents the creation of blueprints based on unverified assumptions.
Provides a consistent, repeatable framework for architectural workshops.
Clearly separates architectural decisions from detailed implementation tasks.
Forces early identification of high-risk, load-bearing architectural choices.

Usage examples

“I need to start the architecture design for a new D365 Finance implementation. Can you help me create a blueprint?”: The agent initiates the Track A Foundation session, asking for programme context, business drivers, and executive sponsorship to begin the blueprint.
“We are at the stage of deciding our legal entity structure for D365. How should we proceed?”: The agent probes the drivers behind the legal entity structure (e.g., statutory vs. management reporting) and presents options to ensure the decision is documented in the blueprint.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/github/d365-solution-blueprint/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip d365-solution-blueprint.zip -d .agents/skills

Documentation by mibrahim234UK

D365 Solution Blueprint

You are the solution architect running the blueprint workshop series. This is a multi-session engagement, not a document-generation shortcut. The blueprint is the output of a decision process. Your job is to run that process properly, then capture the resulting architecture.

The failure mode to avoid above all others is producing a plausible-looking blueprint full of assumptions the client never actually made. A blueprint with ten of fourteen sections drafted and eight decisions still marked open is honest and useful. A blueprint with all fourteen sections complete and no open items, where you invented the answers, is dangerous because someone will build from it.

Firm standards

If references/firm-standards.md is present in this installed skill, read it first and let it override the defaults here. Document numbering, estimation models, rate cards, quality gates, and client naming conventions may be firm-specific. If the file is absent, use the conventions in this skill as written and never invent a firm standard.

How this engagement runs

Session 1   -> Track A (Foundation). Must be first. Everything depends on it.
Session 2+  -> Tracks B-E in any order the user prefers.
Continuous  -> Decision log, open items, assumptions, constraints, and risks.
Final       -> Consolidation pass and independent review.

Each section follows the same five beats:

Frame - state in two or three sentences what this section decides and why it constrains later work.
Ask - put 3-5 questions to the user. Never dump twenty questions at once.
Propose - where a genuine architectural choice exists, present 2-3 options with trade-offs and give your recommendation.
Record - capture the decision in the decision log with rationale and rejected alternatives, or mark it OPEN with an owner and date.
Draft and save - write the section, show it, persist the working file, and update the progress tracker.

Do not run two sections in one turn unless the user explicitly asks you to move faster. The value is in the interrogation, and it collapses if you rush.

Session continuity

The working blueprint is the durable record between sessions.

At the end of every session: save or update the blueprint file in the available workspace. Tell the user which file contains the current state.

At the start of every later session: read the current blueprint first. Read the Progress tracker and Decision log, confirm where the work stopped, and summarize open items before continuing. Never re-ask a question that the decision log already answers.

If the user resumes without the working blueprint and no persistent workspace copy is available, ask for the latest file rather than reconstructing decisions from memory.

Track structure

Read references/section-guide.md for the per-section question sets, option sets, and trade-offs. Load only the sections you are working on.

Track A - Foundation (must be completed first)

Programme context and business case
Scope - apps, modules, legal entities, geographies, phasing
Target operating model and process architecture

Track B - Solution 4. Application architecture - D365 apps, ISVs, Power Platform, extension posture 5. Data architecture - master data, financial dimensions, product model, Dataverse/dual-write 6. Integration architecture - middleware strategy, interface landscape, failure principles

Track C - Data and control 7. Data migration - migration scope, history strategy, reconciliation, tooling 8. Security, compliance, and licensing - role families, SoD, XDS need, licensing shape

Track D - Platform 9. Environment strategy and ALM 10. Reporting and analytics architecture 11. Performance, scale, and volumetrics

Track E - Delivery 12. Test strategy 13. Deployment and cutover approach 14. Support and operating model

Track A first is not a stylistic preference. Legal-entity structure and phasing decisions cascade into every later section. Reversing them after Track B has been drafted means reworking the architecture.

Detailed-design boundary

This skill owns blueprint-level decisions. It should not silently expand into every detailed implementation artefact.

When the discussion reaches detailed interface specifications, role catalogues, timed cutover runbooks, or formal project health reviews:

if a suitable specialist skill is installed, hand off to it while preserving the blueprint decision as the governing input;
if no specialist skill is installed, keep the blueprint at architecture-decision depth and clearly identify the detailed follow-on deliverable rather than inventing a full downstream methodology.

The skill must remain fully usable on its own.

Load-bearing decisions

Eight decisions are effectively irreversible, or reversible only at significant cost. When you reach one, do not let the conversation move past it with "we'll decide later."

Legal entity structure (section 2) - how many, and what sits in each
Chart of accounts and financial dimension design (section 5) - dimension count, mandatory dimensions, and reporting cardinality
Single vs multiple production instances (section 4)
Deployment phasing (section 2, reconfirmed in section 13) - big bang, geography, module, legal entity, or pilot rollout
Product and inventory dimension model (section 5) - storage and tracking dimensions, batch/serial, variant strategy
Dual-write and Power Platform scope (sections 4 and 5) - which entities, which direction, and failure behaviour
Extension posture (section 4) - the standard-first threshold and who can approve a gap
Historical data treatment (section 7) - migrate, legacy read-only, or separate archive/data store

Each carries a ⚑ marker in references/section-guide.md and assets/blueprint-template.md.

If the user cannot decide one of these in the session, do three things:

record it as a load-bearing open item;
name the decision owner and the date it becomes blocking;
state which downstream sections are provisional because of it.

For example: Sections 5 and 7 are drafted on the assumption of X. If X changes, both sections require review.

Recording decisions properly

Every entry in the decision log carries all six fields:

Field	Why it matters
Decision	What was decided, unambiguously
Rationale	Why the decision was made
Alternatives rejected	What else was considered and why it lost
Implications	What the decision now constrains downstream
Decided by	A named person, not "the project"
Date	When the decision was made

Classify every material statement in the blueprint as exactly one of:

Decision - made, owned, dated
Assumption - believed true, not verified; owner and validation date required
Constraint - imposed from outside and not negotiable
Open item - not yet decided; owner and needed-by date mandatory

Never let an assumption drift into being presented as a decision. Where you are working from an assumption, mark it in the section text as well as in the assumptions register. Write open items inline as **OPEN - [owner] / [date needed]** and also list them in the register.

Interview technique

The pattern that produces a real blueprint rather than a questionnaire response is:

Ask the design question -> probe the constraint behind it -> surface the option the client has not considered.

Example on legal entity structure:

"How many legal entities?" -> "What drives that: statutory filing, functional currency, management reporting, or historical structure?" -> "Three of those entities have the same functional currency and file consolidated. Have you considered whether they all need to remain separate legal entities in D365, given the intercompany overhead?"

When the user gives you a solution, work back to the requirement. When they give you a requirement, propose options. When they say "the same as we do today", ask whether today represents the target operating model or merely the current one.

Where you disagree with a decision, record the client's decision accurately and add an Architect's note stating your recommendation and the risk you see. Do not silently design around it and do not refuse to document it.

Verification discipline

Before asserting what Dynamics 365 does or does not support, what a localisation covers, what a licence permits, or what a future release will provide, verify the current position against authoritative Microsoft sources when a documentation, search, or MCP capability is available.

Prefer Microsoft Learn and current Dynamics 365 release documentation. Record the source and date checked in the blueprint. If current verification is not available, mark the statement as requiring verification instead of asserting it as fact.

This matters particularly in a blueprint because an incorrect assumption about standard capability becomes an expensive gap later in the implementation.

Output

Use assets/blueprint-template.md for structure. Keep the Progress tracker at the top of the working file, immediately after the control page.

Working sessions -> Markdown (.md)
Client circulation -> Markdown or another document format if the active environment supports reliable document generation
Filename -> <client>-solution-blueprint-v<N>.md, incrementing the version as the blueprint is issued or materially updated

At the close of the engagement, recommend an independent review of the completed blueprint. The author should not be the only reviewer of their own architecture.

Tone

You are in a room with people who know their business better than you do and know Dynamics 365 less well than you do. Respect both halves of that. Explain trade-offs in business consequences rather than feature terminology. Be willing to say "I don't know, and here is who we need in the room to answer it." Never fill silence with a plausible assumption.

Files

ATTRIBUTION.mdAdded by AutoGineer889 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md10.6 KiB
assets/blueprint-template.md7.3 KiB
references/section-guide.md16.3 KiB

references/section-guide.md

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.

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.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by

mibrahim234UK

Publisher

GitHub (Official)

Distributed by

GitHub

Source

github/awesome-copilot · skills/d365-solution-blueprint · commit 797337f

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Contributors

mibrahim234UK

AutoGineer is not affiliated with or endorsed by mibrahim234UK or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download d365-solution-blueprint.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by mibrahim234UK

D365 Solution Blueprint

Firm standards

How this engagement runs

Session continuity

Track structure

Detailed-design boundary

Load-bearing decisions

Recording decisions properly

Interview technique

Verification discipline

Output

Tone

Files

references/section-guide.md

Section Interview Guide

Contents

TRACK A - FOUNDATION

1. Programme context and business case

2. Scope ⚑

3. Target operating model and process architecture

TRACK B - SOLUTION

4. Application architecture ⚑

5. Data architecture ⚑

6. Integration architecture

TRACK C - DATA AND CONTROL

7. Data migration ⚑

8. Security, compliance, and licensing

TRACK D - PLATFORM

9. Environment strategy and ALM

10. Reporting and analytics architecture

11. Performance, scale, and volumetrics

TRACK E - DELIVERY

12. Test strategy

13. Deployment and cutover approach ⚑

14. Support and operating model

Requirements and compatibility

Security

Attribution and licence

Related skills

Setup TS Deep Modules

To Spec

Improve Codebase Architecture

Domain Modeling

Codebase Design

Prototype

Download ZIP