Step 2: Define the Target Architecture

Decide what you're building toward — Angular structure, .NET API structure, data layer, hosting, observability — and document it as ADRs.

What you're doing in this step

Document the target architecture in detail and capture every key decision as an ADR so future contributors know why the choices were made.

Recommended prompts

Use one of these to do the work in your IDE

Open the template to read it in full. Click Copy prompt to grab it (with your stack values pre-filled where they apply) — then paste into Claude Code, Cursor, or wherever you build.

Primary recommendation 1 day

Coexistence Architecture ADR

Document the architecture decisions for running legacy and new systems in parallel during migration: routing, auth, data, and sessions.

View template

Template· Template 15 min

Architecture Decision Record (ADR) Generator

Generate a structured ADR documenting a technical decision and its trade-offs.

Use this when: You want to write individual decision records one at a time rather than a single coexistence document

View template

Recommended skills

Drop these into Claude Code for this phase

Skills auto-trigger on the right kind of request. Install once; they apply to every prompt that fits.

Skill· Skill 5 min setup

Migration Planner Skill

Flagship migration skill that walks Claude Code through audit → strategy → slicing → cutover for any legacy system migration.

claude-code

View skill

Recommended MCP configs

Wire these tools into Claude Code first

MCP servers give Claude Code direct access to external systems (Jira, browsers, databases). Configure once.

MCP config· MCP config 5 min setup

Filesystem MCP for Evoke

Pre-configured filesystem MCP server for Claude Code — safe, scoped read/write access to project files.

claude-codemcp

View config

When you're done

Verify these in your own work before moving on

This is a checklist for you to mentally tick off in your repo and IDE — the site doesn't track it, you do.

Target architecture diagram in /docs/architecture/
Frontend architecture decided (Angular version, state management, design system)
Backend architecture decided (.NET version, ORM, API style)
Data layer decided (SQL Server stays / migrates to Postgres / per-service)
Auth approach decided (IdP-fronted; if rolling own, document rationale)
Hosting decided (App Service / AKS / etc.)
Observability strategy chosen (App Insights / Datadog / etc.)
5-10 ADRs covering key decisions, all dated and marked accepted

Common pitfalls

What goes wrong at this step

Microservices fever — splitting too fine when a modular monolith would work; modularize first, microservice later
Custom auth — don't roll your own. Use Azure AD / Auth0 / IdentityServer
Skipping ADRs — future engineers won't know why decisions were made and will relitigate them

← Previous step